TAKE SMALL STEPS
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
Pattern summary
Look for small increments of the work that will give you value.
Category
Process
Context
This pattern is needed when you start with test automation and want to deliver results quickly. It is needed both for long lasting automation and for one-off or disposable scripts.
Description
Don't try to do too much too soon in your automation. It is tempting to try to automate as much as possible as quickly as possible, but this will ultimately make more work for you. Don't start with complex test cases, do first the easy and short ones. By taking small steps you can learn your way with tools, scripting etc. and you can show results relatively quickly so that you can SELL THE BENEFITS for your automation project.
Implementation
Here some suggestions:
- Automate at first only positive test cases (Happy Path).
- Automate only the smoke tests.
- Automate only bug fix tests.
- Automate stable functionality so that you don’t have much maintenance in the beginning.
- Automate functionality for which a good test case base is already available.
- Automate the STEEL THREAD.
- Develop the automation in SHORT ITERATIONS
- CELEBRATE SUCCESS regularly.
In some cases it can be most rewarding to do just some automation in order to support the testers right away. This will help to produce much interest and support for a later extension of the automation effort.
Potential problems
A step shouldn't be so small that it makes no difference, and if it is too large, then it isn't a small step.
Issues addressed by this pattern
COMPLEX ENVIRONMENT
HARD-TO-AUTOMATE
HIGH ROI EXPECTATIONS
INEFFICIENT FAILURE ANALYSIS
LIMITED EXPERIENCE
NO PREVIOUS TEST AUTOMATION
STALLED AUTOMATION
HARD-TO-AUTOMATE RESULTS
UNREALISTIC EXPECTATIONS
Experiences
Jochim Van Dorpe writes:
We introduced the 'take small steps' pattern by introducing a level of priority to automate.
Due to timing, resource and budget constraints, we can't implement as many test cases as I, as a test analyst, want. So I make sure that the tests we make are always the 'smartest' ones at that moment. We introduced 4 levels for system tests (per use case, functionality, ...):
- Level 1: The happy path, and when there are less than 3 possibilities, we add 1 or 2 extensions
- Level 2: The non-happy paths with different end-points
- Level 3: Test cases that end up in the same state as cases in level 1 or 2, but with a slightly different path. (for example: IF A then 1 else IF B OR C then 2, the input B could be in a level 2 set, the input C could be in a level 3 set)
- Level 4: Test cases that follow the same path as a level 1,2 or 3 case, but with multiple iterations, a bigger dataset, an empty dataset, ...
An automator always takes a test from the highest level avaliable.
If you have also used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.