Better to reduce the bugs than to fix them

The idea of testing software reminds me of this very famous old saying “Prevention is better than cure”. The simple reason behind it is the fact that there is always high cost associated in fixing the defects. At a primary level,two things can be thought of (i) either avoid the occurrence of bugs altogether or (ii) identify them at the earliest.

I  would like to focus on some most common causes that are responsible for defects in any application and which if address properly can surely help reduce the number of defects significantly and lower down the overall cost of fixing them. Some common facts are as under-
• Improper or ambiguous documentation related to requirements/ Misunderstood requirements/ Gap in understanding those requirements (Business user- Developer- Tester)/ Discrepancies across various requirement documents like BRDs, SRDs other mock ups etc
• Introduction of changes at various stages of software development and lack of proper change control management and not proper impact analysis of those changes
• Inadequate time to develop an application
• There are few more like poor design and coding, involvement of human factor in developing an application etc.

An early start seems to be a good tactic in this regard from testing point of view. We should try going in for an iterative approach, which means testing should be done throughout the project. It will help uncover defects as early as possible. Moreover addressing the above mentioned causes results into achieving the desired goal.

Requirement gathering and analysis should be extended a bit further and emphasis should also be given on getting the proper, accurate and ambiguity less documentation for requirements. Use of some special artifacts like a traceability matrix may help significantly where requirements from all the source documents are noted and discrepancies can be revealed. This gap analysis helps get the refined and properly redefined requirements from the business.

Changes, though are inevitable, but can be managed more significantly. A proper impact analysis should be done. This is a time when already written test cases needs to be revisited and needs to be modified. The impact of the change should be understood by QA and developers both and should be reflected in their test cases and code respectively.

Most of the times, when delivery schedules are hectic, it is a good idea for QA and developers to have common discussions on functionality of application and QA should share their test cases and all the identified scenarios with the fellow developers. This will help them cover all possible scenarios in their code in the first go.

QA’s role need to be redefined as a part of winning strategy in today’s competitive environment. They need to go beyond the technical aspects and should also emphasis on subject matter i.e. domain knowledge. It will help touch the more realistic aspect of the business that seems to be not so obvious otherwise in their testing. It will eliminate the chances of real time bugs significantly in preliminary round of testing only. It would also be helpful in analyzing the requirement more effectively.

And of course an iterative approach for testing- This allows us to find defects as early as possible, which radically reduces the cost of fixing the defect.