The rise of Quality but the death of the tester

Products are getting better. They can do more, they are faster, they change lives everyday. Not only are better products being made, the quality of the products that are launched is usually incredibly high. A defect in a product is a big deal. Quality is an essential part of any product and an essential part of any product are the people or team that are responsible for quality.
The role of a tester has evolved as teams move towards more advanced development techniques and processes. I have been lucky to have been involved in teams that perform QA in very different ways. I have seen the development of the role of QA, from a silo’d function in a waterfall team, to skilled automated testers in agile teams. I would like to take a look at that evolution, and share my thoughts for the future of Quality and testers.
Testing in Waterfall
When I started working in QA a few years back, I was working on a project in a bank and we were doing good old fashioned waterfall testing. Over half a tester’s time was spent typing out test cases in excel spreadsheet, derived from lengthy, complex requirements documents. Testers would get a build after a few weeks from developers they had never spoken to and would execute the test cases they had carefully written. One. After. The. Other… As a tester myself I remember thinking how inefficient it all was. Testers could have predicted the defects before the build was delivered. I remember being frustrated that we could not work alongside the developers (they were in Poland). We performed regression manually. In this world, management’s focus on QA was number of defects and their priority, and how long remained in testing cycles before the product could launch.

Testing in Agile
Thankfully, my next positions were in agile environments where some of those issues I had encountered were alleviated. These teams had a mixture of automated and manual testers. Testers attended the ceremonies and contributed to the writing of stories, often identifying potential defects before they occur in the form of acceptance criteria. Regression was automated as much as possible, and QA’s owned and managed the regression suites as well as the code used to run the tests. Test cases came in the form of feature files or maybe some other test case management tool, but not nearly as detailed as in the waterfall model.
There are notable differences between the agile model I just outlined and the traditional waterfall. Shift left testing practices where testers are more involved from earlier in the project and are working closely with developers are being implemented. Testers also become more technical, as many are expected to write automated frameworks and tests. Extensive QA documentation is no longer a priority. Test cases were written from simple user stories instead of the complex requirements documents. In this world, product owners and managers still care about defects, but sprint demos and conversations with the team were the main QA concerns.
This agile testing model is much improved but it has its pitfalls. Testing can still be a bottleneck for features as testers have to test across multiple browsers and devices as well as performing regression testing when the team plans to release. Some teams may not have extensive test automation expertise or coverage and some regression would still be done manually. Another pitfall is when teams also can have large automated UI testing suites. These suites can take a long time to run and can also be flakey or unreliable. Testing in this world could resemble the image below.

Testing in Continuous Delivery
This shift in QA focus continues in a continuous delivery world, in which I have also been lucky enough to work as a tester in. A team operating in a true environment like this wants all automated tests to be run each time code is committed. There is not time for extensive manual testing. However, that does not mean there is not room for testers.
Int his type of environment the testers role is different from traditional agile teams. The gap between testers and developers has grown less. Testers as well as developers share responsibility of quality. Testers are like the owners of quality, they ensure automated tests are being written, but it may not always be them writing them. Developers are required to write unit and integration tests with extensive coverage, but also developers share responsibility of the end to end UI tests.
Practices like the ones outlined in this fantastic post are enforced, with testers ensuring developers are following best practices, but also having the ability to write tests if they feel appropriate coverage is not being given by one of the automated tests. Testers encourage developers to write as much tests for features and acceptance criteria as possible, at the unit test level. This reduces the need for large, expensive and flakey UI tests.

QA becomes the entire team’s responsibility, with the testers being the prime for all QA activities. Developers are forced to write code that is easily testable. Products owners in this world must allow time for developers to write full test coverage when they are working on a feature. Also as sprint demos have less importance or are no longer being performed, desk checks become a key exercise for product owners to get a sense of the quality of the product.
As the tools for testing applications continue to improve, many of the traditional QA roles can be automated. For eg. visually checking the UI for changes can be automated, accessibility testing can be automated. The testers in this environment strive to automate as much as possible. The only traditional manual testing task that remains, is exploratory testing.
The advantages of this approach are obvious. The entire team cares about quality, and the code is written in a way that is easily testable. With automated testing across many disciplines across the application, feedback to developers is instant. If something is broke, an automated test will catch it. For a tester, the sometimes boring and low value tasks such documenting test cases and regression testing are no longer required.
The future?
In this world, QA’s are becoming developers. The scope of QA work is reducing. If developers are instinctively in the mindset of writing tests and owning quality of the code, then the importance of having a dedicated QA is reduced. With well written feature files with proper refinement session so requirements are unlikely to be misinterpreted, and full suites of automated testing, the risk of defects becomes very low.
So what does the future hold for QA’s working in a continuous delivery environment? I believe that as teams continue to automate everything, testing tools continue to improve and developer practices continue to be more quality focused, the role of dedicated tester will cease to exist. Teams will share QA and its related tasks across each team member. This will involve the entire team becoming product experts, knowing the intricate rules of the business -a role testers currently fulfil.
The shift to this type of thinking may take some time. Many managers have seen the impact of defects in production. They have also seen the positive impact of good testers in agile teams. But as testing tools continue to improve and the line becomes more blurred, I feel this is the next logical step.
I would love to hear what other teams QA processes are and if they envision a role for a dedicated tester in the future.
