Estimation Factors:
S.No | Type | Factor | Impact | Remarks |
1 | Framework | Availability | High | Good framework makes your scripting, debugging and maintenance easier. Do understand that framework needs continuous updating across the script development. |
2 | Application | Repeat functionality | High | It is quite easier to automate incase the functionality repeats across the application (Recommend to use keyword driven in such cases, as you do not end up in writing more action/verification based methods). If NOT, then the effort of building libraries and/or scripts is more linear in nature. |
3 | Project | Test Scope | High | If the complexity of application as well as the test scope is complex in nature, then it would consume huge efforts to automate each test case. |
4 | Test tool | Support to AUT | Medium | The test tool to be used may not support some application functionality and may cause overhead. You may find it more difficult to get started with open source scripting and/or tools. |
5 | Scripter | Skill | Medium | This costs project. The right skill packages of the scripter are very essential for any good test automation. If the customer NOT willing to provide the leverage on the estimate for this factor, do NOT forget to add the learning curve cost to the overall time. |
6 | Application | Custom Objects | Medium | The number of custom objects in the automation scope matters as it becomes overhead for the test automation team to built and maintain the libraries for them. |
7 | Application | Type (Web/ Client-Server / Mainframe) | Medium | For web application, any commercial test tool has amazing utilities and support. Otherwise, there are good possibilities that you need to spend huge effort in building libraries. |
8 | Application | Developed Language & Medium | Low | It matters as selected test tool does not support specific verification checkpoints. |
Assumptions Made while Estimating
While estimating a project, all the assumptions made should be written down in detail.
The Rules
Estimation shall be always based on the software requirements
Estimation shall be based on expert judgment
Estimation shall be based on previous projects
Estimation shall be based on metrics
Estimation shall never forget the past
Estimation shall be recorded
Estimation shall be supported by tools
Estimation shall always be verified
Procedure for estimating:
1. The requirements are gathered and based on the requirements the following are to be identified:
- Number of new test script/test case (in case of creation)
- Number of changes in the test script/test case (in case of updating)
- Complexity of the test script/test case – Major, Medium and Minor.
2. The general hours are then estimated based on the below assumption:
Creation (below is just an example, HOURS you need to be change for your project):
SEVERITY | HOURS |
Major | |
GUI | 8-12 |
Functional | 12-16 |
Medium | |
GUI | 6 |
Functional | 6-8 |
Minor | |
GUI | 4 |
Functional | 4 |
Updation:
SEVERITY | HOURS |
Major | |
GUI | 6 |
Functional | 8 |
Medium | |
GUI | 4 |
Functional | 6 |
Minor | |
GUI | 1-2 |
Functional | 1-2 |
3. The estimation is also based on the time of execution, specific to automation:
- 1st time execution = 1 hour
- 2nd time execution = 0.5 hour
- 3rd time execution = 0.3 hour
Execution time = 1 hour (manual does not depend on the time of execution)
Based on the above calculations, estimations are being done. A sample estimation spreadsheet is being attached below for reference:
No | Name | Type of change | No of scripts | Update Hrs | Are New Scripts Req? | No of New Scripts | Creation Hrs | Execution Hrs Cycle 1 | Execution Hrs Regression Cycle |
1 | Logon | Minor | 6 | 6 | Yes | 2 | 6 | 5 | 5 |
2 | Module1 | Medium | 4 | 12 | No | 1 | 4 | 3 | 3 |
3 | Module2 | Medium | 6 | 12 | No | 5 | 5 | ||
4 | Module3 | Medium | 1 | 2 | Yes | 4 | 1 | 1 | 1 |
5 | Module4 | Medium | 4 | 12 | No | 3 | 3 | ||
6 | Module5 | Medium | 13 | 3 | Yes | 8 | 60 | 10 | 10 |
Sub Totals | 34 | 47 | 15 | 71 |
Related Topics – Software Testing Effort Estimation
Recent Comments