Information Technology Reference
In-Depth Information
3.6.2
Scheduling Risk
1. Does your team need any training for testing this module?
2. Can you identify the kind of training required?
3. Is this training provided by any training service provider? How much time is
needed for training?
4. Include this training time in your project estimates.
3.6.3
Human Risks
1. Can your team test this mobile module? Will you need to recruit new
employees/contractors for this testing task?
2. If you need to recruit new people, then you may have to create a recruitment
plan and include it in your testing plan.
... Strategy for Automation
Traditionally the ROI for automation works out when any test case has to be exe-
cuted more than 13 times. After this number of executions, automation works out
to be cheaper than manual testing. For example, suppose for any test case that the
total effort in writing the test case comes in at 15 minutes and manual execution
needs 15 minutes. So the total time required for executing this test case 13 times is
6.5 hours. Now automation requires around 6 hours of work. Automated script for
the test case runs in barely 3 minutes. So the time required for writing the test case,
automating the test case, and running it 13 times is around 6 hours and 54 minutes.
Sanity checks, performance checks, and some other tests that are run against produc-
tion instance of any system are the best candidates for automation. Production envi-
ronments do not change often, and on average some patches may be applied twice
per year. This means that they are the most stable systems against which automation
scripts may not have to be changed often. Most organizations run these sanity checks
on a nightly basis to ensure that the production systems are running smoothly; if any
problem occurs, then it is caught in the nightly run of the sanity check and the prob-
lem is fixed quickly before users start using the system in the office hours.
When a system is being built, many features are being added in future releases.
Whenever any defects are found in previous releases, they are also fixed in the next
release or a patch. Regression of existing features is tested in all of these next releases
or patches. Whenever those features are touched upon in these new releases, they
should be regression tested. So most of the features get tested again and again. So
regression testing is also a good candidate for automation. In fact, the number
of regression tests increases over time with new releases. But testing resources are
limited and do not increase over time. So you end up having fewer resources for
executing these regression tests. That is why it makes sense to automate them so
that resource requirements can be reduced significantly.
