As a technical test consultant, I visit many companies to support them with testautomation. Every time I notice that there are still a lot of things to improve in this area. I mean testautomation on all levels, from planning to the specification and the execution of tests. It seems that companies think that the step towards the implementation of a structured testautomation framework is too high because the return on investment is not immediately visible. Next to that, there are not a lot of success stories yet, so that the restraint strengthens. Furthermore, sometimes the illusion arises that testautomation makes the work of testers superfluous.
However, the opposite is true … The main benefits and added value of testautomation are described below.
Testautomation has many benefits which contribute to better quality software. In the first place, testautomation forces –indirectly- that the testing process is at a fairly mature level. You need to have specified test cases which you can automate. However, if there are no test cases specified, testautomation is still possible, but you will have to think about two things at once while automating testscripts. (Desired behavior and ‘how’ to automate it) With a proper testautomation implementation, all tools, such as specification tooling, bug tracker, test execution tooling, etc., communicate and integrate with each other. Through this total integration, a lot of manual administrative tasks are no longer required and you can easily relate the test results to the original requirements.
Shortens the feedback loop
Adding value to a product can be done by releasing new functionality. The frequency at which this happens is the heartbeat of a project. In larger organizations, you see that they can release only a few times a year. That could be a lot more! You can execute the regression tests much faster, by implementing testautomation. Thus, more new functionality can be released more often.
Consistent quality factor
One of the goals of testautomation is that the tester is able to execute tests scripts repeatedly, without doing a lot of maintenance on those testscripts. It’s a good practice to start with the core functionality, because this functionality is subject to change the least. You can speak of a consistent quality factor, when all automated testscripts give the same positive results every time.
By implementing testautomation, you can repeatedly execute the exact same checks. The power of a check is that the outcome is always binary; it is either right or wrong. There is no human interpretation involved by verifying the result. The automated checks remove a lot of work from the functional tester. The testers now have the opportunity to focus on other (more challenging/creative) testing techniques, such as exploratory testing (simultaneous learning, designing and execution of tests). In addition, the functional tester can also take the challenge to learn a programming language, so that they can write the testscripts themselves.
Modern software architecture
Today’s architecture software solutions are ideally suited for testautomation. Think of a service-oriented architecture where the business logic is separated from the application and the application integrates with (some) interface (s). These interfaces can be invoked by multiple applications, so it is imperative that this works well and that no regression occurs.
Testautomation done by a tester is only possible if they are able to develop a broader skill set, so they can test applications from a more technical perspective. Especially in the agile software development approach, due to the iterative process, it is increasingly important that tests will be automated and the team gets the technical testers who can do that. Not doing testautomations means falling behind … The work can’t be done any longer manually, testers need to become more technical!
I look forward to the day when organizations recognize the benefits of testautomation and they start working goal oriented instead of tool oriented.
Testautomation, let’s do it!
This article is based on an original in Dutch published article on the Polteq website (see http://www.polteq.com/weblog/testautomatisering-leuker-kunnen-we-het-niet-maken/)