On estimation of testing activities
I, like many others am being asked for an estimation of time on how long it will take to complete testing activities for each thing I am testing. In the past, the estimations were made and were not used for anything except to mark velocity on a burn down chart. Naturally the line for programmers and testers were widely different and the question of ‘how can we bring these together’ was frequently the topic of conversation. My answer was for programmers to develop in small testable chunks that someone can test simultaneous to the development of the next chunk (testable thing). Well, this never truly caught on and the lines remained far apart and at some point I was no longer asked for estimations.
I do not having a problem with making estimations, my issue is that the tester will be forced to commit to her / his estimation and be held accountable to disparity between the estimation and the actual time required when that person is in very little control of the disparity.
The argument that test estimation should be done is that ‘if programmers can estimate, then so can testers’. Creating a piece of software is a finite task, you stop when what you have built satisfies the customer. Testing is a service to provide information about the current state of a piece of software. In my opinion, the tester is done when the information they are providing or the artifacts of their activity stop being meaningful to the person representing the customer. Or in other words, it doesn’t give them any additional insight into their questions about the product. This means we are in effect being told to estimate when a certain emotional response will be elicited.
This might be possible assuming that the things a person was testing were received in a similar state each time and everyone had the exact same understanding of what was being created and that understanding is equal to the customers’ desires. As we are human and fallible, this is very unlikely to happen and so estimation becomes very haphazard and inaccurate.
A scenario: A tester estimates a feature will take 8 hours to test. The tester receives the feature and begins testing, noting several issues along the way. Some issues are fixed that cause regression in parts of the feature that previously worked. Over a period of 2 weeks the product manager checks in periodically to see the state of the feature and each time says the feature is not ready. Has the tester missed the estimation?
I think that Michael Bolton’s assertion that estimation for a tester is really a negotiation is the most correct way to address this problem.
So, I will make estimates to the best of my abilities. But I do not understand what purpose they will serve and I do not want to be held accountable in any way for the disparity between the estimate and the actual.