In my previous post, QA specialists vs testers, I mused that agile is good for the careers of QA engineers:
The post garnered several comments. In this post, I'd like to address some of the thoughts and questions in the comments.
I agree 100% with that definition. But Jorge asks:
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.