Thursday, January 31, 2013

QA Accepted

I subscribe to how Cem Kaner clarified the difference between testing and quality assurance.
Testing is a technical investigation of a product, done to expose quality-related information.
Testers dig up useful information. This is good. But it doesn’t ensure quality.
Quality Assistance–that’s what testers do. We help. We investigate. We learn things. We report them clearly. We make sure that people understand what we have found and what its significance means. We provide the good data that is so important for understanding and improving the quality of the product.
That’s important, but it’s not “quality assurance.” (emphasis mine)
- Cem Kaner, The Ongoing Revolution in Software Testing (2004), p. 6-7
Couple of months back, I designed a proposed user story and bug workflows in our internal tool to use in our organization. A couple of days after I submitted it for review, I realized I marked the statuses for testing as “QA”, “Testing in Progress(QA)”, and “QA Accepted” consistent with how our development teams referred to what we do.
Big mess. I could have potentially institutionalize roles I never wanted us to play:
  • Every user story needs to be ‘signed off’ or ‘QA Accepted’ by my (Test) team (IMO should be the role of the product owner or project manager or by the Agile Team)
  • My Team becomes ‘gatekeepers’, where stories or issues needed “QA” sign-off before being released
  • So we’re now supposed to do more checking rather than testing?
I immediately raised this issue to my new boss to propose the change from “QA” to “Testing”, where workflow transitions end with “Testing completed”. This should communicate clearly that:
  1. Everyone‘owns’ quality;
  2. The Test team cannot and does not assure quality; and that
  3. We test, not perform quality assurance
What did I get?
I agree. “Quality” starts with the gathering of requirements and should be part of everything we do from then on.
Great boss.
What’s your thoughts on testing vs. quality assurance?