Have you wanted to start with automation testing and not known where to begin? Or maybe you have 100’s or thousands of test cases in your current automation pipeline and you want to reduce the build times. Here I will walk you through one way you could consider slicing up this problem. Using examples from Tyro’s banking app (I use to work on their mobile iOS team).

Break into flows

Analyse your app/site/tool and brainstorm the main flows that people will take through it. I picked 6 flows using tyro as an example app. Next I numbered them.

1. Registration

Registration is a pretty common feature, you might also set a 2 factor authentication, a pin and a password for the account (especially if it’s a bank account)

2. Transfer Funds

If you have a bank account, it’s highly likely you want to access the money in it at some point

3. View Transaction

You might want to check if that bill was paid correctly or if the last transfer was processed

4. Contact Us

Something not quite right? send us a request and we will give you a phone call at a convenient time

5. Change Pin

When was the last time you changed the pin for your mobile banking app?

6. Log in

I’d say this is a pretty common feature

Mapping those flows to a risk board

Draw a graph, put frequency of use on the x axis down the bottom; things that are more used will be on the right hand side. On the vertical y axis put impact if broken. This is from a person point of view, how much would they care if that feature was a broken? From a business point of view you may have a different understanding of risk and that’s fine two. We will go into how to reflect that later.

Add your flows

We have our 6 flows to the right hand side of our graph, we’ve also broken our graph into 3 areas

Move the flows to your graph

It helps to pair on this exercise to help build up a shared understand. Do your designers and engineers have the same understanding of risk as you do? It’s ok if your answer is different to mine, we all have a different context and understanding.

Reflect other elements of risk

You might want to reflect other elements of risk such as security, financial, regulatory and anything else you can think of. At the end of the day this is only a 2 representation of risk and risk is a little more complex than these dimensions we put here.

Neat, what’s next?

If you are thinking, well that’s cool and all but what does that have to do with automation testing? Then please continue reading. You could use this board to decide which tests you should focus on building/refactoring next (hint, the stuff with 3 stars is pretty important). You could also use this to priortise your performance testing efforts. I took this board to our planning sessions to talk about new features and it helped with deciding how much automation/testing effort we may need. At the end of the day, your software will be more complex than this example.

Here is the actual board I used at Tyro with a bit more detail:

I then broke down each flow into a test case, and grouped similar test cases into a barebones automation test suite. You can also use this approach to generate exploratory testing ideas for each screen in your flow.

You can watch this talk in full here:

I also run this as a lunchtime 30-45 minute workshop exercise. Book me in for a lunchtime brownbag if you are based in Sydney (I can do remote too).

Join the Conversation

1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *