Are you stuck at the starting line, surveying the landscape of automation products?
Why not automate today? Are you convinced you’ll need months of development BEFORE writing test cases?
It doesn’t have to be this way. Here’s how to avoid wasting time and money implementing automated testing in your environment!
First, try something free
I recommend open source tools like RobotFramework, Cucumber, or Selenium.
Run a pilot program
Run a short pilot program (less than 2 weeks).
Pick a team member with the right skill set to be successful. If you don’t understand what’s needed, find someone to tell you what you need (i.e. call us:984.244.2313).
Determine root cause
You should have working, maintainable test cases by the end of the pilot. If you don’t, the pilot didn’t work.
In that case, determine the root cause for the failure.
Did the person working on the pilot have the skills to succeed? Is there a technical reason this didn’t work?
Once you’ve eliminated all excuses and ensured your people have what they need to succeed in the pilot effort, run another pilot program.
When your pilot works
If you have test cases that:
• Reliably tell you the state of the system,
• Are human readable (without engineering prowess),
• Are maintainable,
• Are extensible,
• Are running periodically, then…
Your pilot worked
Expand your success within this functional area of the application by writing more tests. Make sure the tool facilitates the writing of test cases rather than hinders it. Sometimes this only becomes clear once you get into more complex test cases.
Ensure what you’ve created is credible and consistent and works all the time. Tie it into your continuous integration environment. Start running all tests often.
At this point, you may be able to run all your tests every build. That’s fine — It will help you make your system less brittle, provided you resolve framework errors in a robust way.
Break up test cases later into separate batches later, when long run times become an issue.
Clone Successes
Once you’ve determined you can succeed in one area with the tool, hand off writing test cases for the initial functional area to someone new. Now try using the tool in another functional area.
Repeat the appropriate steps above for this new functional area of testing.
When your tool doesn’t work for a functional area…
There is no tool that will work for every situation. My advice? Don’t force a square peg into a round hole.
If the tool you’ve chosen doesn’t work with a new functional area, you have choices:
- Decide whether to hold off on this functional area until later OR
- Try out a new tool for this area
Reporting
The only warning I’ll offer is: it is good to have ONE reporting mechanism for test outputs. Automated tests are worthless if we can’t easily find important information in reports.