A simple method for estimating the test time can be as follows for a typical black box test assignment.
Total Time = # of cycles * (Time for each test cycle + time for fixing errors found in one cycle)
so if you have an estimated time of testing cycle of 6 days and is expected that developers will have 4 days to fix errors found in a cycle and if the number of test cycles are estimated at 4 and then
Total time = 4 * (6 +4)
Total time = 40 days
But this model is very simple, but useful for simple projects.
A bit more complex model to estimate the time trial of the software includes:
1 Categorization of software requirements resulting in series of requirements that may cover commercial, technical, functional and performance
2 Using Complexity constant (e.g. 1 to 1.5 for simple and complex)
3 risk factors application (e.g., ranging from 1.1 to 1.5)
4 Application of an overall contingency factor (e.g., 1.15-1.35)
So a cycle time = n * constant demand for the complexity of risk factors * contingency factor
If you are implementing the above methods, you must take into account some other factors also-
When running the estimation of the test, one can estimate the efforts for tasks outside the test team. You can calculate an accurate estimate of the tasks that depend heavily on developers, as the publication is based testing and correcting errors. Build normally issued very late to the testers and the testers have to change their schedules. In addition, the technicians do not know and control how errors are fixed. Therefore most difficult part of evaluating the evidence is proof of the implementation phase.
The best way to calculate the efforts of the proof is that you should know what size projects the point function approach. However, no easy task.
Function point approach is not easy to explain in a post. Let me know if you want to talk more about this.
0 comments:
Post a Comment