💾 Archived View for capsule.adrianhesketh.com › 2015 › 03 › 01 › the-future-of-the-tester captured on 2024-02-05 at 09:48:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
I went to a Round Table event last week hosted by the iSource group at their rather fancy new office in Leeds. I've been to a few of these events now, and always enjoyed the discussion with other engineering team managers.
Chris Ambler (Head of Testing at Capita Customer Management) gave us his historical perspective on where we've got to today, and we all talked about where we thought the role of the QA Team was headed.
As went around the table and each shared our views on the future of testing, most of us agreed that the days of the Tester who blindly executes test plans are over. Some of the group talked about the role of the Tester and being a repository for domain knowledge within an organisation, which I thought was a really good point - something that is often overlooked when the value of a QA team is being evaluated.
I talked about how the traditional QA Team is seen as being separate from the Development Team. In this model, you have a "Quality Assurance Manager" who is "the guardian of quality" and _theoretically_ could stop a release from going ahead. The testers are passive, there to check the work of the developers against the specification once development is complete, rather than to contribute to product function and design. This model is over now.
Having agile development teams means that this traditional management structure of "Dev" and "QA" has to change because the Dev and QA managers no longer control work assignment, it's handled by each team themselves. Having a "Guild" system (like at Spotify) is a good way to make sure each specialist within a team gets the training and support they need from outside their team, making the best use of the organisation's scale.
Security, infrastructure resilience and APIs all need testing just as much as user interfaces. Failure scenarios are complex, with applications failing under specific load or failing in single digit or lower percentage volumes which make them near-impossible to reproduce. Complex branching and deployment processes, feature flags and A/B product testing all have to be understood. Logs from disparate connected systems need to be analysed and performance monitored. SQL queries need to be written, JQuery UI automation needs to be built, APIs need to be tested using C#, Python or whatever, caches needs to be probed with wget requests, the Web Socket failure scenarios need to be tested. It goes on and on.
This necessitates a high level of technical skill within the "QA" specialism, sometimes higher than the feature developers. To be able to train / hire this skillset and be able to provide the right benefits package means ditching the job title of "Tester", so I suggest that the future of the Tester is to be something else.
Maybe "Developer - Quality Specialist" is the right name for this. What do you think?
WCF - Client Proxy Creation Performance with Ninject
Decreasing KMeans Clustering RAM Consumption with Sparse Vectors