From software testing help
Effective Defect Prevention Approach and the 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 simply is testing or Quality control) but also include 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 sounds 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 the prevention measures are taken, the better. Besides, defect prevention also helps companies achieve the highest CMMI (Capability Maturity Model Integration) Level.
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 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 or BA or client) to make sure that all the 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 directly get involved in this phase, but the review does go on here too. Developers carry out code inspections, walkthroughs and reviews before they unit and integration test the application.
Defect Prevention Methods and Techniques
Some traditional and common methods that have been in use since a long time for defect prevention are listed below;
#1) Review and Inspection: This method includes the review by an individual team member (self-checking), peer reviews 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 as to find which 20% of the reasons attributed to the 80% problems. By simply focusing on those 20% reasons and eliminating those, 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 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 effort at various stages which is the reason 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:
- The staff gets motivated and are more aware
- Customers 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 the defect database which includes the collection of defect data.
- Defect data must be updated at regular intervals and defect info should be kept current at all time.
- To plan the implementation of change
Client's 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 process. It helps manage the quality of the software product in a “sooner and cheaper” manner with the help of the techniques listed above.
It ensures that the problems get resolved early on without even making it to the application. It considers root cause finding as its primary means of identifying and eventually removing issues.
To maintain the quality of software is the responsibility of the core management and entire team including project lead, client, and every team member.
