Defect Prevention Strategies & Techniques in Software Testing

Here is an article on effective Defect Prevention Approaches and Critical Views:

Quality Assurance is the term that is commonly used to address the testing teams in IT projects.

Technicalities aside, quality assurance activities are not just targeted at defect identification (which is finding defects after they have happened). This is simply testing or Quality control. But it also includes defect prevention (making sure the defects do not happen in the first place or the defects are removed/reduced before making their way into the software product).

A simple equation equivalent can be:

QA= QC (defect identification) + Defect prevention

Although this looks fairly simple, there is less emphasis or direction available on how or what exactly are defect prevention tasks.

The truth of the matter is, defects found during the testing phase or worse after release are costlier to find & fix and might cause a loss of trust on the brand. Hence, the earlier prevention measures are taken, the better. In addition, defect prevention also helps companies achieve the highest CMMI (Capability Maturity Model Integration) Level.

In this article, let’s take a closer look at defect prevention.

Defect Prevention

Defect Prevention is a crucial step or activity in any software development process and as can be seen from the below diagram is pretty much half of our testing tasks:

In brief, the following are the defect prevention responsibilities for testers in each of the below stages:

#1) Requirement Specification Review:

After understanding the customer’s requirements, prepare your requirement’s gist.

A review is important at this step – the first level of review should be within the team, followed by another level of external review (by a dev, BA or client) to make sure that all perspectives are in sync.

#2) Design Review:

Design stage can be considered a strategy stage of sorts and going through it will ensure that the QA team understands the pros and cons of each strategy.

This kind of critical walkthrough will help unearth any problems with the said strategies and fix them before going further. This can be considered a feasibility study for the strategy (or strategies).

#3) Code Review:

There is not a lot for testers to get directly involved in this phase, but the review does go on here too. Developers carry out code inspections, walkthroughs and reviews before the unit and integration test the application.

Defect Prevention Methods and Techniques

Some traditional and common methods that have been in use for a long time for defect prevention have been listed below:

#1) Review and Inspection: This method includes review by an individual team member (self-checking), peer review and inspection of all work products.

=> For more information on how this is carried out, please check our Test Documentation Reviews article.

#2) Walkthrough: This is more or less like a review but it’s mostly related to comparing the system to the prototype which will give a better idea regarding the correctness and/or the look-and-feel of the system.

#3) Defect Logging and Documentation: This method provides some key information, arguments/parameters that can be used to support analyzing defects.

#4) Root Cause Analysis: Root cause analysis includes two major approaches:

I) Pareto Analysis:

Pareto analysis is a formal and simple technique which helps prioritize the order of problem resolution for maximum impact. It states that 80% of the problem arises due to 20% reasons.

Therefore, the problems once identified are prioritized according to frequency and a detailed statistics based analysis is performed to find which 20% of the reasons attributed to the 80% problems. By simply focusing on those 20% reasons and eliminating them, results are guaranteed while optimizing the extent of work involved.

II) Fishbone Analysis:

Also known as Ishikawa Analysis, this method is a more visual root cause analysis technique. There are no statistics involved as this method is based on team-wide brainstorming. The following diagram helps you understand this better.

The problem is first written on the rightmost side and on the horizontal line that passes through it, the various causes are listed. The branch that has the most cause-subclause bones (or lines/branches) is the problem that is most serious and that is to be worked towards elimination. This technique is also sometimes called cause and effect analysis.

TMM Level and Defect Handling by Test Organization

#1) TMM (Testing Maturity Model) is based on CMM i.e. Capability Maturity Model.

#2) Defect Prevention involves many staff members and their collaborative efforts at various stages, which is why it plays a prominent role in TMM level 5. e.g.; If a defect occurs frequently in any test case or procedure, the organization might allocate a group of staff members to analyze the defect and develop the plan containing actions for changes in the process with the problem.

#3) Some of the benefits of the defect prevention program are as follows:

• Staff get motivated and are more aware
• Customer satisfaction
• Increased reliability, manageability and predictability
• Enhanced continuous process improvement

Team roles and responsibilities

Three critical groups are involved in the process of defect prevention:

Manager’s Role: 

• For the success of any defect prevention program management must be strongly supportive.
• The support can be in the form of resources, training, and tools which are required to implement the plan successfully.
• Management should define the appropriate policy and should make some cultural changes if necessary.
• Managers are supposed to promote discussions, distribution of common defect list and changes in the process.

Tester’s Role:

• Testers maintain a defective database which includes the collection of defective data.
• Defect data must be updated at regular intervals and defect info should be kept current at all times.
• To plan the implementation of change

Client Role: 

• The client plays a comparatively small or limited role but their commitment towards quality is critical.

Conclusion

Defect Prevention plays a major and crucial role in software development processes. It helps to manage the quality of the software product in a “faster and cheaper” manner with the help of the techniques listed above.

This ensures that the problems get resolved early on, even without making it to the application. It considers root cause finding as its primary means of identifying and eventually removing issues.

Maintaining the quality of software is the responsibility of the core management and entire team including project leads, clients, and every team member.

We would love to know your defect prevention methods. Don’t forget to share your questions and thoughts in the comments section below.