We all know projects should only move forward if the return on investment (ROI) justifies the investment of time and money. The same is true with test automation. Although we may find a lot of reasons to justify automating tests, we cannot forget that the strategy and ROI should play an important part in the approach. I’ve been working in this area for nearly ten years now and below are some of my insights on what I feel are the most useful things to think about before doing any test automation.
Follow the Automation Pyramid.
First, your approach to software development can restrain the time you have to develop your test script. Remember the automation pyramid from Mike Cohn? In my experience, if you follow agile methodology, Cohn’s is the most efficient and cost-effective way to approach test automation. I’ve used Cohn’s approach as the basis for my suggestions below.
Find the right moment to develop your test script.
We cannot automate all test cases. The tricky part is identifying which ones should be running against the code, services or UI (user interface).
Good questions to ask yourself when deciding which tests to prioritize are:
- How much time do you have to test before client delivery?
- What functionality is imperative to the end user?
When you take this thoughtful approach, it will become clear which tests to prioritize.
What is still changing?
Testing code that is still under development is a poor use of time and resources. Streamline the process with proper planning. Changes are inevitable and not always foreseeable but, by prioritizing your tests against stable components you can streamline time and resources.
Streamline the process with the right people at the right levels.
By identifying key personnel to automate tests at each level you can better manage the process including maintaining better control over costs, time & quality. During the Acceptance/Integration/Component Test phase, QA and Dev teams can work together. This collaborative approach will ultimately result in the best quality product and will do double duty by fostering healthy teams that work well together.
Borrow business methodologies to streamline tests.
Consider using Behaviour Driven Development (BDD) to write acceptance tests that can be used as a base to develop your automated tests. This approach can facilitate and shorten the way you automate tests.
These days we work in dynamic environments where constant change is the norm. This blog is a high-level view of a much broader conversation and one that is crucial to have in order to make better decisions to initiate automating tests.
Which of the above steps do you take before testing or do you use another approach you feel is critical? Email me at firstname.lastname@example.org with your thoughts.
For your reference, here is another great blog by Abstracta which discusses Best Testing Practices for Agile Teams: The Automation Pyramid.