QA: Stop finding bugs!

Start preventing them!

For the past few months, I have delivered several versions of a presentation I created, titled ‘Scrum Primer’.  Managers at several levels, engineers, and other employees involved in the creation our software have attended.  A couple weeks ago, I added our QA department to that list.  Theirs was an interesting meeting and preparing for it expanded my understanding of their role on an agile team.

I would like to share some of my insights with you.

Traditionally QA is seen as gatekeepers of the product.  Each night, the build machines compile the engineering modifications in to nightly builds.  In the morning, QA grabs the nightly build, installs it, and validates the modifications.  If the engineer claimed to have fixed a defect, QA attempts to reproduce it.  If the defect or a derivative of it remains, QA rejects the change and the engineer revisits the code.  If the engineer added new functionality, QA compares it to design documents and test plans to validate that the engineers modification matches.  If it does not, QA rejects the new functionality with an explanation and the engineer revisits the design.  In either case, if QA accepts the change, the task is marked as completed and s/he moves to the next modification.

Do you see a pattern here?  Historically, QA’s role has been to find defects.

Engineering pushes code to QA, and then QA accepts or rejects it.  This is how I was taught in school.  It makes sense.  Someone has to validate what the engineers do.  Automated tests are limited and can only take a team so far.  Eventually human eyes are needed.  Typically, this is someone with significant domain knowledge and skill to verify or find breaks in the code.  These people best served the team by taking the code produced by engineers, running it through their mental models, and then providing feedback.  QA, in this model, is limited to the receiving end of product development.

In an agile team, the role of QA has expanded.

With agile teams, the opportunities for QA to provide more value are greatly increased.  Yes, they are still responsible for validating the quality and completeness of software, but because they work alongside the product managers and engineers, they can provide more value than QA traditionally has.

The opportunities are there.  Our Scrum team recognized this when we found that QA was never demoing the software we created during our sprints.  Historically it was the engineers.  Why?  The QA team member helped the engineer develop it by providing design guidance, clarifying requirements, and locating design & implementation defects.  As of our last sprint, we have QA demoing some of the software they helped create.  They now have an opportunity to discuss the product that they helped build.

It is important to recognize something in that story.  It is not just about making QA a contributor in the sprint demos.  It is about recognizing the pivotal role that they fill on an agile team.  They work with everyone to ensure that what is delivered will meet our customers’ expectations, end-to-end.  While this could be said of the traditional QA role, the key difference under agile is that QA is an active, rather than a passive participant.  On an agile team, they help design and refine the product.  They are helping teams prevent as well as find defects.

———-8<—————————————————–

Regarding the role QA plays on your team, here are some things to ask yourself:

1. Do they participate in conceptual design discussions?

2. Do engineers work closely with QA to deliver software and resolve issues?

3. Does communication happen primarily through face-to-face conversations?

4. Is your team fully leveraging the QA with specialized domain knowledge?

Time to get better

Battered, bruised, and still smiling.

My team just finished a long, involved, and complex project.  The outcome is a milestone product that we are proud of.  In fact it is probably the best product we have released in years.

As part of any good strategy to improve, the team will be hosting a retrospective which will allow team members to discuss what practices they would like to continue to perform, and what practices need improving.  I am heading on vacation shortly and will not be available to attend, so I drafted some notes listing my humble opinions about the good, bad, and ugly practices.  It gave me a chance to reflect on the benefits of a retrospective.

It is important that teams host a retrospective shortly after a milestone, because it provides teams with many benefits, including some which may not be obvious:

• It allows team members to indirectly thank each other.  By stating that a practice was beneficial, the team member who original suggested or implemented the practice gets an emotional boost.
• The retrospective provides an opportunity for newer, shy team members to participate in larger team discussions, even if they only say ‘I agree".
• The team can focus on improving itself without the pressures of delivering a product
• It builds the community, since a retrospective involves different functional teams discussing issues in the same room

The retrospective is a beneficial activity that is not restricted to our company.  Some company executives host an annual retrospective where they discuss the prior year.  Others follow processes that require retrospectives, such as SCRUM.

If you are not performing retrospectives, you are missing out on a vital opportunity to inject successful practices in to your next project.  Start now!

Here is a good resource to get you started: Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement.