As an automation developer and community builder, I often get asked how to move from manual testing to automated, but we rarely talk about what to do when you aren’t doing any testing and need to. Like anything in the software development life cycle, we’ll break it down into small steps that we can iterate on and help you safely accelerate your test automation journey.
Risk Assessment and Triage
You can’t wiggle your nose and complete your automation dreams overnight. If you’re like me, looking at all the things you need to get done can be overwhelming too. We can follow a few steps to help prioritize and figure out what would give the most bang for our buck, regardless of if we are attacking the problem manually or with automation.
Where do your customers spend most of their time?
Find your happy path. Maybe your customers spend hours customizing their dream car and it’s important that the logic there works. Or maybe your customers need quick access to all their important documents. Whatever path your customers take the most often is a logical place to start.
What would be the most catastrophic failure?
Everything is loaded and running smoothly, until that one action that sent the whole experience up in flames. If you had to plan for the worst failure, then ask yourself what the ultimate goal is for the software (or at least this piece of it). Assessing business goals and making sure software is reaching those goals should be high on the priority list. Rome wasn’t built in a day, but it was burned down in one.
What has been a historic problem?
Do you lose sleep every time a new feature is added because the product is fragile? Is your regression suite prone to human error? Maybe there are just a ton of data sets to get through and time is a factor. Whatever has you fretting about those end-of-sprint tests is also a good candidate for automation.
Beware the Scope Creep
Focus on what the test is trying to accomplish. Each test should have one goal. I often see,
“Identify the purpose and document it.” If you don’t have formal test documentation that lists the purpose then a good descriptive name can help eliminate any room for interpretation:
A bad test name:
An okay test name:
Modal close on confirmation
A great test name:
Discard Changes modal closes on confirmation via mouse click.
This will help remind you of the ultimate goal, but also makes reading failure reports easy.
If your tests seem overly complex and like they are doing too much heavy lifting, they probably are. Try to keep tests as narrowly scoped and simple as possible.
If you’re still feeling overwhelmed, here’s a few recommended practices to pump you up.
1. Make a plan and document everything.
Not only will this help you stay focused on the priorities you set and plan work out, but will make your work visible. Besides, if there is no documentation – did you really do it?
2. Start specific and abstract later.
You’ve already got an idea of what needs to be tested. Something is better than nothing, so start small and work on abstracting tests later. Create a basic contact. Configure a minimum product. Get fancy later.
3. A test is only a good test if it can fail.
Write the test to pass, but plan on it failing – at least at some point. If a test can’t fail and you’re checking something like TRUE==TRUE, then you’re not actually checking anything. The false sense of security might feel nice, but what did you really accomplish?
Regardless of whether you’re starting with manual tests or racing into automation, quality testing doesn’t have to test your sanity too. We’ve got your success in mind at Provar and hope these recommendations help you avoid a backlog speeding ticket.