Once we deliver the software to users, we’re not there to answer questions or solve problems when they occur. It should simply work without problems. When introducing the concept of Zero Defects, one trick used is the challenge that at the final test there should be “no questions, no issues”. If the testers would have even just one question to ask or find even just one issue, the test is to be aborted as failed. My experience is that in no time the quality of the deliveries improves dramatically.

In my work as a project/team/organizational coach, and sometimes as a ‘flying QA person’, I found that recognizing and understanding human behaviour is important to do a better job.

Better than trying to change that behaviour, I accept it, as we cannot change the genes, and try to see what we still can do to mitigate the risks that some human behaviour traits can pose for the successful results of our work.

In this session I want to share some of my findings with you, expecting that it can help you in your work as well.

We’ll talk about discipline, intuition, communication, perception, politics, excuses, and some more, illustrated by several cases, including a case with a development team in Minsk.

This is about a real case of too many developers feeding too few testers, causing a testing backlog of half a year, with many angry customers waiting for too long for solutions to their problems. One senior tester just had left the company. There was only one senior and one junior tester left. They were facing this huge backlog of work and didn’t know where to start.

We’ll show how empowerment of the testers, careful planning, and involvement of the developers allowed the testers to catch up in about 9 weeks, systematically making customers happy one by one along the way. The senior tester learnt how to plan the work of the testers effectively and efficiently in sync with the developers so that there were no backlogs ever since. Trust by customers who were in the process of abandoning the supplier was restored causing a turnover to grow enormously since.

How many defects should the users of our software find? How many issues do you accept the users to experience? If you agree that it should be “Zero!”, then we can discuss how to achieve that. If you think it’s impossible, better attend and learn, to avoid being put out of business by those who are delivering Zero Defects.

Some people think that we can produce better quality by better testing. Wrong! The most economical way to produce quality is by preventing any problems to creep in in the first place, making sure the users don’t experience any hassle. We’ll discuss a few cases where we used techniques that helped people move towards Zero Defects, like: design, review, the DesignLog, short-circuiting, and using “No Questions, No Issues” as a final test requirement.

Zero Defects is often is dismissed as an impossible dream. My experience tells otherwise. It doesn’t mean “turning a switch and then we don’t produce bugs anymore”. What it does mean you will find out in the presentation.

People who Review or Inspect code or any other document, without proper training don’t find many issues, wasting time, and missing the quick learning of how to prevent introducing issues in the first place. Furthermore, Reviews and Inspections can be used in even more ways than ‘just reviewing’ and ‘just finding bugs’.

In this session we will see some cases of using Reviews and Inspections with various unexpected and interesting outcomes:

- The review caused a redesign

- The review caused not to implement at all

- The review caused the document to be discarded as completely useless for its purpose

And we will see how Early Inspections can feed prevention even faster.

This will give you more flexible insights of applying Inspections to improve the quality of your software, which will lead to better Quality On Time: delivering better results, spending less time. For those who thought that Inspections only waste time, this presentation may give a fresh stimulus to reconsider.