Niels Malotaux is an independent Project Coach and expert in
optimizing project performance. He has over 40 years experience in designing
electronic and software systems, at Delft University, in the Dutch Army, at
Philips Electronics and 20 years leading his own systems design company. Since
1998 he devotes his expertise to helping projects to deliver Quality On Time: accurately
predicting what will be done when, delivering what the customer needs, when he
needs it, to enable customer success. He also teaches testers how not to delay
delivery. To this effect, Niels developed an approach to effectively teaching
Evolutionary Project Management (Evo) Methods, Requirements Engineering, and
Review and Inspection techniques. Since 2001, he taught and coached over 400
projects in 40+ organizations in the Netherlands, Belgium, China, Germany,
India, Ireland, Israel, Japan, Romania, Serbia, South Africa, the UK, and the
US, which led to a wealth of experience in which approaches work better and
which work less in the practice of real projects
No Questions, no Issues. Period!
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.
Recognizing and understanding Human Behaviour helps QA to do a better job
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.
Help! We have a QA Problem!
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.
Examples how to move towards Zero Defects
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.
Inspection used in various ways
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.