You may wonder why this blog's title is not 'RoI of testing'. RoI approach is defensive and retrospective and answers the question 'why do I exist?' It is a mathematical justification and is relevant during early stages in the maturity cycle of a business function. RoI has the connotation of a cost center and not a value center.
In contrast the business value approach is proactive and asserts 'I exist to provide these values' and upfront states those values to the business. This approach is relevant when the function is mature and proven and does not need any further justification for existence. One can then go beyond justification to qualitative linkages to value.
Does testing activity need any justification for existence? I think the answer is clearly no. Let us then examine the business value of testing.
Testing by very definition adds zero functional value to the system under development, but is expected to assure that the right value is delivered to the business. There are three value elements delivered by the testing function. I outline these values and key strategies to be deployed to realize those values.
The first value is that of delivering assurance. Testing delivers assurance of business purpose readiness. In case of IT systems the business purpose is production deployment and testing thus assures deployment readiness. In case of products testing, it assures market launch readiness. So, the final outcome of testing is an assurance of a specific business purpose readiness. The business and IT relies on the testing function to provide this assurance. So testers don't really deliver test cases or test execution. They deliver assurance. Test cases are tester's consumables and not the end goals. A key strategy to realize this value is to ensure that a business process linked approach is adopted while estimating, designing, executing test cases and analyzing test results. Also, testing activity can never guarantee absence of defects (absence of evidence does not mean evidence of absence), but must assure that key risks are covered so that the probabilities of high cost failures are eliminated. Risk-based testing strategies thus play an important role here.
The second value is agility. Time constraint is a reality whether you are running a product organization or an IT organization and the expectation is that the cycle time and cost of assurances are kept low. Testing is a downstream activity and by the time the system is 'ready for testing' the upstream folks (the developers!) would have probably eaten away a major share of the planned schedule. Many a strong willed test managers attempt to 'push back' to obtain more time but to no avail. It is the constraints that prevail! It is not so much about 'how much time we need for testing as 'how much time do we have for testing'! An ideal situation is when testing cycle time becomes less and less sensitive to scope changes. The key strategies in realizing the value of agility are extensive use of test optimization techniques, use of test accelerators and usage of rapidly deployable test artifacts. Risk-based test strategies may also help in optimizing cycle time.
The third value is that of playing an advisory role in program management. Routine defect analysis does provide some indication of the quality of the system as on date, but not enough value is given by the program team. The testing function should play the role of a navigator in the journey towards the final purpose readiness milestone which implies data analysis with a view to provide risk assessment of meeting the final milestone of purpose readiness. In addition, recommending strategies to mitigate risks of meeting the final milestone is expected. It is possible to deploy structured dependency analysis techniques to assess the priorities for fixing of defects, so that the overall defect fix effort and time are drastically reduced. I remember a case where there were 30 major defects but fixing just 5 of them automatically closed the rest since there were functional dependencies, which were not very obvious but came to light through structured dependency analysis techniques.
To completely and truly realize the above-mentioned values, testing should be seen as an independent business function rather than just a mere phase in the software development lifecycle. Recruitment, training, capability building, budgeting, managing and reporting should reflect this perspective.
