What Is Estimation?
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.”
How Long Will Testing Take?
When a tester is asked this key question by a manager, all of the following things are going through their mind:
- What does testing need to look like for this project?
- How much time is really needed for testing?
- How long would complete testing take?
- What is the least amount of time we could allocate to testing?
- Do we need to test?
- What are the resource requirements?
- What is the cost of the testing?
- What is the value of the testing?
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:
- A person-days estimate including a range of accuracy (+-%)
- Supporting justification for the estimate
How To Start
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:
- Does the business want the testing team to use its experience to test outside the bounds of the requirements?
- Does the business want the test team to provide specialist information (security, performance)?
- Does the business want a test function that delivers messages to all management levels?
- Does the business want a specific methodology to be used?
- Does the business want testing to work throughout the entire lifecycle of the project?
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.
Negotiation
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:
- Phase 1 – Relating
- Phase 2 – Discovering
- Phase 3 – Advocating
- Phase 4 – Supporting
Relating
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.
Discovering
Pre-Estimation – Getting to know the testing service requirements
Understand the stakeholders’ needs and motivations. Discover what the testing service needs to be.
Advocating
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?
Supporting
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.
Summary
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:
- The test function cannot mitigate risk
- The test function must know what the business expects the test service to be in order to be able to effectively estimate and negotiate
- Negotiation starts much earlier than the moment you need buy-in on your testing choices
This content made possible by QualiTest
About the Author
Paul Darby I have been working within software testing and defect management since 1997 within Motor Racing, Public Safety, Pre-Press, Defence and Retail industries.
My testing career has seen me testing on Unix, Windows and Mac environments with heavy emphasis on client/server applications.
I have managed teams of people and the testing life cycle from Inception through to delivery and into the support process. My work has seen me working with teams in both the UK, America and projects in various European countries. I have managed the testing within multiple projects simultaneously extremely effectively.
I have maintained testing environments and run configuration management for these environments. Well versed in testing lifecycles including Waterfall, Agile/Scrum, V-Model and RUP. Excellent working knowledge of Static testing and Dynamic/ functional testing. Good knowledge of non-functional testing such as usability and have led teams of performance and security testers.
I pride myself with being extremely able from planning and stategising testing lifecycles through to writing and running tests.
Specialties: Whilst my security clearance has expired I have carried SC clearance until December 2011 for a period of approximately 9 years.
I hold ISEB Foundation, ISEB Intermediate and Prince 2 Practitioner professional certification