Information Technology Reference
In-Depth Information
important to choose test cases for automation. Automating test cases that will not
run many times or test cases that will need a lot of maintenance will be a waste of
time and money. On many projects, the test team tries to automate all test cases,
which is a totally wrong approach. Time taken in result analysis and reporting
should also be considered.
In this particular project, all of the aforementioned considerations were not
taken care of during automation.
9.3.2.2
Issues Faced
Higher effort/time for maintenance—Because all test cases were selected
◾
for automation, effort for maintenance of automation scripts in subsequent
releases of the software was huge.
Lower regression test coverage—Due to high number of test case automation
◾
for certain parts of the application under test, other high-priority areas of the
application were getting neglected, and this led to low test coverage of many
high-priority areas.
9.3.2.3
Solution
To overcome the problems faced we first defined a complete test automation pro-
cess including a keyword-driven framework and implementation strategy. We
linked test automation strategy with requirements. Due to thoughtful execution,
a lot of rework and scrap could be avoided. Because we adopted a keyword-
driven framework, if any change was required in the script due to any change in
software being tested, it could be done at only one place in the script. Thus script
maintenance work was reduced by more than 70%. The scripts were also por-
table from one platform to another with minimal change in script. The key word-
driven framework also enabled domain experts to test the application easily. This
approach enabled testers to test the application the way any end user may use
the application.
9.3.2.4
Lessons Learned
◾
Process implementation—This project helped all team members to learn the
right approach to executing any automation project.
Implementation of requirement-driven approach through relevant test design
◾
techniques. Using a keyword-driven framework, requirements-based testing,
highly maintainable and portable scripts, determining which tests to auto-
mate, and how to reduce scrap and rework were the best lessons the entire
team learned from this project.
