Test estimation is a forecast of the projected cost and duration of testing which is agreed upon between the testers and enterprise which requires testing. It is a means for discerning information which will need to be fed back in to the business. It is often said that testing is a Risk Mitigation exercise, but as the testing process itself cannot mitigate risk, it would be a truer statement to describe the testing function as a tool by which the business gleans information enough to mitigate risk. It’s likely that most of those reading this white paper will fall into the bracket of estimating in accordance with what should be done as a set of testing tasks. This is not incorrect; however, to only consider testing estimation against what one believes to be the correct list of testing tasks and depth of testing is an incorrect way of approaching test estimation.
Bearing in mind the previously-stated definition of risk mitigation (“the testing function is a tool by which the business gleans information enough to mitigate risk”), it is clear that estimation is guided by the business more than our own thoughts, and the following statement describing estimation becomes true: “Deciding the means in which the correct information can be provided to the business in order to mitigate risk.”
When a tester is asked this key question by a manager, all of the following things are going through their mind:
All of these questions are asked because management needs to form a project timeline and understand how much it will cost. The tester’s response to these questions should include the following:
All testers will want to do as much testing as possible. In the eyes of a tester, a product or solution is guilty until proven innocent; given the mantra that testing can’t test everything, testers tend to want to test whatever they can in as much depth as possible for as long as possible. This is probably directly at odds with what the business wants which is ‘the correct answers and information as quickly and cheaply as possible’.
Taking this point of view into estimating, the person starting the estimation process needs to first question the business on what the testing service is required to be. To understand this, a tester may want the following information:
In essence, the tester is discovering what it is the business wants so that they have an idea of what will be accepted and what will require further negotiation. Understanding the answers to questions like these will set the scene for what the expectations of the business are and will also provide a scheme for the estimation and negotiation process.
Let’s assume that you’ve asked the questions and you know what the testing service is expected to deliver in the way of messages. You’ve taken this away and generated an estimate with very clear boundaries between what answers the expectations of the testing service and what provides good and effective testing. How should you negotiate?
Negotiation can be considered a form of sales; there are a number of key phrases which a sales approach to negotiation should encompass:
Pre-Estimation – Getting to know the internal client
It is first important to get to know the project team and establish some trust. Get to know those around you and develop the information that shares the value you bring to the organization.
Pre-Estimation – Getting to know the testing service requirements
Understand the stakeholders’ needs and motivations. Discover what the testing service needs to be.
Post-Estimation – Selling against the requirements and the advantages of additions
Highlight the benefits and advantages from the estimation outputs. How is this meeting the testing service requirements? What would additionally enhance the service and add real value?
On-going – Remaining in sync with the business
Keep engaged with the project and management and adapt the testing service when required.
It’s important to recognize that the negotiation process is much longer than just the period of trying to get people to listen to what you think needs to be done. If negotiation starts with Advocating, the business won’t know you and therefore won’t trust you. You will likely offer so much that you’ll be told to go back to the drawing board and cut it all back. This not only appears unprofessional but will undermine your authority; convincing your client of the wisdom of your choices will now be an uphill struggle, because they don’t necessarily believe that you know what you’re doing. Similarly, if Supporting is not carried out, the test service will quickly be over-run by ever-changing goal posts and project managers disillusioned by the testing services’ ability to deliver the right information at the right time.
This brief discussion of test estimation and negotiation has hopefully brought forward a few key messages and given some food for thought about the reader’s own methods of this process. Hopefully this methodology will provide useful next time you must estimate testing efforts and attain buy-in to allow testing to proceed. Please keep the following in mind:
