A way to organize test cases for efficiency

Sometimes I find myself struggling to organize a test suite in a way that seems efficient or just feels right. Today, I was looking over a test suite written by a colleague and something clicked:

• Organize tests in a way that traces user flows
• Organize tests in a way such that total test time is minimal

Both of these have a direct relationship to efficiency. I didn’t realize I’ve been organizing my tests this way until I was doing a “test case review” of a colleague’s test cases. It may seem like obvious statements, but when trying to wrap your head around a hundred tests and many flows, it can be overwhelming to sum up your process to a few points.

Think about how a user would use your software. What are some tasks they’re able to do? How do they get from point A to point B? How do they get from state A to state B? You can use the product requirements and UI mockups to help you with this, or better yet, use the software if it’s ready (even if partially).

Organize the tests in a way such that when running tests manually or even through automation, the total execution time is minimal. That means covering as many paths or tests as possible with as little repetition of tests or steps as possible.

Say you are writing tests for a simple application with a log in page and a generic dashboard that displays a welcome message.

We could write our tests in the following order:

1. Successfully login with valid email and password
2. Successfully login with a different account
3. Should not be able to login with an unregistered email
4. Should not be able to log in with wrong password
5. Should be able to successfully log out
6. …

Going through this in order, the flow would be: login > logout > login > logout > login > logout. It also means you’re covering tests that are farther down the list while doing earlier tests. You could argue that it doesn’t matter since you can just give a result to the already tested scenario and move on. That’s a valid point, but to me it seems redundant and messy. Plus, there’s an extra ‘login’ action at the end if you were to continue tests for the dashboard.

What if we organized them to minimize the total amount of steps and follow what users might try?

1. Should not be able to login with unregistered email
2. Should not be able to login with wrong password
3. Successfully login with valid email and password
4. Should be able to successfully logout
5. Successfully login with a different account
6. …

The flow for this is: login > logout > login. That’s 3 logout/login actions vs 7 or 4. The difference might be small in this example, but imagine having hundreds of test cases. I probably could have picked a better example too 🙂

It does depend on how you write your test cases and it might not work for all people or situations. However, it’s one way to organize tests for efficiency.