Once upon a time, software development was nowhere near as complex as it is today. In many cases, it was a one-man job. Even with a slightly bigger team (augmented, for example, by a designer and a tester), it all fit nicely in the classical waterfall model:
Nowadays, however, we build large environments in cross-functional teams, and we can’t put off testing until the very last moment. In this article, I’ll outline the problems with the typical role of a tester and I’ll suggest a more suitable solution for modern software development.
A typical tester is not enough
There are two significant reasons why separating testing from development doesn’t work anymore.
1. Testing happens too late
In the waterfall system, testers are rather late to the party. Quality assurance happens at a very late stage, and major issues are hard to fix. It’s bad enough in a project when the requirements are established at the very beginning. In agile development, when the conditions can change over time, it’s a recipe for disaster.
2. A tester doesn’t see the big picture
Typical testers install an application and check if it works as it should. If they do this and nothing more, their understanding of the whole product is only skin-deep. Therefore, a tester can make sure that the application doesn’t break, but they can’t guarantee that it really serves its purpose.
From tester to hero
Many ideas have been floated about how to improve the testing process in agile teams. One of them says that there is no need for a tester at all. Instead, it suggests that all members of an agile team should act as testers.
In my opinion, however, a dedicated quality person is required, but their role should be heavily redefined. We don’t need testers anymore, we need quality engineers. A quality engineer is much more than a person who finds bugs and reports them. They should be a part of the process at every stage of the project.
Working with the product owner
A quality engineer should work on the project’s concept and requirements along with the product owner to:
- Challenge the PO’s ideas
- Detect contradictions
- Spot edge cases by asking the questions like “What happens if/when ….”?
This will give them a strong understanding of the project’s purpose and business goals.
Working with developers
A typical tester waits until a feature is implemented to check it against the brief. A quality engineer, by contrast, is familiar with each element from the very beginning. They can help with project estimation and even have a say on the technical part. With the basic programming skills, the QE is able to better communicate with the development team.
Working with the code
A quality engineer should be able to write automated tests (integration and end-to-end). Because the QE understands the architecture of the system, they can spot integration points in the application. They can also determine the correct business path because they have been a part of the preparation stage.
The tester is dead, long live the quality engineer
The responsibilities of a tester and a quality engineer overlap to a certain degree. They both run manual and semi-automated tests but they work with the product on entirely different levels.
Unlike testers, quality engineers know the product inside out. They are active during the planning phase, so they are much better prepared for the testing stage. Moreover, their cooperation with the PO and the developers results in a much smaller number of issues during implementation.
All in all, in my opinion, it’s time to replace the scattered testing process with a more holistic approach. We don’t need test managers, manual testers, test developers, mobile testers, and so on. All we need are skilled engineers who oversee the quality of all aspects of the product, top to bottom.