1. Identify the essential tests
So what are you going to test? The aim is to remove the heavy lifting from manual testing through quick checks, so it’s good to start with the most laborious tasks. Any use cases in your software that requires many steps? Logging in and out as various user types? How about testing that a process works after hundreds of records are added? It’s important that a test actually saves time from the user recording them, so a focus on the most irritating common repetitions are likely to be among your essential tests.
2. Allow for the variables
The fact that the actions and steps of a test are fixed needn’t limit the range of things that can be tested. Based on the tool being used, variations can be factored into a test so that it recreates a real user experience. Options could include selecting a different record from a grid with each test at random, or logging in with different credentials from a list. Variations in tests provide much greater replication of a real life scenario and are much more likely to catch an edge case bug in the system.
3. Structure your tests in combination
Rather than making one long test script for each specific use case, it is far more sensible to make tests out of combinations of smaller mini-tests. Rather than a single test where a user logs in, browses to a specific page, opens a record and edits, it would make more sense to have a login test combined with a browser-to-page function, then a test for opening and editing a record. Breaking tests into modular chunks makes it easier to build future use cases from reusable tests, plus it becomes much easier to make future adjustments.
4. Test for successful errors
It is important to test not just for successful outcomes, but for the case of purposeful failures too. Test that a user cannot login with the wrong credentials, test that logged out users cannot access the site, test permissions, redirects and correct error messages display. Ensuring the correct error cases are just as important as the happy path ones.
5. Create tests to work, don’t work to test
The reason many often criticize automated testing is that the time needed to set them up takes longer than simply testing itself. Whilst there is no replacement wholesale for human testing of a software, automated tools need the correct setup to work for you rather than the other way round. Focusing on these steps and identifying the right time and structure for automated tests can ensure they are quick to setup and build, and even quicker to run and efficiently test your system.