While making estimate for a test project can be a challenging task, there are ways to better measure and quantify the efforts. If we can identify the variables in the estimate process and focus on the known factors in making estimates, we will be closer to the real schedule. The known factors can generally fall into several categories. They are non-project related tasks, project related tasks, test tools/drivers/cases development, test executions on the manual tests, and automated test cases execution. If the test leads or managers can use an onion-peeling approach to break down all the tasks required in their products testing, they will have a better idea in giving more realistic schedule. On the individual task estimate, we also can make some quantified methods in getting a ball park figure. For example, what are the number of web pages needs to be covered, what are the controls on each page planned, what about the number of APIs, the number of arguments in the APIs are some of the more known factors in making rational estimates
After the scope has been ironed out, we will ask ourselves what are the tasks that can be repetitive by nature and make the best estimate accordingly. This can be coordinated between development, project management and test. Some of the repetitions occur due to number of builds, number of configurations: O/S, hardware platforms (if any), components versions, the upgrades support (how many back versions), the topology combinations (client/server to be on different machines or the same machine), planned regressions on each milestones, planned Service packs releases. Priority must be defined to avoid unnecessary duplications. Generally, the duplicate efforts in testing are the killers that break the schedule. But they can be planned in advance, so the test management can be better prepared for them.
On the tasks which are more fluid by nature such as design changes, unexpected field hot fixes and last minutes add-ins, and personnel turnover or organization changes, we can also base on the historical trend to allocate some cushions for the project.
If we follow this disciplined approach, we will be able to streamline the test efforts and become more accurate in giving estimates. The following are some of the tasks that a Microsoft test project team generally performs. The attached Excel spreadsheet hopefully will give you a suggested approach to define your scope of the test and prepare for the tasks you will perform. It is my belief that we can reasonably use the attached table, strategies, and the formula described below to define the tasks needed in the project
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
