Testing Time Estimation Methods: Factors to Encounter

Often, management of the companies that outsource QA services asks to analyze the time required for testing efforts. But this index is hard to predict, a range of aspects elude the measurement.
Some of the companies prefer a science-driven approach in this regard rather than just making assumptions. And it does make sense, management views software testing as a valuable investment, so they tend to fit the deadline, be aware of the costs & benefits testing brings.

Factors influencing time estimation

The guesses at the testing length only help to build an idea of the approximate time required. Once you hire a QA engineer, deadline uncertainty goes over the edge, the schedule is re-estimated. Once the QA engineer runs the tests and detects serious failures, the rate of a bug influences their further strategy. If the defect is marked as severe, that means a QA specialist would rerun the tests, sometimes more than once.

The following factors always modify the relevant time-estimation plan and tighten up the whole software testing process.

• Experience & data focus. Testing length estimation is the reason why collecting previous project data is crucial. Often, similar projects help us to compare the percentage of time spent on task division and QA. Meaning the experience serves as a basis for accurate time estimation.
• The QA team. First, it`s time to encounter the number of QA engineers assigned to the project and conduct the estimation relying upon the workload of each. Besides, professional level, skills, the experience of every team member are vital factors to evaluate their performance and time they devote to each task. Although there are no models of measuring personal characteristics, past experience also helps to analyze the time-frame each QA engineer usually needs to handle the assigned tasks.
• Stability of requirements. Modern agile projects welcome changes, so the development team is no longer ready to freeze the requirements. So the time for QA is adjusted along with the product & deadline modifications.
• Product complexity. Project size and risks are also key points to consider when evaluating the amount of testing to perform. Again, there is no strategy to analyze these factors. Experience and expert opinion of the QA engineers are the only yet reliable options to estimate the testing efforts.
  Another point here is the project industry. Is it an e-store where some minor errors are acceptable? Or is it a patient-care system where each defect is serious? Taking into account these factors would help to significantly shape deadlines for testing.
• Defect density. It is impossible to predict how many defects the system will deliver. Since buggy software requirements and design result in buggy code, this factor has a substantial impact on the time QA engineer might take to find the errors.

QA time estimation techniques

Time estimation approaches always include a range of factors to follow. But these five primary planning techniques help to structure the approximate time needed for testing.

• Delphi method. Also known as Estimate-Talk-Estimate. This is a communication-based method that relies on the team expert view. Usually, surveys or real-time meetings with QA engineers help to implement the technique and determine an average time estimation for each task.
• Planning (scrum) poker. A gaming technique, as you might have guessed from the name. To make the method work, it is crucial to break the project into the individual tasks for the team members to estimate. By playing numbered cards face-down to the table, the group evaluates the amount of time required for the particular testing task. Once the cards are revealed, the discussion starts. The method is believed to be bias-free since the numbers aren`t spoken out loud yet discussed collectively.
• Workload breakdown. This is a basic technique of deconstructing the project into smaller components along with the required time-frame setting.
• Functional point analysis. When used to measure development and testing time, FPA relies on project function size. This method sets time estimation dependent on the task (functional point) complexity. Each is ranked from 1-5 (like 1-simple, 5-complex). QA engineers would multiply the number of tasks with the assigned weight within the category and further divide person-hours needed per each functional point. FTA also helps to measure the project throughout the irrespective of the tools and technologies used.
• Three-point estimate. An assumption-based technique to manage testing deadlines. This is a probable time distribution required for the product components (aka tasks). The method works by the following time-estimation models that are assigned to each task: Optimistic (O), Pessimistic (P), Realistic (R).
  
  The formula E= (O+4*R+P)/6 helps to determine the time estimate (E).

Note that these are the pattern models for testing time estimation. The project quality requirements and the list of testing types are individual, so the methods will most likely be modified.

Now you see why the time estimation is that complicated. Even if you`re aware of most the factors to shape the testing time, the individual structure of your team and project could still impact the deadlines. After all, the key goals are the high-standard project and its successful time-to-market.