What software engineers like to do best is to take on challenges, develop algorithms and data methods, and write new code. Their focus will always be on making it work instead of testing it, stressing it, breaking it. If you ask them to estimate the complexity of a user story, they will do so from the perspective of “how much work is it to write this code?” not “how difficult will it be to define and execute a test environment?” To ask them to keep an even split between the two is an impossible exercise in double-think.
THE ROLE OF THE TESTER
The role of a software tester is to determine the best approach to testing each feature, in each sprint. The complexities of selecting the right programming approach to test automation are often equivalent, and always different, than developing new code. Asking software developers to switch between the two is inviting one area to be neglected.
This is not to say that developers do not provide a valuable foundation into the testing process. Thorough unit testing is the bedrock of quality software, and the development team is in the best position to make that happen. Only if the conditions of each module of code are tested with enough detail to provide confidence that changes to the latest build did not break the previous one can the Agile process move forward with the velocity expected of the team.
Beyond unit testing, however, paradigms and concepts in test automation change dramatically. Even the most straightforward automation platform, such as Selenium, requires combined experience in coding, test architecture, and metrics reporting. Getting the most out of a business-driven test platform such as Cucumber, takes an automation engineer that is a unique breed of programmer. Scriptless automation platforms, such as Tricentis Tosca, remove the need for writing code and enables manual testers to easily automate tests.
Not having someone focused on manual test planning and execution is another issue with “textbook” Agile. There is a specific skill, borne from years of experience, in taking a user story and being able to write the “correct” number of tests to sufficiently cover positive and negative conditions, without wasting time by repeating tests or having too much coverage of low-risk areas. Not all tests can be automated, and it takes a well-thought out manual test plan to fill in the gaps. System performance, scalability, usability, security, device compatibility and accessibility are all specialties within the software profession. The assumption that team members within an Agile team can switch into these roles and do what needs to be done is simply untrue.
Within the Testing Practice at SPR, we embrace the Agile Manifesto, and the philosophy of integrating within a team that can rapidly turn out quality software. But first and foremost, we believe in the value of having software test experts, not interchangeable cogs.