Test estimation is not an easy task. Various schools of thoughts suggest varied strategies of estimation. A number of techniques are available for task estimation. Before we talk about any of the estimation technique, which is out of the scope of current post, we should talk about the activities that need to be kept in mind while estimating testing effort.
Majorly, the activities can be categorized under Test Planning, Requirement Analysis, Test Case writing and/ or scripting, Test Case/ Script execution, Training, Defect Reporting and Tracking, Regression and Retesting and, Reporting. Then we should incorporate following possibilities in the real life scenarios: possibility or parallelization of tasks, dependencies and roadblocks and, risks. Let us dig further into each of them.
Test Planning
This is start point of any testing project. Here, we include items to be tested, environment needs, resource availability and the timeframe. This is a task done by a team leader or the manager of the project. Depending on the complexity this task may take few hours to few days of effort.
Requirement Analysis
This task is performed by every member of the team. How long this will take, depends on the volume of the requirement document or the change request. It also depends on how much level of clarity the document has. In case of unclear or ambiguous document, there would be several discussions within the team to clarify each of the user scenarios.
Test Case/ Script Writing
This is a huge effort and depends on the amount of modules considered in the scope of the current iteration. In case of automation, tool selection and suitable coding efforts are required. For automation, you need specialized personnel for the job.
Test Case Execution
Execution of manual test cases or automated scripts is most critical activity of a tester. You always avoid the bug leakage at the production. For that the team needs ample time to execute the entire test cases/ scripts. Apart from this, a suitable bandwidth must be given to the team for exploratory testing.
Training and Environment Set-up
The team may need training on the testing tools and the product. The effort and time for this also needs to be estimated. In case of an ongoing project with the fixed team the training requirement can be ruled out, whereas, for a new team it is a major effort. Environment set-up takes good amount of time, depending on the technologies involved.
Defect Reporting
Finding defect and logging into the defect tracking tool is also an effort, which is mostly ignored while estimating. The defect report should be clearly explained with the steps to reproduce and the target environment.
Regression and Retesting
Once the defect is fixed, tester needs to retest the issue and regress the adjacent areas of the application. The amount of time needed varies from one defect to another. In some cases, testers need to run the entire smoke test after the defects are resolved.
Reporting
The whole exercise of testing is not successful till a nice report is presented to the management and the customer. Report is a snapshot of the whole exercise and it says the number of test cases run, defects logged and the current health of the product.
Having known all the items to consider for the test estimation, you need to be sensitive for the amount of work that can be done in parallel and others in sequential mode. Also, while one should identify the risk (ie. unforeseen circumstances arising during the iteration). Broadly, you should consider following while estimation:
Scope of Parallelization
Few of the tasks can be done in parallel and others can’t. For example, test planning and requirement analysis can be clubbed together. Similarly, test execution and defect reporting, by nature, goes hand-in-hand.
Dependencies and Roadblocks
In order to carry-on the testing smoothly, you should offset all the dependencies and roadblocks. The idea is to identify the in advance and take a proactive step so that testing does not affect.
Risks
There must be proper strategy for the risk identification and its mitigation. All the identified risks should go to the test plan document and their mitigation strategies must be discussed with the management and client.
Phew! Please let me know if you feel I should have included more in this.
No comments:
Post a Comment