Techniques for software defect prevention and identification
A quality process should produce close to zero-defect software that meets the user requirements. In this article, we will go through step-by-step, the various practices/techniques that can help you prevent defects in your software, and how to catch them if they already exist.
Understanding Customer Requirements
When a customer provides you a requirement, it’s not that you start working on it there and then (Figure 1, below). You first need to understand clearly what the customer wants.
Once you have gone through the requirement, put down what you have understood. Then, get your understanding confirmed from the customer. Doubts, if any, in the requirement specification, must be clarified at this stage. Do not procrastinate or hesitate in asking your queries.
|Figure 1. Requirements work flow|
While working on the development of system software tools, I have seen many defects creeping in due to misinterpretation of the requirement specification. Fixing such defects at a later stage can prove costly. So, it is very important that you get your understanding verified from the customer.
Functioning as a team is a skill. Delivering a high quality product is no responsibility of an individual. It's the entire team who is responsible for it. If the product fails, each team member is responsible for it.
Review is an important part of team work. Peer Review refers to participation of team members in the development and assessment of task/activity performed by an individual.
In this process, illustrated in Figure 2 below, a team member requests an artifact to be reviewed. The other team members then provide their review comments which may include corrections, suggestions and doubts on the artifact.
The artifact is then updated based on the review comments. This process is repeated till the artifact is up to satisfaction of all the team members. Of course, in case of any conflict it is the Project Leader who makes the final judgment.
|Figure 2. Hunting for Artifacts|
Reviews are critical at the following stages of software development:
a. Requirement Specification Review . As we discussed in the last point, understanding the customer requirement is very important. So, while you prepare the Requirement Specification, get it reviewed by your team members. Ten people in a team may have ten interpretations of the specification. Discuss it out within your team, and then pass your understanding to the customer for verification.
b. Design Review. Once the requirement specification gets finalized, we move on to the design phase. In the design stage, you would now think about how to approach the problem.
As you will agree, review at this stage is vital. Selection of a wrong strategy can put the entire system in a miserable state. Reviews performed at this stage will help you in:
*Analyzing various strategies to solve the problem.
* Analyzing feasibility of each strategy.
* Knowing advantages/disadvantages of each strategy.
c. Code Review. Code Review involves examining the source code to find defects. While working on development of system software tools, I have been a witness to how code review can really help you find defects.
It is good to let someone in your team walk through you code, and do the review. All the members must review the code changes with respect to other modules and give their feedback in case some side-effect is suspected.
Many defects such as memory leaks, wrong passing of arguments, unreachable code, lack of readability, high complexity and maintainability issues can be identified via code review. Finding defects at the coding stage, and fixing them there and then, would prove to be less expensive than finding them in the testing stage.
Currently no items