More Testing, Less Testers
- 3 minsI believe the more we take QA and testing related activities as a full-time role, and the tester as a person, the more distant we are from being agile. Based on the common sense on the software development nature, old-fashioned testers are not exactly suitable to our reality. However, mostly because of cultural inheritance reasons, many companies keep pushing for the tester role while calling their process as agile.
Inspired by what Kent Beck mentioned about 10 years ago, testing, as well as development and business analysis are skill sets, rather than individual roles. Not only can I reach that conclusion by logical induction based on common knowledge, but also by empirical experience: the most successful teams I’ve seen, share the fact that people are multi-functional and self-managed, in a sense that every single member would be actively involved in a) helping the business to figure out and define requirements, b) directly work on the development of features, and c) directly work on testing related activities. As a consequence, people in this kind of team always grow in skill diversity through knowledge sharing. They tend to care more about the overall goal rather than their individual performance.
On the other hand, a number of companies (including well-known agile consultancies) have been failing on that regard in many ways. It’s pretty common in those companies the idea of QA, BA, dev individuals, working for entire projects strictly in their given role. Also, the idea is usually sold to most of their clients, persuaded to believe they need specialized people. Recruiting efforts also have been contributing to this kind of RUP-like culture, by conducting interview process by role and sometimes (even worse) by technology.
In contrast, I tend to believe whenever you have a QA, a BA, or a Dev person in your team you’re a big step behind from what a lean production system looks like. In addition to that, this role separation frequently generates a number of direct and indirect problems in the process, like communication overhead, bottlenecks, super-heros and blaming culture. (and it’s boring… who really likes to do the same kind of thing for weeks, months, years?)
Overall, I feel that most companies are heading the wrong direction on that and they could rather encourage people towards multi-functional skills, given the proven benefits it brings to the whole software business. It’s clear, though, that specific knowledge is definitely valuable. But for a more adaptable, self-managed, risk-less and (the most important) money saver team, that specific knowledge must be shared and leveraged by as many people as possible.
Besides that, there are still some strong cultural barriers to be overcome. In fact, we may agree it’s not really difficult for testers used to automation to evolve their dev skills as well as for devs to evolve their testing skills. Also, it’s not that hard for testers and devs to develop business analysis skills (that’s pretty common, actually). However, for “manual” testers and old-fashioned BA’s getting into technical knowledge can be a long way to go. Specially for the ones that are in the market for a long time and have already incorporated a wrong sense of maturity. Overcoming that kind of barrier is still more a personal will than anything else, though.
I recently gave a talk on this topic in an internal event at ThoughtWorks, check out the slides:
Vinicius Gomes
Software Developer