About the Blog

  • Software is our business, and perfecting the art and science of delivering it is our mission. The contributors to this blog are passionate about the impact that great teams and good software can have on an organization’s bottom line. They bring decades of experience designing, developing and delivering great software, and each is playing a critical role in Borland’s own transformation.

Blogging Authors

« The benefits of continuous software delivery | Main | Agile Development Practices conference take-aways »

November 13, 2008

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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

The comments to this entry are closed.