Test automation is without any doubt one of the hyped concepts for the last years and will most probably have a high focus in the years to come. The focus on increased software quality, lower maintenance cost etc. has spawned a lot of theories and discussions on how to best lift the task of doing test automation.
The existing, a large number of testers already in the software producing industry need to be put in a position, where they can implement automated test cases, while keeping the focus on their test profession. The testers should be able to use their high-value skills and competences when producing automated test cases without having to code – they don’t need a new profession – the just need the right tools!
There are definitely a lot of testers that have skills in programming and are able to understand the complex structures in various systems under test. My experience tells me that these testers are highly valued, busy and hard to find. The solution for many companies has been to reshuffle the existing puzzles. Train the testers in programming or give the programmers the responsibility for implementing the automated test cases. For many reasons this is far from ideal and will create at least as many problems than it solves!
Programmers as testers
Testing is a profession and a high-end craft – and it must be respected as such. The focus on details, overview of requirements and the ability to represent the end-user in a development team as well as providing reliable feedback to the programmers are examples of the important and crucial role a tester covers. This shouldn’t be taken lightly or neglected as something that can be done by others.
These characteristics don’t fit very well with a software developer. Software developers want to…yeah…develop software. The developers will eventually focus on what they think is interesting – implementing and delivering features, doing unit tests etc. Fixing bugs will typically also get a higher priority when the going gets tough. Doing test automation will never be an integrated part of a developer’s work life, and the quality of the test will end up being questionable.
When considering how to do test automation, be sure that the prerequisites and assumptions are realistic, can scale and are not bound to one specific employee.
Testers as programmers
Having testers implementing automated test cases in code solves – at least in PowerPoints – the problem of finding the right resource that knows about test and can implement test cases at the same time. It also carries a lot of problems with it.
First – coding is not a tester’s job! The tester shouldn’t care how an application is implemented – why is that? Because the customer doesn’t care and the tester represents the customer when it comes to quality. Yes, there are definitely testers that can and will add test value by understanding programming and can decode the implementation of the system under test. My point is that a tester shouldn’t have to do this to do the job of automating test cases.
Second – Let’s assume a tester should learn how to implement test cases in a code based test automation tool. Understanding and learning the coding language for the testing tool is not enough. The tester needs to understand the model and implementation paradigm behind any application under test. Once a tester has this skill in development it’s my experience that the tester eventually will change the carrier and start focusing on development. Why? Money, prestige and interest!
Third – What about the millions of testers already in the software industry? They possess an enormous amount of domain knowledge which can’t be used if they don’t learn how to code. This is not rational!
Testers are not programmers, programmers are not the new testers. Testers are still the testers!