Before you automate
Do your analysis, identify your biggest risks and choose how you can mitigate those risks. This is abstract, so what kind of risks might you identify?
- Allowing invalid input crashes the application or allows corrupt data to be recorded
- Users can no longer do something they could before
- Users can do something now they were prevented from doing before, that they should not be allowed to
- Usability is compromised so it's now more difficult or confusing to use the application
- Application on longer performs as required
- Application no longer projects privacy or security
There are many more risks you could identify for your own applications, but militantly it boils down to this:
The application on longer behaves how it is expected, preventing the customer or business getting the desired value.
Be selective
Given you have identified your key risks, ask yourself, will automating your UI give you confidence you have mitigated these risks?
If yes - stop reading and go make that automation happen!
If, like me, the answer is almost always "not completely", think carefully before you sink too much time into UI and front-end automation. And start asking the question "so how do I mitigate the risks identified?".
At some point, there is no single answer, but stick with it. Work with your business and/or client you will get there.
So what options might you have?
- API Automation combined with UI automation
- Chaos or "Monkey" testing
- Exploratory testing, supported by tools and scripts executed "on demand"
- Data-driven automation
If you come up with some good ideas on this, let me know!
If it doesn't bring you joy, throw it away
So - you already have an automated regression suite? Is it giving you value? is it bringing you joy?
Remember, it's important not to let your regression tests to go stale. Make sure they are still giving you value, and they are not getting flaky. If they are taking a long time to run, are they still worth it?
Don't be afraid to stop running regression tests if they no longer bring you joy! For joy, read "confidence to make changes".
This is so often misunderstood. Daily I'm trying to eliminate swaths of tests to get the most out of the time testing.
When I work with others on the automation being written I ask what is this testing for and the answer is often specific to the incident and not the issue. Which prevents a generic test to catch other case.