In a tweet I agreed on do not use Excel for test management – I hate it since the 90s
My test manager says „I don’t wanna get back to the 90s“ when talking about Excel for managing tests. No further comment.
— (((Robert Strauch))) (@shrubbytester) 10. Juni 2016
and Michael Bolton answered on the thread later
@osxjogi … Monte Carlo simulation. Example: https://t.co/VkYCEHAAD1 @shrubbytester @ThomasPonnet
— Michael Bolton (@michaelbolton) 10. Juni 2016
So, I decided to write down now how I try to get data for getting estimations on a project without making complicated calculation where I would need Excel. I have used this in bigger projects (18 months estimation planning) as well as in smaller ones. The factors can differ but it is agile – just make small updates based on your experiences….
Common
On two aspects you need to take care
- Estimation for the code creation (production code, class- and method-tests, documentation, integration- and systemtests, internal acceptance)
- Estimation for additional aspects like project-management, test-cycles and external acceptance
Estimation of software creation
The method is based on the assumption that experienced code developers can estimate very good their own work time on a task they have to finish – means: coding time, not the rest of it. The estimation will grow with the influences which the code developer has not under control. The following table
- is based on experience and not a „that’s it“-solution but in summary the average through development cycles will match
- describes the additional effort which has to be added to the estimation of the pure coding estimation (Estimation = 1):
Influece Factors Code Development
| Developer creates code | additional effort to the pure code estimation | Notes and explanation |
|---|---|---|
| without using foreign code | 1 | Normal in a development team |
| with using open sourced code inside the company/project | 2 | e.g. using code from other groups inside the company - knowledge can be easily transferred |
| with using open sourced code from outside the project/company | 3 - 5; 3 is normal, 5 is the worst case | e.g. using an unknown (in the project team) open source framework or extremly high performance requirements |
| with using closed source code | 3 - 5; 3 not often found case, 5 normal | e.g. using a closed source framework as it is |
| with the need to use closed source software (3rd party) for integration | 5 - 9 | e.g. integrate a service which reachability is not under control of the project team |
Examples:
- Developer estimates 6 work days for pure code development. The developer needs to use a class(s) which are already part of the project. 1 x 6 work days needs to be added. In summary the estimation for getting the task done is 12 work days for the code, unit tests, documentation, integration and internal acceptance.
- Developer estimates 5 work days for pure code development. The developer needs to use an open source framework of a third party, The knowledge is nearly zero in the project team. 3 x 5 up to 5 x 5 work days needs to be added. In summary you get then an estimation of 20-30 for all needed work tasks.