Skip to main content

QA Time Estimation


One of the hardest tasks is to give time estimation for a QA work. I believe that the main reason for that is the fact that QA work is unpredictable and dynamic by its nature, in other words any time slot can be filled with some helpful QA activities but not every QA activity gives enough added value to justify the time and money invested to execute it. So how we get a good estimation for QA?


I remmember a while ago I was consulting a company that had some trouble budgeting its small QA department the methodology that they used to favor for time estimation was "percentage of development", and by doing so were completely ignoring two major factors needed for good QA estimation:
1.Complexity of the SUT (system under test)
2.Average number of Test Runs
Those two factor will allow us to use more accurate, though more time consuming, estimation methodology called "Internal overview". By moving to this new approach the company improved significantly its budget planing and had been able to provide more fitting and accurate pricing for their projects.
To emphasize the shift that we did with that's company QA department lets look closely on the two methodologies:
Percentage of Development
This methodology assumes that the amount of time invested in QA effort its always a subset of the development work, usually around 50-60 percent. So if developer requires X number of hours to develop the new feature then Qa work estimated as 0.5*X=(QA ESTIMATE)
Sometime there are more generous departments which will estimate QA effort as equals to development which will bring us to the formula of X=QA ESTIMATE.
Advantages

  • Really easy to estimate
  • Doesn't requires QA involvement in the estimation process

Disadvantages

  • Ignores different complexity levels
  • Ignores the need for new test cases and planing
  • Ignores the need for different number of test runs
  • Highly inaccurate

Internal Overview
To get a good estimation for QA activities we need to understand QA's involvement in all stages of SDLC. QA department should begin its work alongside with development in order to plan and prepare proper set ot test cases. Estimation for this part done by investigation and understanding of the system requirements.
Usually this task is shorter than the development effort on big projects and can be longer than development on small new features requests. It is extremely important to be aware of that when planing a formal release.
Sometime ago I used to work for a company as a QA manager and part of my responsibilities was to provide time estimations for my department. I can tell you that it always was hard to justify QA activities for small feature releases then for big new projects. If for example a new web site required, it will take much longer for development to crate this website then for QA to prepare a solid test suite for it, but when a new button requested on all pages of the website its much faster for the development to create that button, then for QA to plan all possible scenarios of how that button could be used.
Later on when development is done QA execution should begin. The estimaton for  that can be done by taking into account the number of tests to be executed in one full test cycle (TEST SUITE TIME) and multiply it by the number of test runs. Now, here my recommendation will be to take 3 test runs as average. This number can change based on the testing environment and the actual SUT, but for average software release 3 test cycles its a save bet. That will give us following QA estimation formula:
(TEST SUITE TIME)*3= (QA ESTIMATE).
A note will be appropriate at this point, as I had such a confusion before, the (QA ESTIMATE) time will be the net value of QA activities. Usual practice is to involve development for fixing rounds in-between testing cycles so the total time for a specific release increasing based on development work.
Advantages

  • More aqurate time estimation
  • Better quality results
  • The estimation includes all QA activities
  • The estimation provides better overview of all QA tasks.

Disadvantages

  • This sort of estimation more time consuming
  • Requires investigation and QA involvement in the estimation process

My recommendation for every company that I'm consulting is to use the "Internal Overview" methodology for QA time estimation on the regular basis and to leave the "Percentage of Development" approach only for extreme cases.

Comments

Popular posts from this blog

7 Most Popular Test Types in Software Testing

Today we are going to return back to basics of software testing and discuss the 7 most popular test types that are being used in every software testing effort. Those different test types cover all the levels of the software to make sure that the final result matching the expectations from every possible angle. Here is our list: Unit testingSmoke testingRegression testingFunctional testingIntegration testingUser Acceptance TestingPerformance Testing


Now let’s have a deeper dive into each one of those by using a simple example of an imaginary system that was created in order to manage warehouse activity including shipments, inventory and goods receptions from suppliers.
Unit Testing This type of testing is usually performed by the developers and is covering the very basic development component. In this test developers are testing the straight forward functionality of a functional piece of code to make sure that it is performing according to their expectations. In our example: This test w…

Story Points estimation for Scrum with Fibonacci vs Shirt Sizes vs Linear - 7 minute guide

It is all began long time ago when Development Teams were constantly asked to provide estimate and they were having a hard time to properly face the task. Let's admit it, there are so many things that can change, happen, and simply go wrong during the development process that one can hardly expect a proper estimation of hours for each task. That why a relative estimation with Story Points came along.

Story Points Estimation
Its a different way to estimate the effort of the Scrum Development Team with-in Agile methodology, which means that instead of estimating hours of work the team estimates each effort relatively to other efforts in the project.
Let's assume that a developer knows that specific 'Task 1' is much harder than another 'Task 2' it is hard for him/her to quantify that harder feeling in hours of additional work but it is possible to say that it much more work. This situation is being address by Story Points when each story point is representing som…

5 Steps to Install Robot Framework for Web Testing Automation - 7 minute Guide

Lately, I found myself helping several people to begin their automation testing journey. And what a better place to do it then a nice new installation of a Robot Framework with its Selenium2Library on a Windows OS.

Why Robot Framework with Selenium2Library? While you are probably here because you are looking for a quick installation guide for Automation Testing platform for you web project, I still need to do my do diligence and explain in couple of words why we need it.
Robot Framework it's a Python framework that allows for a less development oriented Manual QA professionals to do a quick switch into Test Automation. This can be achieved by allowing for easy English phrases (e.g. Click Element, Wait, etc) to replace a more complex Python syntax.
Selenium2Library it's additional add on on top of Robot Framework that allows easy interaction with web elements during the automation process.

That's it..... DONE with the talking now the installation....

Installation process Ro…