About two years ago, when I was a new software tester in my current company, I started estimating the time I need in performing regression testing on each of the organization’s major products. I wanted to know how much time was enough in order for me to do my tests properly, without rushing and without dilly-dallying, because it helps me prioritize and pace tasks. If asked if I can deliver results after a specified period, I would be able to answer yes or no immediately. If I say I can’t deliver on the initial negotiated time, I would be able to tell my superiors how much more I require to be able to provide the information they want.
For one application, I found out that I have to commit a day, provided that tests are focused, not rushed, without much distraction from everyone else. I got my estimation where I then based all my decisions and made guided expectations. For that product, one day provided enough testing time such that every further project release for that software often went well. There were no troubles in the required testing time. I had no worries in pacing myself well.
That is, until recently. There was a scheduled major release and I told my boss I can finish testing before the deadline but I wasn’t able to, even after giving overtime work. Imagine my surprise: that day, the estimated testing time that I was so sure of looked like it wasn’t enough.
Several days later, I realized two obvious things that I never thought could lead to a disaster in decision-making:
- software applications grow in complexity as they continue to be updated, and, because of that,
- the regression testing time required for growing applications also needs to increase by a properly factored amount.