5 Ways for Testing Time Estimation
According to my observations, I elicited several ways to testing time estimation:
- based on knowledge;
- based on testing sessions;
- based on testing type;
- based on expertise;
- based on bugfixes.
Let’s deep dive into each of them.
Based on Knowledge
For instance, the tester who is familiar with a product for one month would give an assessment that will differ from a tester who knows the product for a year, just because the second tester knows more details and pitfalls. Second tester dove deeper than the first tester. Of course, there might be the case when the second tester has batophobia and keeps swimming on a water surface in water wings. But let’s assume that we have a brave tester here.
Based on Testing Sessions
Lousy answer: It takes one day/two days/one week. Suspiciously precise, right? You weren’t in the future unless you have a time machine. Perhaps you might need even more time as you stumbled upon unpredictable circumstances or some other external reasons that made an impact on testing time.
A tester has plenty of activities before actual testing:
- Read documentation (if exists).
- Talk with the team to get to know about the product.
- Prepare everything for testing (test data, test tools, test cases, environment configurations, get access to services you need for testing, etc.).
- Do the first round of testing and create tickets for a defects.
- Wait for a fixes, do the second round of testing, close defects, create new defects.
- Repeat steps 4 and 5 until the product looks nice and clean. In a suit and tie.
Let’s assume we need to give only a pure testing estimation to a manager (steps 4, 5, 6). Even here the testing process is stretched out. Imagine, we have a functionality that can be tested in two days. It doesn’t mean, you sit at the table and test two days in a row. You take breaks as you will be more efficient at testing.
During every testing round, you might have several sessions (30 minutes, one hour, 90 minutes, etc.). Between those testing sessions you have other activities (chatting, talks with teammates, company meeting, lunch, coffee breaks, rest, etc.). Eventually, two days of testing might be stretched out within one week. It’s impossible to achieve the same effect just by doing testing two days in a row. You need those time gaps.
Now, what kind of estimation should I convey to a manager? Two days or five days? Pure testing takes two days but it has to be stretched in time to make it more efficient and productive. Whatever you say, your manager should be aware of your testing approaches and you will be able to defend your position regarding that.
Wise answer: In case there are no bugs I need this amount of time to test this piece of functionality. Depends on how raw the product is, it will vary the time for testing, bug reporting, and follow-up testing. We all know, there is no such thing as a bugless product. Even when you think you’ve found all bugs, it doesn’t mean it’s true. In any case, the list of defects found during the first round (or whatever rounds quantity it takes) of testing postpones the production-ready day. So, name the time range you need, not the concrete amount of time.
Based on Testing Type
The testing type you apply has a direct impact on testing time estimation. The time range vary depends on the level of how deep it will be, or what kind of testing it will be. Either it’s UI testing or API testing. Smoke, Acceptance, or Regression testing.
For instance, if your testing looks like exploring the water surface (just to get to know water temperature) it will take very little time. If you choose to deep dive in a swimsuit with the diving cylinder on your back it might take longer to explore one particular place more thoroughly.
It requires more preparation to be able to analyze the surroundings more slowly and meticulously by moving with a water bubble speed. Perhaps you need to change the diving cylinder several times or you need more people for investigation.
Based on Expertise
If you are an API testing expert the execution time will be smaller than a tester who knows less in that testing type. Same with Security, Performance testing, or any other kind. The T-shaped specialist’s concept becomes more and more popular. But don’t expect the work will be done as fast as an expert can do it. Make sure, the task will be done by the same person who estimated it. Otherwise, if estimation was given by someone else (for instance your QA lead) (s)he should take into account the professional level of each QA Engineer in the team.
Whatever the estimates are there is something we need to keep in mind:
- always keep a time buffer (20%-30%);
- be ready that testing can be done faster (managers would be thrilled);
- be ready that testing can go way beyond the estimation (but this is another topic).
Based on Bugfixes
I want to share separately step 6 from the testing sessions approach (testing iteration). The tester’s routine with the build will look like this:
- you get the 1st build to test it;
- after the first testing session you report some issues;
- then, you get the 2nd build;
- you verify bugfixes and continue with the second testing session (probably, you will report some defects again).
And there will be several rounds of testing until the product is going to look nice and clean, in a suit and tie.
As you might see from this routine, we have bugfixes time gaps. You cannot estimate and predict the time for each bugfix. Hence, you cannot predict when you will get a new build after your 1st testing session. Even if you are a test estimation pro and you know exactly how much time you might need to finish testing, you cannot forecast for how long testing will be delayed due to the bugfix. Of course, you can fill a build waiting time with other activities. However, at the end of the day, we all want to see some progress and eventually, visible results. But when this day comes?
You cannot forecast for how long testing will be delayed due to the bugfix.
We need to distinguish the testing time and time for stabilizing the build. Time for build stabilization can vary and the whole team effort is in charge of that. In practice, the time buffer that each team member puts into his/her estimation should partially represent the build stabilization time. The main question is how much time the team can afford considering a crazy release schedule in the Agile world.
I bet there are other approaches to do precise or narrow estimates. I included those that are worth the attention from my point of view. If you have any other useful techniques I would be glad to read about them in the comment section.
