Every coding project has embedded risks and challenges that are constantly transforming and requires proper care. I have worked in test automation projects for more than 10 years now, I have used many languages, worked in multiple domains, being part of big and small teams and there is one thing that still scares me from time to time.
And it is To build something useless ...
You can smell that something is wrong when you have been developing your test framework for over six months and it is not providing any value to the product.
Purposes of test automation
I truly believe that a test automation framework serves 2 main purposes:
- Provides trust and confidence that if no bugs are found and no alerts have been triggered your system is continuously working expected even when new features have been added. This means that your framework serves as a confidence tool and if there have been month without a single test case reporting failure then you can always feel safe.
- Provides details when something goes wrong so that you and your team can analyze and take decisions based on the reporting failures.
Challenges of test automation
There are many challenges that we can face when working on a test automation project. The tests could be flaky and report false negatives that will consume time on debugging misleading scenarios. You can also skip important validations and report false positives which will lead into production issues and the possibility of customer facing problems. You can also be limited by technology, stack and setup and have an incomplete framework that only tests partial scenarios which takes us to the previous challenge.
But there is one challenge that I fear the most, and is to build a test automation framework that ends up being useless. Imagine yourself working for three month building the framework structure, you spend time adapting some cool reporting tools, and you use the very best SOLID programming principles to feel confidence about your code, but... nobody is benefiting from the tests. And here are some of the reasons why this could happen:
- They take too long to execute.
- They are flaky.
- There is no CI/CD process within your project.
- There is no confidence in the tests.
- They are complex to execute on different environments.
- There are unrealistic expectations about the testing framework.
- Nobody know about them.
What to do?
When you find yourself working on a test framework that is not providing a lot of value to anybody what you need to do is to remember that it is a software project. So what? What I mean is that your project should have stakeholders, should have requirements and a defined release lifecycle.
What you need to do is simple. Just raise your hand to the QA Team, the Dev team, the Product Owners, Project Managers and any other stakeholder that you think should be involved with the project. Ask the right questions and push for guidance, maybe the Product Owner just need one or two critical scenarios tested, while developers might not even understand the benefits of what you are working on and don't get me started with the amount of time testers don't know they could save.
Don't be afraid to start over, it is always better to have ten initial stable test cases and add coverage slowly, than pushing 100 flaky tests which means a lot of debugging and all the trust compromised.
Conclusion
It is easy to lost motivation when the work you are doing is not being appreciated, so make your self valuable and be smart about it.
follow me if you need help implementing your test automation.
https://coffeestainio.github.com
Top comments (0)