No matter what kind of an app you are building, knowing what to test for and covering important test scenarios is key to ensuring a stable, quality product. The people testing the app must wear different hats and test it with various perspectives. One could be that of an end user playing around with the app for the first time. Another could be of knowing enough of how the app operates behind-the-scenes, to try and hack it! Such varied perspectives bring good breadth and depth to the QA exercises done on the app thus fixing most bugs that exist.
It is said that a good testing team is a developer’s nightmare! All in good spirit of course, because at the end of the day, what matters is getting the bugs found and fixed. Solid test-case writing begins with understanding the basic requirements of the app and then building upon it to come up with intelligent test scenarios. A good test case suite is not necessarily about lengthy documentation; it’s more about the value each test case brings. Here are some points to keep in mind while writing test cases:
- Don’t just rewrite the use cases!
Inexperienced testers often end up doing this! So the test cases end up being a requirements document albeit in another format! This is something that must be consciously avoided as it does not 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. If the requirement is to sign in to the app via FB, the test case must capture the context of the same. What if the user does not have any FB account? What if the user does not 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?
- Don’t think of it from a developer’s point of view
It is easy to fall into the trap of thinking at 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 certain result, it should make it to your test case suite. The dev team needs to do what it takes, to make it work. If they conclude that it is totally infeasible, the business analyst of the project can be consulted to come up with an alternative way of achieving the intended result.
- Test Scenarios – the gold mine the QA team brings to the project
Intelligent test cases are an asset whose importance cannot be described enough in words. 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 and 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 4 people put their hand on the device screen at the same time or if the device switches between 3 w-ifi networks in 3 minutes! Rather than these kinds of test cases, what the app actually needs is real-world scenarios that are likely to happen more often. For example, if you have an order management app, how the app treats a scenario when the inventory has stock at the time of displaying the order summary but runs out of stock as the order is being placed.
- Make test cases easy to digest
Writing good test cases is as important as how you present them. Avoid adjectives. Use quantitative terms. Avoid unnecessary descriptions. Keep them concise and crisp. Format your test cases such that the steps and expected results are easy understandable at a glance. This makes every cycle of QA much more efficient. There is no point writing test cases that the team never gets round to actually using in the thick of the QA phase. It is not a formality to be completed but rather a document that should complement the QA activities and help test the app more productively. Test case suites should also be very well-organized making it 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.
- Iterate and improve
Test case writing should start soon after requirements and designs are done. Peer reviews and brainstorming sessions go a long way in helping the team come up with various scenarios and also in catching existing loopholes. Great test cases start with a solid understanding and grip over the requirements. Creative ways to get a grip on the requirements could be doing role plays within the team or having the team take a quiz on the different actions a user can take and their 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 makes them even better. Also, as the project progresses, it is important to keep adding to the test case suite as and when anyone thinks of a new scenario.
Getting the above aspects into the DNA of your testing team’s style of working can make a huge difference to every project they take up. And the results? They will be there for all to see!
What’s expected of CIOs in 2016?
Distilled here are the 5 areas of focus and priority that find a place in the to-do list of these technology visionaries in 2016.
Click on the image to download your copy!