Not having enough time for test automation is a common problem that faces most test automation projects. I have personally experienced it in several projects I have worked on. In this post I will try diagnose some problems and their solutions.
Read Bold Text Only if Skimming
The Test Automation Narrative
Test automation projects are always initially viewed as the solution to all software quality problems. We all think we will just build a test automation suite. Run the test suite before the release and voila quality is ensured. For this reason the project starts with a lot of enthusiasm. A team is allocated to start building the amazing automated test suite.
The team builds the automated test suite and deliver it to be used. The project ends and the team is deallocated from the project. The test suite works well for a period of time. However without continuous maintenance and updates the automated test suite starts to slowly degrade providing less and less value over time until it becomes a burden.
It becomes clear that the automated test suite requires more work. However at this point the whole team is busy performing functional tests to cover new functionality or performing repetitive efforts to ensure that the old functionality is working as expected.
The team does not have enough time to invest into test automation. Which is the real irony because it’s the test automation that would save the exact same team from doing repetitive efforts therefore saving their precious time.
The Alternative Narrative (In Points)
Now that we are done with the narrative let’s look at an alternative narrative that could really work benefiting you and your company.
First of all let’s set it clear that the alternative narrative does not provide a solution to the time problem. Instead it introduces a different way of doing test automation.
- Test automation is not a onetime project without continuous development the test quickly lose their effectiveness becoming a burden. Test Automation must be treated as an ongoing activity like any software project. Set smart small milestones, develop it, Merge it into the release process, Celebrate and repeat. The milestones here could vary from covering new functionality, refactoring the scripts or improving the performance of the test suite.
- For ongoing projects test automation cannot survive on a temporary allocated team. Supplementary to the first point you must have a permanent team that is focused on developing, maintaining and improving the automated test suites as a continuous activity. This would allow the team to gain ownership of the project growing the test suite along with the code it is testing.
- Test automation must be treated like production code. Investing time on its architecture and design patterns. It may be time consuming at first. However doing so could lead to a highly scalable and maintainable test suite. Increasing the effectiveness of the test suite overtime and decreasing the risks of it becoming a burden for the project.
In my opinion this is the only way to effectively include test automation into your development process. Stop viewing automation as a temporary activity, instead see it as a main activity that must be done side by side with the production code. Automation is not the answer to all software quality problems. We would always rely on other forms of testing to deliver quality code. However if you or your company is considering incorporating automated testing into the process consider the alternative narrative.
This is just me putting my thoughts into words. This is a first draft. I am eager to hear your comments and suggestions and editing it further as needed.
Please do leave a comment with your thoughts….