Image courtesy of Amazon
I like to think about Test Automation as providing tools that can execute important checks that might be tedious, time consuming, or there might not be enough time to manually perform those tests. Instead of performing these repetitive, time-consuming tests, the Testers can spend that time exploring risk areas where using their intelligence to make decisions on tests to perform is a better use of their time. (And a lot more fun than performing repetitive tests!)
Test Automation is not a trivial undertaking – research should be conducted to develop a strategy, identify tools, and determine the best approach to automate tests that are being performed manually. Test automation is not a silver bullet and it takes time to develop your approach over time by what you learned.
Do you want to learn more about Test Automation and what has worked and not worked so great at other companies? An excellent book to read that I highly recommend: Experiences of Test Automation Case Studies of Software Test Automation by Dorothy Graham and Mark Fewster. This book contains 29 case studies written by those involved with a test automation project. Each case study begins with a background including if the project was successful and if test automation is still being used at that organization. Consider starting a book club where everyone reads a different chapter(s), shares what they learned, and develop a strategic plan for your company on how you might approach test automation or improve your existing approach. (And consider adding food as part of your book club, food always make any event more fun!)
Key Take Aways:
- Test automation is not necessarily performed by Testers. It is performed by the person best qualified to use the tool selected that can include the ability to write code!
- Test automation does NOT replace Testers but should supplement your testing strategy.
- Test automation is basically maintaining a code base to test your Product’s code base.
Below are learning points; however the above resources provide a wealth of information that is not summarized within this posting.
- Make it a real project with dedicated people, time, and funding. Start with a small pilot with key objectives and gain buy in for your pilot by key stakeholders.
- Start with simple UI tests or smoke tests as a great way to get some initial protection around the code.
- Consider test automation strategy by: technology facing tests (unit, components, integration) and business facing tests (acceptance, business, GUI).
- Concentrate on testing 1 system first as a model – the system producing the most business (start small, focus on a single but important part of the system).
- It is expensive to automate all types of tests including edge cases. Identify what tests need to be in the automation suite. Think about the value of the test and the question it answers or information provided. What is the ROI?
- Tool training or employees who have experience with the tool is important to reduce expensive mistakes.
- Can Testers write the GUI tests and the Developers write the unit tests? Who will write the business layer tests? That depends on the tool selected and skills of the team.
- The developer may write the tests with the Testers running them.
- Be sure to include business people when selecting the business layer tests.
Tools & Approach:
- New code is often easier to automate than legacy code.
- Different tools / programming languages can be used for the test automation pyramid: Unit, acceptance tests, business layer, GUI.
- Test automation is good for mature code that is not constantly changing.
- Lean regression suites help keep maintenance costs low while still providing value.
- Be careful how you write your tests – reduce failures that really are not a problem.
- All tests running green do not mean there aren’t any problems.
- Once tests are automated, train Developers, Testers to understand how to maintain them.
- Determine if the tool needs to clean up after the test was executed.
- Ability to run the code across platforms, browsers, releases.
Managing Test Suites:
- Different type of test suites: nightly test suite, weekly test suite, candidate test suite.
- Keep the tests small and maintain the flexibility to run tests in logical test suites to reduce the time it takes to execute them. For example:
- you may need to execute some key tests during the day when time is running low.
- you may execute core tests with every new build for critical functionality.
- Strong management support is necessary to understand the cost of the pilot program and long-term support that includes ongoing maintenance of modifying and adding automated tests.
- Strong collaboration with Development is important – code needs to be written in a manner that it can have automated tests written.
- Make the benefits of test automation visible to stakeholders for continued support.
- Ideally Developers / Testers are dedicated to test automation to ensure that new and changed code is being reviewed to determine tests to add or tests to change.
- Identify different champions: tool champion, change agent, stakeholders, etc.
- Count number of tests for each test tool – trend over time to see how the tests increase in number.
- Send business users a calendar of green vs red if any of the tests are red.
- Build time is a critical metric since it includes the time to run the automated tests.
- On what O/S were more bugs found and frequency?
- Detection rate of bugs for tests. What tests found the most bugs? No bugs? Is the percentage of green tests trending upwards over time?