Software Test Automation is often perceived as a magic bullet that can save the day in providing adequate test coverage. There are two main types of software test automation. Whitebox software test automation looks at the code and includes testing both statically and dynamically but just because you have good quality code as well as high code coverage doesn’t mean that you have good quality software. Another type of whitebox is related to testing data or interfaces where code is written to test incoming data validity and the interfaces that a software system may interact with. On the other hand, blackbox or so-called user interface software test automation tests the software from the end user point of view. In general, developers are involved in whitebox software test automation whereas “traditional” testers take charge of blackbox.
In practice, developers are often too busy to do much whitebox testing, much less whitebox automation. Therefore, defects are often found during blackbox testing that may be the result of missing whitebox testing. Recently, with the popularity of agile, software test automation has taken on a new level of importance at the whitebox level as code is supposed to be able to be delivered to the customer, as a workable and viable product with each iteration. Thus, developers check in code on a continuous basis, and run whitebox automate scripts to validate their code quality upon check in.
Testers, at first glance, may be seen as less valuable. And this is true for those that are not flexible. However, as the term agile suggests, and with quality moving upstream in an agile process, testers who are capable can actually take on a broader role or deeper role. Rather than waiting for the software to be thrown over the wall, those with some programming skills may get involved in unit level white box testing and software test automation at the whitebox level. They can also get involved in acceptance testing at unit, interface and system levels even without having coding skills, and those with technical backgrounds can then covert these type of tests into white or gray box software test automation scripts.
Those testers with softer skillsets have the flexibility to move upstream in the quality process. Product requirements in particular, are where many defects originate, and by working closer with product managers and business analysts, testers in this role can develop very effective acceptance tests both at the whitebox and blackbox realms. These tests in turn, can be turned into good automated test scripts.
Lastly, the traditional role of regression should be a lesser concern as so much of th quality process is moved upstream. By the time the product or code gets to regression there should be fewer defects to begin with. Regression can be done in a very targeted manner with base functionality or smoke testing, combined with very new features or functions implemented with that sprint iteration.
With a lesser burden at the end in regression testing, software test automation can be applied on a selective basis combined with greater emphasis on exploratory testing which is where most defects are found anyway.
As you can see, the role of testers and software test automation in an agile process has morphed wider and deeper. While there should be less regression pressure, more quality should be built in up front. Making this transformation is difficult due to migrating expectations, roles and responsibilities. Don’t expect a traditional waterfall team to convert to agile in a few months or even a year.
Software Test Automation – Testing in an Agile World