Most of us are aware of the Boehm-curve which explains that finding defects in an earlier stage is cheaper to solve.
I'm sure there are lots of arguments available to stick to this statement. Unfortunately I noticed that a lot of testers are using this argument to test almost everything. They are extending the test phases. They are giving advice not to ship the software to productive systems as there are lots of risks.
There might be a slight difference between newly build software and software under maintenance. The major thing is that software becomes bad not because the number of issues which are in the code, it becomes bad because the functions, framework which comes with the code is not providing enough service to make the business using it.
Even with bad software people can work. As long as the benefits of earning money with that code is more then it would cost to solve issues immediately it might be worth to ship and use the software.
For example: to withhold software to use, you are not able to gain money which supports the business case. If you delay the system with a few months, are you not loosing you competitive strength or loosing the money you intended to make? If you are able to identify the strong and the weak points in the software, if you are able to explain what and how to use it and you are still able to make the money based on the services you are able to deliver now, why not ship it?
Finding issues might be cheaper to solve in earlier stages, only you need first the ability to make money before you can extend the project to find and solve everything. I can imagine that is the system is mandatory to continue the business you are also willing to accept the risk of having issues in the system. It is more important to be able to act promptly when issues becomes problems.
I would rather suggest instead of claiming it is cheaper to find issues earlier and therefore continue testing, be honest and ask yourselves if you are able to provide information on which clients can make there decisions. Don't fall in the pitfall to claim that this can only be told based on coverage. If you are able to explain what you have done and how you see the system and what you didn't do and you have faith in you and your team. You already made a huger step then speaking about coverage. If you are able to tell what functions might possible cause risk and how you are tending to monitor it and you are able to help fixing it within time you are more capable then telling you tested well and give negative advice as there are issues which might bother some people.
It might depend on the development method you choose and the organization who stands behind you if this can be successful. I noticed situations were it was cheaper to ship products with some issues or some risk. Money was made immediately instead a few months later and the issues which were found in the first days were faster solved and tested then during the normal test project.
So it finding defect earlier cheaper to solve? Yes, is it cheaper to withhold the system to go production? I think most of the times we have to rethink the verdicts before making our statements.
The End of Search as We Know It
2 days ago
Jeroen,
ReplyDeleteI think you are missing a key point of Boehm's work in this area. The "cost" associated is that of "rework". The later you go in the cycle the more expensive it is to rework the product. BUT, this is dependent upon when the issue/defect was introduced (which phase) and when it is discovered and resolved. The amount of "rework" is really what Boehm was getting at. The associated cost of having to go back and redo the work can become quite prohibitive in later parts of the cycle or after the product has been released.
What Boehm was getting at is that the prevention practices (reviews, initial involvement by Test group) need to start earlier in the project cycle in order help contain the cost of rework during the various phases.
And at times it is better to hold the release of a product if the financial impact of rework and loss of revenue (you release crappy software anyway it will cost you in lost credibility and loss of customers) could outweigh those of just shipping the thing.
Hello Calkelpdiver,
ReplyDeleteYou have a good point about the association about costs of rework. I don't want to judge that. What I see often is that testers are bounding the hands of the clients with arguments that it is cheaper to test now and accept the delay.
And of course there are a lot of errors/issues which must block the shipment of software to productive environments.
In my opinion there are more arguments you have to look for instead of repeating the words persons learned during courses about cheaper to find issues earlier.
For example, I did a project were we tested about 70% of a certain functionality, we noticed that there were some “blocking” errors for the remaining part. Only based on the 70% which was working, money was retrieved from customers. This allowed the project to gain extra budget for solving the remaining issue(s). Next to it, as they were isolated issues, the User Acceptance Test was not done from start.
With respect to Boehm, yes issues alone are cheaper to solve in an early stage. If there is money and time to do this. If not, it is large price you have to pay if you don’t ship because of the issues which are found or not.
regards,
Jeroen