Introduction
Though we hear examples of Zero-Defect delivery in most engineering disciplines, in software engineering, it is generally an accepted norm that such a thing does not exist, at least in business applications. Most IT managers have accepted this bitter truth while businesses suffer, compromising in timeliness and accuracy, apart from cost of rework.
Actually, unlike such belief, a Zero-Defect remains very much a possibility and can be caused. This article briefly talks about ways to achieve a Zero-Defect Delivery, more often than one tends to believe.
What is Zero Defect Delivery?
“Delivery is defined as any goods (commodity) or service that passes ownership from one to another and the other acknowledges receipt of the same”. In the context of Information Technology such goods are software - products or custom applications.
Zero defect delivery is that delivery that completely conforms to specifications. Or, the delivery meets or surpasses expectations clearly stated in an agreed upon specifications. This is true for any engineering goods. When we buy a TV, it comes with product specifications that clearly articulate specifications that can be measured and validated. If it does not suit my purpose, I cannot say it is defective if it meets the stated specifications. However, in the context of software we don’t yet have a language to clearly state the specifications, and we still rely in English. Therefore, correlation of a deliverable in IT seems more appropriate with a tailored suit. Zero defect delivery therefore thus a perfect fit. Any manual work, including software development, is prone to injection of defects. It can be minimized but cannot be eliminated. These defects can only be fixed and reworked. To cause a Zero-defect software delivery, we need to fix all these defects.
Testing is like any sieve; one will always have residual defects in the tested artifact. You would have noted that after a cup of tea is filtered through a sieve, some fines always get through. If the screen is made finer, tea leaves get stuck in the sieve and output flow is blocked. The solution is to put multiple sieves in series, one after another. In software terms, we need to set interim review or test checkpoints (like trial fit of a tailor) in order to reach perfect fit at the time of delivery.
Accidental Vs Intended Approach
Zero Defect can occur just by chance or accidental. During my initial years, I had designed and developed a library management application that did not report any defect, nor required any change for more than 25 years. That was an accident. Later, I reflected and discovered what factors actually caused it to happen! Years later, I led a team to Zero Defect delivery again, only this time by design or intent. Here, I am sharing with you how I achieved it.
ZERO-DEFECT delivery has to be triggered by declaring our intention at the beginning. Let the world know "you want it".
Power of in-phase Reviews - Capturing and stating requirements is the most important task in software development. We are limited by the use of English for creating requirement specifications. Use of Use-Case diagrams, flow charts, state transition and tables minimizes the ambiguity introduced by free style paragraph. Adopting a good template and following it religiously helps capture all essential aspects. Last but not the least, all implicit requirements (Non-Functional Requirements or NFR) must be documented. Precipitate unsaid specifications right at the initial stage, to avoid blunders in design.
Prepare a robust Test Strategy – Defects are there to be found; finding them early, keeps the cost of rework low. Moreover, requirement defects cannot be discovered in any testing before user acceptance testing, if missed in requirement specifications. Strengthening reviews, logging defects – requirements missed, changed or excess (not English grammatical mistakes), considering reverse presentation to business users as a way to validate, goes a long way to assume everything has been considered and captured. Ensure that there are no defects in requirement specifications.
Business Orientation to Test Design - Wearing a business-Hat while designing test cases is a must. No, master detail or table columns here. How can defects be caught without having to go to backend database and how defects leakage can be prevented across SDLC phases, must be the focus of test strategy.
Focused Design Reviews – Design reviews focused on various design considerations goes a long way in discovering defects and thereby delivering high quality software. Traversing the test scenarios on the paper design brings out many design defects that otherwise go unnoticed till systems testing. One leaked defect here results in multiple code defects, more rework, more compromises and hence unstable code. Have a special focus on NFR - The non-functional or unsaid specifications as design considerations.
Compulsory Detailed Design – Aim to Attain absolute clarity for coding in detailed design or design enhancement. This gives a chance for factoring the code. Rightly factored code is easier to reuse, easy to couple with other code components and less prone to defects.
Progressive code reviews in Construction – Progressive code reviews and group reviews are powerful techniques to ensure that developers code right the first time; just as your expert detailed designer has designed. Just-in-time causal analysis and feeding the inference back into the process (coding checklist) helps arrest issue patterns quickly. With a focus of finding defects, code reviews are the easiest way to catch defects. Code reviews should not be delayed to after unit testing as by then, the consequences are already high. Even after knowing that the code is poorly written, it becomes difficult to have it rewritten or even undertake major changes, by then.
Test Driven Development – Tools as jUnit or nUnit are popular and should be used for testing units specially in regression conditions, a fool-proof way to assure stable unit code.
Integration Testing - Healthy entry criteria for code ready for integration testing in terms of very low % of defects must be ensured. Keeping constant vigil on changes in interface signatures, and trapping each error condition distinctly leads to easy diagnosis and quick resolution of integration issues.
Business oriented System Testing – Production environment must be simulated as close as possible; representative masked test data and high test-coverage test cases and sound unit and integration testing leads to quick stabilization of system. Ensuring a strong design and stable code before system testing can ensure this with high predictability.
Zero Defect User Acceptance Test – With the above steps undertaken one can set a ZERO-DEFECT goal here. A business-oriented system testing has already been assured and released for User Acceptance (UAT). By reverse presentation of solutioning of requirements, the surprises that would have waited to be discovered during UAT, have been absorbed already. Now, no further inputs are likely.
Non-Eventful Go-live – Go-Live of such released software is generally a non-event; business As Usual. Ensure users are trained well before planning cut-over.
Conclusion
Zero defects are not impossible. But one must start at the beginning. After all, it is generally common in all other engineering disciplines. Only, we need to ensure an engineering approach is followed, not that like a Mechanic.
References
“Zero Defect Delivery” by Arun Jain, Chairman Intellect Group
“WSO Order Management Project” - Zero defect delivery executed for Polaris for an Engineering Company in Energy Sector in Australia.
Comments