Problem Test Estimation:

Estimates

Problem Test Estimation

This is a short paper on what I have learned from doing test estimates. It is not just a case of thinking of a figure, doubling it and adding on a bit for good measure. While this paper focuses on testing, there are some lessons here that could be applied to all estimation.

I have found testing professionals to be particularly bad at giving estimations (I include myself in this group).

Some of the more common excuses are:

  • I don’t know how long testing will take as I don’t know how many defects I will find.
  • I can’t say how long it will take to test as I don’t know how much regression is required.
  • I don’t know how long it will take to get the environment/data set up.

Good points

Below are some points I have picked up over the years that have helped me.

  • Understand the expectation – When you are asked for an estimate the person asking usually has a view themselves. So, you should have the conversation in their context. For example, does the asker have a date they are being pushed to work towards?
  • Never give a date – If you are asked to give a date when something will be complete or delivered, don’t. Or, have your industry standard guidelines on the ready.
  • Give all estimates in effort – You should always work in effort, the units of which will depend on the project. Typically I would expect hours or days. Effort is the amount of time it takes you to do a task without any interruptions. I don’t talk about story points here.
  • No task is ever 100% allocated – During any work day there are other things that take your time, for example, meetings, ad hoc conversations, coffee etc. It is not unreasonable to allocate tasks at 80%. This will turn a 5 person day effort into 6.25 days duration.
  • Start with the deliverable – Always start with what it is that you must deliver, then allocate all the tasks required to produce that deliverable, including tasks to be done by other people.
  • Split Tasks – No task should take more than 3 days. If it does, split it in two. If you want to keep a task longer than three days it means you can’t have contingency.
  • Parallel and Sequential Tasks – Some tasks are required to be run in order while others can be run in parallel. Clearly, tasks that can be run in parallel usually require two or more people to execute them. Be clear and highlight the dependencies tasks have before they can be executed. Plus, be clear if you have dependencies on other people, they may not be allocated to your project.
  • Contingency – Add contingency at the task level. Tasks you know little about should get contingency up to at least 50%, and tasks you know and understand well should have 0% contingency. When a task finishes, you can’t carry the contingency.
  • Use rules of thumb – Estimate top down, for example, test effort is 40% of the development effort. Then compare to the bottom up (points above). If they are very different make changes as you see fit (use your gut). If you know the project, usually your instinct is correct. These rules can also be applied to the number test execution cycles, amount of regression and number of defects.
  • Best and worst case – The best case will be the effort based on percentage allocation and no contingency, the worst case will be when the contingency is added in. As you work through you project your final date should land between best and worst case.
  • All estimation is wrong – All estimation will be incorrect as you did not have all the information, you forgot something, or something unexpected happened. The key is to constantly review and update, estimation should be done throughout the project.

Exactest is an independent software test consultancy providing software testing solutions to quality concise and market driven clients utilising experienced test professionals and innovative technical solutions.