App Test Cases Are The Lifeline Of Your QA Process

5 Things To Do and Not Do When It Comes To Testing Applications

No matter what kind of an app you’re building, knowing what to test for and covering important testing scenarios is key to ensuring a stable, quality product.

The people testing the app must “wear different hats” and examine it from various perspectives. For example, one could simulate an end-user playing around with the app for the first time. Another could act as a hacker with knowledge about how the app operates behind-the-scenes.

These varied perspectives bring a broad breadth and depth to the QA (Quality Assurance) exercises to ensure any bugs that exist are found and fixed. It’s said that a good testing team is a developer’s nightmare. Because, at the end of the day, what matters most is finding any bugs and fixing them.

Solid test-case writing begins with an understanding of the basic requirements of the app and building on them to come up with intelligent test scenarios. A good test case suite isn’t necessarily about lengthy documentation; it’s more about the value each test case brings.

The following are five points to keep in mind when writing test cases:

1. Don’t just rewrite the use cases.

Inexperienced testers often end up doing this. When this happens, the test cases end up being a requirements document, albeit in just another format. This is something that must be consciously avoided as it doesn’t add any value commensurate with the time spent on it.

Test cases should cover the basic requirements but also go beyond what a requirements document does. For example, if the requirement is to sign in to the app via Facebook (FB), the test case must capture the context of the same. What if the user doesn’t have a FB account? What if they don’t have the native FB app installed on their phone? How does the app respond to a logged-in user if he or she changes their FB password?

2. Don’t think of test cases from a developer’s point of view.

It’s easy to fall into the trap of thinking on a system, database, or web-service level, and thereby letting a bug or issue exist because the developer said, “Modifying the web service would impact the ABC data in XYZ column of the database.”

Never accept a developer’s justification of this kind for discarding a test case. If, as an end-user, it makes sense to expect a particular result, it should make it to your test case suite.

The development team needs to do what it takes to make it work. If they conclude that it’s not feasible, then the business analyst for the project should be consulted and come up with an alternative way to achieve the intended result.

3. Test Scenarios – The gold mine the QA team brings to the project.

Intelligent test cases are an asset whose importance cannot be emphasized enough. Thinking of scenarios that are likely to come up based on a combination of user-inputs or user-circumstances makes the test case suite invaluable. An app that passes such a testing cycle will be anyone’s pride.

A common misconception is that intelligent scenarios are the rare-case ones —Things that can happen if four people put their hands on the device screen at the same time, or if the device switches between three wi-fi networks within three minutes.

Rather than relying on these kinds of test cases, what the app actually requires is testing real-world scenarios that are likely to occur more often.

For example, say you have an order management app. Test how the app behaves when the inventory has stock when displaying the order summary, but stock runs out when the order is being placed.

4. Make test cases easy to digest.

Writing good test cases is as important as how you present them.

• Avoid using adjectives; instead, use quantitative terms.
• Avoid unnecessary descriptions. Keep them concise and crisp.
• Format your test cases so the steps and expected results are easy to understand at a glance. This makes every cycle of the QA much more efficient.

There’s no point in writing test cases that the team never uses in the thick of the QA phase. It’s not a formality to be completed but rather a document that should complement QA activities and test the app more productively.

Test case suites should also be very well-organized so it’s easy to search by module, user role, and platform.

They should also be easy to update whenever needed – either with new test cases or with the results of each testing cycle.

5. Iterate and improve.

Test case writing should start soon after the requirements and designs are completed.

Peer reviews and brainstorming sessions go a long way in helping the team come up with various scenarios and catch existing loopholes.

Great test cases start with a solid understanding and grip on the requirements. Creative ways to do this could be performing role plays with the team or having them take a quiz on the different actions a user can make and their resulting outcomes.

Once the team has a grip on the requirements, they need to apply their QA skills to come up with the best possible test scenarios to write intelligent test cases. Reviews and feedback incorporation make them even better.

Also, as the project progresses, it’s essential to keep adding to the test case suite when anyone thinks of a new scenario.

Incorporating these five principles into the DNA of your testing team’s style can make a huge difference to your QA process and outcomes.

And the results? They will be there for all to see