When it comes down to strategies and approaches, there’s no one-size-fits-all approach. It will heavily depend on the context, like technical infrastructure, quality objectives, budget, timing, resources, and many more.

If you’re going to start your test automation journey, pick a project which is neither critical nor trivial. You certainly don’t want to endanger the qualitative and timely delivery of a critical project, but you also want sufficient leverage – which typically is missing in trivial projects.

Your second decision is the level of automation: code, API, UI, … For which levels do you have the buy-in, the skills, the tools, the data and the time to start automating?

Another decision is the type of automation you would like to undertake: test execution, test data preparation, automation of reporting or rather focus on the non-functional test automation (security, performance, usability, reliability, maintainability, …)

Once you’ve established all that (and have it confirmed by the stakeholders), it’s time to start your test automation adventures. Ideal candidates for automation are:
– Repetitive work (e.g. similar test cases on different configurations)
– Non-functional tests (e.g. stress tests)
– Sanity or smoke test (e.g. tests that have to run with every build or deploy to confirm that the most important features and flows work)
– “Easy” tests (e.g. data entry, filling forms, …)
– Data driven tests: (e.g. similar tests that have to be run with different data sets)

Finally, continue to be evaluate your test strategy and approach. There’s always room for improvement.

Similar Posts