More Testing. Less Testers.
by vvgomes
I 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’d say you’re being too nice. The picture is even more grim… even within roles there is excessive specialisation and labeling. Amongst developers we probably have the most problematic situation: “ruby developer”, “front-end developer”, “dba” are just a few examples.
These days I feel like BAs and QAs are completely obsolete unless they are substantially technical. The same could be said about Developers that can barely communicate a full sentence to a stakeholder without abusing technical jargon.
Beautiful post, Vini.
I completely agree with Mozair as well. The main problem IMO is that many companies are more concerned about producing code, than actually producing software. Once you realize the product you’re building matters, you shift from the simple billing unit to a real software developer, roles are not that important anymore, as long as you’re getting things done (the important ones).
Where’s that revolution everyone talks about?
Amazing post! Very well done, Vini.
This is an uncomfortable subject that I’ve seen many people avoiding.
It’s specially interesting how paradoxical it is that the agile community talks so much buzzworks like kanban and lean but doesn’t seem to give much attention to the fact that having multi-functional members is key to get major concepts such as buffers and wip to work properly.
On the other hand, I am not totally convinced that completely abolishing roles is the way to go either. I do think that there’s more to quality assurance than just writing automated tests, and there’s more to business analysis than just being comfortable talking to clients. But in the end of the day what development teams do is deliver working software, and working software is code, so everybody in the team should be able to read and write code, godammit!
I would agree that people whose attention and skill set is limited to the box defined by their role are not really agile. However, I think it unreasonable to expect an individual to be an experienced multi disciplinarian. My job title on my CV is BA, I’ve done consultancy as tester and I’ve written SQL code (I can generally with a bit of guidance read most languages I’ve been exposed to) and participated in system design, and performed some scrum master activities. However, with the exception of the BA skill set, I consider my skills in the other roles to be junior and there are many times where a better skilled person is needed. So I still believe whilst each person on a software team should be willing and able to learn new/cross functional skills it’s not always the most efficient use of resource.
In response to the question that seems to permeate the industry ‘do we still need BA’s?’ I’d agree the BA role is a collection of skills which anyone can learn….but I’ve yet to meet a person whose specialism is other than BA (PM, Dev, Test) who wants to work with the business on the non IT aspects of the solution, eg business process design, training, change management. And yes the People who work in the business could do these things, but again they may not have the skill sets because their time has been spent becoming proficient in what their primary job requires eg HR, Accounts etc. So, yes on many projects I think a BA is still required.
So in summary each person on a team should have some awareness and appreciation for other team members skill sets, but we can’t all be masters of every skill required to produce quality solutions (software, process and people).
I agree that some level os specialisation is necessary and healthy… although I wouldn’t go as far as creating different roles to shoehorn that into team mechanics.
Specifically related to writing automated tests I think that’s a very serious issue we face right now. We basically have a whole bunch of clinic doctors performing heart surgery because hey, they found out that a scalpel can cut people right open \o/. I’d say if you don’t feel comfortable enough to write production code, you should not come anywhere near automated tests too.
If you are a tester, QA, QE and want to automate stuff, fine… first you have to become proficient in the skill set of a developer. I don’t want to see people learning to hook up a couple of badly organised selenium calls before they understand programming at all.