As an automation developer and community builder, I often get asked how to move from manual testing to automated. However, 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 everything 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 whether 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 essential 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 action sends the whole experience up in flames. If you had to plan for the worst failure, ask yourself the ultimate goal for the software (or at least this piece). Assessing business goals and ensuring software reaches those goals should be high on the priority list. Rome wasn’t built in a day but burned down in one. 

What has been a historic problem?

Do you lose sleep whenever 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 you have 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 an excellent descriptive name can help eliminate any room for interpretation:

A lousy test name:
Modal close

An okay test name:
Modal close on confirmation

An excellent test name:
Discard Changes modal closes on confirmation via mouse click.

This will help remind you of the ultimate goal and make 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 straightforward as possible.

If you’re still feeling overwhelmed, here are 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 it will make your work visible. Besides, if there is no documentation – did you 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 primary 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 failing – at least at some point. If a test can’t fail and you’re checking something like TRUE==TRUE, then you’re not checking anything. The false sense of security might feel nice, but what did you accomplish?

Whether you’re starting with manual tests or racing into automation, quality testing doesn’t have to test your sanity either. We have your success in mind at Provar and hope these recommendations help you avoid a backlog of speeding tickets.

If you have questions or a great tip you’d like to share, you can find me on LinkedIn, Twitter, and if you are a Provar customer, in our community forum. See you online!