Guest post by?Jennifer Bedell
It is cheaper to find defects early in the project’s lifecycle. But how early can we start?
We usually create a project plan that allows testers to be involved before the actual testing phase. This allows them to review the requirements and to create test cases that can be?executed during testing. What happens if the tester finds a gap in the requirements? They will ask for clarifications and update their tests accordingly. But is this tracked?
Unclarified or incomplete requirements are the main reason for project delays. We still struggle to justify additional analysis time. People want to see the results quickly so we don’t rush into the development phase.
If we track the questions about the requirements in the same way that we track defects with the software, then we’ll likely find the root cause of many. The requirements are what causes “defects”, not the code. It is the code that must be fixed, as it was based upon requirements that may not have been fully met.
By reporting on the root cause of defects, we can identify the ratio of requirements?defects?to code defects.? These data can be used to show the importance of allowing enough time for analysis, formal walkthroughs and requirements reviews.
This may seem to slow down progress at first, but the advantage of identifying potential problems early will reduce the need for rework later in the project’s lifecycle.