Your client likely wants to know how long testing will take and how much it will cost. For small projects, test estimation can be fairly easy. For big projects, software test estimations can be a little more complex. Quality assurance is the bridge between software development and the release date.
Most clients’ top concern is how they can avoid cost and launch-date overruns. Your test estimates should cover all stages of the software development process. These three tips reveal how you can negotiate the most effective software test estimations. You will also learn how to answer your client’s questions fast.
Decide On the Best Test Technique
There are several ways you can approach software test estimation. The technique you pick may be based on factors like:
- The size of the project.
- Resource allocation.
- Whether the software is user-facing.
- Supporting activities: The estimate technique depends on supporting activities such as smoke testing, bug reporting, regression testing, and the filling of timesheets.
- Number of testing cycles needed.
Three of the top most used techniques include:
Work Breakdown Structure (WBS)
WBS requires teamwork. A moderator may need to negotiate roles between teams. Some negotiations training may come in handy to arrive at fast and realistic estimates. The steps for WBS are:
- Divide the test into smaller tasks.
- Allocate each task to a group of testers.
- Estimate time and effort required for each task.
- Validate the estimates.
Wideband Delphi Technique
In the Wideband Delphi technique, a number of experts make their estimates in several rounds. The experts typically number between three and seven, including a moderator. The moderator supports the management of a team of subject matter experts with different skills.
In the kick-off meeting, the moderator presents the problem specifications. The moderator may also include assumptions and project constraints. Each expert then independently presents their estimates.
The moderator calls a follow-up estimation meeting. Using the expert estimates, the moderator draws the range of estimates. The experts provide reasons for their estimates, and some negotiations may take place on each expert’s reasoning. After talks, each expert independently reviews their initial estimates. There may be several negotiation rounds until the team decides on a final estimate.
Three-Point Estimation
Three-point test estimation is a simple yet useful tool. The tester provides three values for every task. The tester bases the three values on their training, past experience, and educated guesses. These three values are:
1. Best-case scenario
The first value is an estimate of what should happen in the optimal state.
2. Most likely outcome
The second value is an educated guess on what is most likely to happen with this particular project.
3. Worst-case scenario
The third value is based on what could go wrong during testing for that particular software.
Armed with these three values, the tester then calculates a weighted average for a realistic estimate. The tester should add some buffer time to manage any unpredictable changes, such as a team member falling ill.
Other test estimation techniques are:
- Use-Case Point Method
- 3-Point Software Testing Estimation
- Percentage Distribution
Consider Communication Overheads
Once you have decided on the test estimation technique, consider the time consumed in communication. Software tests involve almost constant communication and negotiation between diverse teams. The main teams may include the test team, software development team, and the business managers.
Testing typically starts with the discovery process. During the discovery phase, testers become familiar with the code base and the user objectives. At each stage of development, the code base may keep shifting. Also, the business case use may evolve as coding progresses.
These changes will require time for the testers to reassess their technique in line with the changes. Some changes may need testers to undergo quick training to follow the code realignment. Keeping everyone informed and educated may require negotiations and meetings. In turn, this leads to communication overheads.
Figure Out Transitions
Quite often in the software development stage, developers find they must switch between tasks. Sometimes schedules clash, or the results for one stage end up delaying the progress of another.
The frequent switching between tasks causes time delays in development. Also, there is a cognitive cost in that developers may find it difficult to get back “in the zone” once a task is interrupted.
Testers and developers ideally overcome wasting transition times by prioritizing their projects. Negotiate with the test and developer teams for each to work low priority tasks during their downtimes. That way, high priority tasks face fewer interruptions and make for a more realistic realistic time and effort estimate.
