More on QA specialists vs. testers

In my previous post, QA specialists vs testers, I mused that agile is good for the careers of 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.

The post garnered several comments. In this post, I'd like to address some of the thoughts and questions in the comments.

First, Andrew and Jorge question my use of terminology. Andrew writes:

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.

I agree 100% with that definition. But Jorge asks:

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)

In general, I would say, yes, the two terms are interchangeable. The point I was trying (unsuccessfully, I see) to make in using the term "QA Specialist" was specific to agile: a scrum team consists of members with various specializations, which makes the QA engineer the team's QA specialist. But I agree with Jorge, it's probably an unnecessary distinction to make. "QA Engineer" has all the same connotations.

Mark Johnson points out that this change of focus for QA engineers has also been good for the company and products overall:

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.

I don't really have any reply to that except to congratulate Mark. That's the outcome that I would expect from a successful agile implementation.

Finally,Sean Wilson asks about how I undertook the mentoring that I described in my earlier post.

The QA engineer whom I described was originally assigned with me to the same scrum team. Our mentoring relationship started with some credibility issues with one of the developers. To over-simplify the situation, one of the developers on the team felt that the QA engineer was not sufficiently trying to solve problems or find information herself before involving him and he felt his time was being wasted.

The other QA engineer and I discussed the problem, and we agreed that I would become her 'safety.' If she couldn't figure out a problem or find information, she should come to me first, and I would help her find other methods to address the issue at hand before resorting to the developer in question. We also explicitly agreed that she could ask me anything; no question was dumb with me. And finally, if she did have to take an issue to the developer, I mentored her on how to present it, e.g., describe the issue as methodically as possible, list the steps she'd already taken to resolve it herself, etc.

Due to this agreement, we formed a relationship of trust, and it eventually led to broader mentoring. I have to say, though, that the success of the relationship lay squarely with the other QA engineer: she recognized her weaknesses, sought out a mentor and actively worked to better herself professionally.

I eventually left that team and this QA engineer assumed a more active role in leading quality efforts. Over the course of a few months, I was pleased to see that she was flourishing in this role.

Comments

[Michael Maham]

Stan-

For a long time I heard many QA professionals insist that they were not "just testers" but that Quality Assurance also included things like ensuring the projects were following the proscribed process. While good, in theory, it set QA up as the "bad cop".

Like testing, whether we're doing our work the way we said we'd do it (also known as following our process ;) ) is the responsibility of the whole team. If your process needs outside enforcement, it is probably a bad sign! Of course, this means you need a highly disciplined team (as mentioned here http://borland.typepad.com/agile_transformation/2008/11/whats-missing-from-the-agile-manifesto.html) that includes good "QA specialists"