Monday, February 20, 2012

Reinventing QA

July 24, 2010 by · Leave a Comment 

In June 2010, Harvard Business Review Editor-in-Chief Adi Ignatius found himself as the moderator of two paths diverged in a conference room. One the one hand, he had a pile of clear reader feedback demanding that the executive summaries in the magazine be brought back. Ignatius and his editorial staff had recently pulled the summaries out of the magazine because the staff – all professionals in print editorial and business practices – had decided that the summary sections were redundant and ultimately took away from the presentation of the content.

The readership didn’t like these changes. The readership of Harvard Business Review, while generally intelligent and well-placed in their respective industries, were certainly not professional magazine publishers or editors. Shouldn’t the formal review of editors control editorial? Ignatius put the sections back in.

Why were sections that were clearly redundant added back to the magazine? The product clearly stood to benefit from the efficiency of the editorial staff’s decision to pull the summaries. Ignatius implemented an important concept that is vital to the success of a QA team: give the sponsors what they want. Guide your audience to where you feel they need to be, but ultimately give them what they want.  Sometimes the output of Product Huddle may, as in the case of the Harvard Business Review executive summary removal, be contrary to what the user really wants.  QA is in the best position to voice these suspicions first and get them on the product radar.

A web product’s feature set is not the minimally set of functions to achieve engineering proficience. A product that interfaces with humans needs human attention, human critique, and human testing and evaluation. Quality Assurance techniques used to analyze service-to-service functional efficiency surely must focus on the engineering minimal set and optimized performance; there is a time and place for this approach. It must not be the only approach: products written for human consumption required a softer, more flexible set of assumptions in writing a suite of tests. Quality Engineering practices for the web are far more than mathematical minimalism. How then do you take best practices for quality engineering and apply them to web QA? Surely regression, automation, new feature testing, UAT, and performance analysis are still needed. How do you adjust for the human factor?

One of the great advantages heralded by agile web development, especially by methodologies such as Scrum, are the integration of the product organization to engineering. Integration in this sense is a very real physical integration: have Product literally sit in physical proximity with developers and QA. Phone conversations overheard will reduce meetings. Exclamations at the content of certain emails will be not only entertaining but helpful. The response of “Oh no, not again” or “I can’t believe that got in there” to bug reports is supportive, helpful, and just plain fun. Having fun at work: what a concept! As QA professionals, look to where you can reinvent the prejudice that QA is a dry crust around the edge of the slice of pie. Be your own fruit filling!

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!