POOR SOURCE CODE QUALITY

Lack of identification is inevitable during functionality testing, even if there has been thorough unit testing during the development phase. Usually, in test management, the test manager comes out with the test approach, scenarios, conditions, cases and scripts, to complete the functional testing of your project. Their test plan should cover all of the requirements that are agreed to be delivered. The test manager will plan several cycles of testing. Starting with a full suite of functional testing, followed by successive cycles of testing defects from previous cycles, along with regression testing of the existing functionality, to make sure the fix made by the team did not impact already tested and proven modules.

There is a huge risk to timely delivery if a high volume of defects inflow is identified by the testing team of a project. There is no industry standard for acceptable defect volumes, but, if you see a large volume of critical or high priority defects, then as a project manager, you have to revisit your development team’s quality assurance procedures/processes.

Root cause analysis
Any defect identified by the test team has to undergo root cause analysis that undermines the basic cause of the defect. A defect could be at the code, design, environment or even a requirement gap; you will have to focus on the prime factor for the defects and take appropriate measures, such as revisiting your process, tightening the review process, or adding more unit testing.

Re-opened defects
Re-opened defects are a bigger challenge. They are the defects that are fixed, or claimed to be fixed, by the team, but tests prove it to still be open, and the test team has to reopen it. This could be due to lack of testing on the developer’s side, or delivery of a wrong version of the code.

Defect fixes create more defects
There are situations where a defect fix opens up newer defects during the testing. This proves that the development team has not performed proper impact analysis and has failed to perform end-to-end testing.

Add penalty clauses for such scenarios (such as re-open defects, defect fixes create more defects) in the development team’s contract, so they will be more careful with their delivery.

One bright side of the problem is that we identify defects and issues earlier with the test team’s help, rather than facing them after go-live.