The quality? Oh, we test it in! (part 2)

Who is actually responsible for the quality? To answer that question, I ask myself two questions: what is quality? And what is responsible?

Quality is a difficult concept. In training on software testing I often ask the question: “is the coffee any good?” I get the most diverse answers. Some answer: “for coffee from a machine, it is doable”. If someone says, “horrible!” my response would be: “Why do you drink the coffee anyway?”. A nice discussion about the concept of quality. Quality is value to someone (who matters), at a given time. So the coffee, even if it is not really good, can still have value: for example, to wake up/stay awake! So the coffee has some quality for someone who wants to stay awake.

The other topic is responsibility. Who is responsible for the software? Anyone who ever worked with a RACI matrix, knows that there are different “types” of responsibility. Responsible and Accountable, which in Dutch both can be transleted in “verantwoordelijk” (responsible). In this context, I look at the question: who is responsible for the quality? The project (or project board) for its production. But what about the rest of the team?

Andreas says: “A nurse in hospital is still partly responsible for welfare of patients? Not just the doctor. An inspection department at Unilever is responsible aren’t they? Not only the people behind the machines?”. The example of the doctor and nurse is a good example. Of course the nurse has responsibilities. To nurse the patient as directed by the doctor who suggests a diagnosis and treatment. Each profession has task and are jointly accountable. Not responsible for the health of the patient! They should do the best possible in their profession. But if a patient decides to leave the hospital during treatment, it is his choice! Similar to: if the customer decides to ship the software. In spite or because of the results of testing.

I totally agree with Jan Jaap saying: “many testers are limited ….” and “testers of all companies: broaden your horizons!”. Testing is definitely not just a plan, case writing, execution, reporting. It can and should be much more. Only the purpose of testing, I would like to formulate it differently. Not “contribute to the project objectives with a focus on quality“. I’d rather go for the definition of Cem Kaner, “Software testing is a technical investigation for the purpose of revealing the quality of a software product on behalf of stakeholders.” or the shorter definition of Jerry Weinberg: “Testing is gathering information with the intention of informing a decision”. The goal is to provide information! And thus helps the tester actually contribute to the project goal.

In early quality measures, I also recognise quality reviews, inspections, etc. But here is much more than just working on documentation. I think of: pair programming, help unit testing (improvement), improve testability by asking for logging, acceptance criteria drawn up by acceptance tests (even before fully written requirements and specifications). And there’s so much more testers can do.