QA specialists vs testers

Back in July, I wrote on my agile testing blog:

I'm becoming increasingly concerned about the suitability of conventional QA engineers in agile environments. Since agile methodologies stress that the entire team is responsible for testing and that as much testing as possible be automated, the QA specialist has limited usefulness on an agile team.

When I re-read that entry today, it felt like I wrote it years ago, not a few months. I still hold the same general belief--that distributing testing among scrum team members reduces the role traditionally played by the QA engineer--but my take on the situation is much more positive now.

While agile adoption could indeed lead to a total reduction in the number of QA engineers needed in the industry, it can be a good opportunity for individual QA engineers. Nobody is relegated to the role of tester--a subset of QA work that's generally considered lower status. Instead, every QA engineer on an agile team must function more like a lead QA engineer: planning testing strategies, advising the team on what testing is necessary, and making sure that the testing work is accomplished by various team members.

I have seen first-hand the positive effects of scrum on the professional lives of individual engineers. I mentored a QA engineer on one of our teams here who first struggled with the challenges of her role on her scrum team. But I'm happy to report that she has since flourished and really come into her own as a 'QA specialist' on the team. She has gained the respect of the entire team and raised the overall quality of the software that her team develops.

I'm interested to know if others have witnessed the same types of effects.

Comments

[Andrew]

Hi Stan -

Good article. I am fairly new to agile, but have a lot of experience with iterative waterfalls. Couple points I wanted to make, and to get your thoughts as well.

I struggle with your definition of a QA engineer vs a tester. To me, the role of Quality Assurance on a project is to make sure deliverables (test scripts, code, functional designs) live up to a certain standard, which you inact at the beginning of a project. The QA is seen as a subject matter expert for this area. To me, a tester is someone who actually physically tests the application.

To that point, and yours, as automated testing becomes more common, the role of setting up the test cases (high level view) and test scripts (executables in the tool) becomes critical. To me, this should not be done by the development team, because they are too close to what they have written, and will make the test scripts cater to their needs, rather than the core requirements.

Also, it is rare that you have a skillset of a developer and a resource that is intimately familar with setting up automated test scripts, performance testing, and executing those scripts in a tool such as HP's Test Director (formally Mercury). I am curious if you have run into the same problem.

How have you seen this done in an agile environment?

Thanks,
Andy

[Mark Johnson]

Stan,

As the manager of the QA team, I had been pushing for them to do less testing and more QA for several years.

Agile legitimised this and made it clear that the developers role is to develop working features, not throw half-working software over the wall to testing.

I have changed the role of the senior QA staff to include the negotiation with the stakeholders of the acceptance criteria before design and coding are started; this has given them higher profile within our organisation and our clients and raised their status.

[Jorge]

I find this comment has a subtle but important issue:
The headline refers to QA Specialist vs. Testers

Then, inside the comment, refers only to QA Engineers and testers.

Does the author try to say QA Specialist = QA Engineer? If that's the case, there is no reason to use different naming for the same meaning (QA best practice should avoid that)

On the other hand, if it is not, what is the relationship in between QA Engineer and QA Specialist in order to mention both in the same post?

QA Engineer is just a fashion name. QA Specialist is broader and fits in every position and company size.

[Steve]

This is the approach I took to building the QA team here at Six Apart. I knew that we'd have a limited number of people working on frequent releases of multiple products, so instead of building a sort of nomadic team of people with individual specialties who would have to change gears every week to work on something different, I put one person in charge of doing all the test planning and execution for each of the products.

I consider it successful, but only because I held out for the right people for each product. Recruiting has been nightmarish, and I'd say that we only interviewed about 10% of the applicants who made it past our recruiters' screens. I've stressed to our recruiters that candidates who haven't worked in a startup environment are almost never what we're looking for.

As for the effect on peoples' careers, I believe it's been good, in that it's forced them to constantly work out of their experience and comfort zone. It's also made them more significant stakeholders in their products; one of our QA Engineers recently became the product manager for the product he works on.

I think this method scales well for the company and for the Engineer. As the company grows, you can start to build out the individual product teams with similarly well-rounded individuals who display a strength in a particular area of specialty. For instance, my second person on the team might be someone who's a good all-around tester but has always wanted to spend some real time learning and building automation, as opposed to someone who is a career automation specialist. The latter will cost more money and be of limited use until the product is really ready for him. I might also get someone who is really entry-level and have them focus on black box testing and regression to start off with. The tech support team is usually a good place to tap for that person. This approach to growth allows the original engineer to decide along the way if they want to take on a more traditional "working lead" role, or pick an area of specialty (but not exclusivity) to focus on while making room for yet another person who is a well-rounded tester with aptitude for resource management and planning/project management.

One last key to making this work, in my opinion, is making sure that your management team is behind you. I've been lucky with my management teams in that I've always been able to show them why it's worth it to keep a requisition open long enough to find the right person, and why they might need to look at the salary requirement a little differently than with your typically less-broad QA Engineer.

[Sean Wilson]

We are just starting to institute an Agile Methodology here and as the QA Manager, your topic is near and dear to my heart.

Some information about how your mentoring went would be fantastic.

Sean