The Scary Word Estimation, or How I First Estimated Testing Time and Went Overboard
When a manager on a new project asked me to estimate testing, I was at first confused, because it was supposed to be a manager's or senior tester's job. Then I remembered that I was the only tester on the project. And off we went…
☑ A little about estimation methods
☑ If you are encountering this for the first time with EWithTIMtion
What's happened?
I remembered this story recently when I was helping a young colleague navigate the topic. She found herself in a similar situation – an application from scratch, a small team, one QA, there are technical specifications and nothing else, the client wants to go into production in 3 months. She panics and doesn't know where to start.
Now I calmly suggested to my colleague to take a breather. But then, several years ago, I myself was quite stressed when I realized that theory and practice – again (what a surprise!) diverge. Learning the definition and talking about estimation methods at an interview is one thing. But evaluating tasks on a real project, especially when you are your own senior and junior tester, and for the first time – you know, for the immature psyche of a newbie, this is not so good.
As I said, the project was small. We were developing a mobile application for online consultations for the medical field. The client already had a website, he just wanted to become more “mobile”. Even before the official start of work, the manager asked me to evaluate the tasks, or rather, time for testingShe needed numbers to justify the budget and the number of QA hours.
On the plus side, I had requirements.
On the downside, there was nothing but requirements. I had to write the test documentation myself as well.
A little bit about estimation methods
You can find different methods on the Internet, I will only give those that I have encountered most often.
Decomposition. When we divide a task into smaller subtasks and so on until we reach the one that can be easily estimated. I like this. With the requirements, I was able to quickly figure out and apply them.
Rating based on 3 points. We use three options: optimistic, most probable and worst. And then we use the formula for calculation:
where 6 is the standard deviation. It's a bit complicated – the first three options also need to be taken from somewhere. I skipped this method.
Delphi method. What is needed here is a group of experts who will gather, fill out questionnaires or discuss everything at once and make a verdict, reaching a consensus. Well, where can you get them most often if you need to answer “yesterday”?:)) Also out of place.
Percentage of development. Quite a popular method. We take the development time and, depending on the number of testers and developers on the project, multiply the development time by a percentage. As a rule, there are two testers per developer. Therefore, we multiply the time by 0.5. I had it the other way around, there were two of them and I was alone. But it made no difference, since they still didn't tell me about the development timeframe.
Experience. A useful method. As obvious as… well, as obvious as anything. Of course I used it.
Method A finger in the sky. Oddly enough, that's what it's called. Although, as for me, if you try to use the smart formulas of the above methods at the beginning of your work, then you end up with something like PVN, because you don't understand at all how to apply these things without experience.
What I got
Let me repeat – I was very lucky that I came to the project with ready requirements. There was clearly written documentation and an analyst on call. I was given time to review the requirements (although in fact it turned out to be testing of the requirements) and to draw up a test plan.
So, BEFORE the start of the project I:
ツ conducted requirements testingafter which the analyst made a few changes and work could begin;
ツ chose (not right away, unfortunately) the best method for yourself assessment of testing time, combining three in one: experience + being your own expert + decomposition;
ツ found and installed the application on my smartphonewhich had similar functions to our application, for some of which I had no experience testing at the time;
ツ based on the number of test scenarios in the requirements, I sketched out an approximate number of checks (positive and negative) for each task, as much as possible decomposed;
ツ multiplied number of tests for the approximate time of passing the test case. Moreover, I did not calculate the arithmetic mean, but I counted separately obviously quick playthroughs and things that might take longer;
ツ I included 30% in risks.
The number that I typed to the manager with shaking hands – 110 hoursI thought I would be fired right away, I counted so many.
How many hours was I wrong?
After finishing the project, I compared the hours spent and saw what was left in reserve. there are still 26 hours left. That is, my calculations turned out to be a little (was it a little?) exaggerated, even taking into account the risks, writing test documentation and the fact that at this time, testing on iOS was includedwhich was not planned.
What mistakes did I make:
– for some reason I wanted to make everything look nice and went to try to use formulas when assessing. As a result, I spent time shoveling through the Internet and realized that formulas are either difficult in principle, or clearly not for a junior with his meager experience and panic attacks from meetings with an analyst, manager and customer
– I didn’t contribute any preparatory activities like requirements testing and the testing assessment itself ANYWHERE (facepalm, I know). In fact, I just wasted my personal time. And I could have gotten paid for these 4 days…
– I hurried to answer the manager. Perhaps I should have recalculated. Although the manager was satisfied with my answer – she clearly expected that she would have to fight for more from the client.
I know that most of the people here are experienced, but still.
If you are new to EsTImation,
…then first of all – don’t panic. Or even better – set a timer for 15 minutes And panic. And then turn off the timer, take a breath and think about where you can find the answer/advice (spoiler – from colleagues, curator, in Google, there is a little bit in this article too)…
And if you haven’t encountered it yet, but you already work as a QA, then, even if you are not asked, Before you start a task, estimate how long it might take. Record the time and when you close the task and/or file bugs for it, note how close you were to the real time. This will greatly help you not only in estimating, but also in basic planning of working time.
If you have any life hacks on estimating testing or another process, please share them in the comments. I have a feeling that my story has not covered everything. Maria, LC testing specialist.
We welcome your questions/feedback/comments. We are QA team We want to write interestingly and usefully about what we can do.
