The Evolution of the Tester Role

Repeated software-development tasks are becoming automated through the application of Continuous Delivery and DevOps. If developers are taking more and more testing responsibilities into their hands, I wonder what will be the role of traditional testing and testers moving forward?

This question has been troubling me since I looked at the testing pyramid, a concept coined by Mike Kohn in his book Succeeding with Agile. Its essential point is that you should have 70-80% unit tests, followed by 10% integration tests, 5% system-level tests, and 5% GUI-level tests.

Although the percentages of preciseness may differ, the point is that you should have many more low-level unit tests than high-level end-to-end tests running through a GUI.

Testing is all about risk mitigation. Instead of mitigating risks using manual testing or GUI-based testing, the test pyramid looks at risk mitigation from a holistic point-of-view. Testing in itself is not the last line of defence; developers also have to play an important role by laying out a strong, quality foundation in the form of unit, integration, and workflow tests.

Having said that, risk mitigation remains the primary responsibility of the tester role. If a tester doesn’t know how to read unit / integration tests and understand how they can be used in mitigating part of the risk, then he / she will never be confident in releasing code to production based on developer-oriented automated testing, plus automated functional testing. Only if a tester has programming skills, can he / she can make sense of automated and integration tests.

Wherever I hear success stories about the testing pyramid, they all have one key success factor in common: either developers do all the testing themselves, or testers learn programming in order to test. In my opinion, a tester who has following characteristics will soon be irrelevant:

• Accepts a regression suite run taking longer than 15 hours
• Does not collaborate with rest of the team members
• Has to be the “quality gate” (i.e., cannot explain risk and mitigation)
• Believes that automating all tests is a worthwhile endeavour
• Does not work towards improving quality by engaging with others

As part of the evolution of engineering roles, both developer and tester roles will soon have coding as a prerequisite. The only difference between the two roles will be that test engineers will put testing first, and vice versa. Testers will spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios. (Just to clarify, manual testing in the forms of exploratory and UI testing will still be alive; it’s just that testers will also value programming as an important skill.)

Conclusion

Gone are the days when manual testing was enough, and the testing cycle used to take months. Now almost the entire regression is automated. Out of that, only 5-10% is covered through end-to-end test cases. The boundaries between developers and tester are getting blurred day by day.

Testers need to also be good programmers moving forward. Just being familiar with programming will not be sufficient. Test engineers need to be product experts, quality advisers, and analyzers of risk.