Guest post by Jennifer Bedell
Everyone knows it is less costly to identify defects early in the project lifecycle, but how early can we go?
Typically, we create a project plan that allows for testers to become involved before the actual testing phase. This gives them an opportunity to review the requirements and create test cases that will be executed during the testing phase. But, what happens when the tester discovers gaps in the requirements? Sure, they will ask for clarification and update their tests accordingly, but is this tracked?
A major reason for project overruns is unclear or incomplete requirements. Yet, we still have difficulty justifying additional analysis time. People want to see results early so we move too quickly into the development phase.
If we track the questions asked about the requirements the same way we track defects that are discovered with the software, we will likely find that the root cause of many ”defects” is the requirements and not the code. But, it is the code that needs to be fixed because it was based on requirements that may not have been complete.
By reporting on the root cause of defects, we can identify the ratio of requirements defects to code defects. This data can then be used to demonstrate the importance of allowing adequate time for analysis, formal walkthroughs, and requirements reviews.
At first, this may appear to slow down the progress, but the advantage of discovering potential defects early will decrease re-work later in the project lifecycle.
via Flickr by by Mykl Roventine
Why is it always the developers who get blamed for goldplating? Most people who have worked in a project environment know that goldplating is one of the biggest contributors to scope creep. When you consider that the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly.
But, what if the developers are not the only contributors to goldplating? What if goldplating is also being done by the testers? Considering the cost of change at the various stages in the SDLC, it becomes clear that goldplating by a tester could be ten times more costly than if it is done by a developer. But, exactly how can a tester goldplate?
Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log. While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”. A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality.
Quality is defined as the ability to meet specified requirements as stated by the user. The key in this definition is the user. It is the user’s perception that determines whether a product meets their expectations.
To mitigate the risk of gold-plating by testers, all defects should be triaged by a member of the project team who has a clear understanding of the requirements scope. This person can determine whether each defect is truly a defect related to the current project or an enhancement suggestion for a future release.
