Quality Intelligence - A summary of my approach to QA in the last couple of years

Hello everyone,

I thought I would share some thoughts and concepts that I have been developing in the last couple of years.

It all started with me thinking that the QA acronym was misrepresenting what QA Specialists or testers were actually doing, whether it meant Quality Assurance or Quality Assistance.

QI, not QA: QI, not QA

I then tried to summarise the core concept in a presentation.

What is QI?: What is QI?

And after this I developed and expanded on a few different aspects.

On transparency and visibility: Quality Intelligence: Transparency & Visibility

On test coverage: Quality Information Coverage - A QI Concept

On quality ownership: Signing off on Quality

On bug backlogs: The Bug Backlog - An Evergrowing Mountain

And I also wrote a longer piece, connecting the QI concept with how to develop high quality software: Building High Quality Software

Maybe it can be interesting for someone, maybe not. Hope it adds some value at least.

Best regards,

Johan

3 Likes

Love this @johan.hoberg . You’ve put into words and pictures what I’ve had in my head for a long time. A fantastic perspective on quality and I love the term Quality Intelligence.

2 Likes

I agree with your discomfort about the terms Quality Assurance and Quality Assistance
I think the best answer to β€˜what does QA stand for?’ is Question Asker

  • In the early stages of development, we ask questions in backlog refinements to ensure that requirements are robust and complete
  • My favourite way of test planning is in the form of questions about whether the product fulfills requirements and what it does in various tricksey situations
  • During testing itself, we need to remember to question our own assumptions
  • Exploratory testing is all about thinking β€˜what would happen if…?’ and then finding out the answer
  • Even when we report on test results and quality, you could see this as an implicit question: Given this information about the state of the product, what comes next? Is it acceptable for deployment, or do we need to do more work?

(It also sometimes stands for Question Answerer, as testers are often the most knowledgable about the detailed behaviour of the product)
In general I think Question Asker makes it clear that we are not directly contributing to quality, but our presence keeps everyone on their toes and uncovers all sorts of things that would cause problems later on

This topic was automatically closed after 730 days. New replies are no longer allowed.