Test Case Thinking - A Methodical Approach

Agile is now prevalent in the industry. Software Testing in this Agile era is one of the most challenging role as it might get. Thanks to the rapidly changing requirements and the thrive for #ContiniuousImprovement.

As an agile tester, there are just so many things to keep in mind that you should look out for while testing - Acceptance Criteria, Validation testing, Authorization, Performance Testing, DB testing, Exploratory Testing, Impact on existing functionality (Regression), Browser Compatibility, Boundary Value analysis, negative scenarios and the list goes on.

Imagine yourself as a tester who wants to cover all of the above and convert them into set of test scenarios and test cases, what will your state of mind be?

Will you not be confused with questions bombarding your mind such as where to start?, what all to cover?, how much to cover?, what sequence to follow?, how to make sure I have covered them all? etc etc etc.

Well, that is exactly what I used to feel until I came up with a simple and effective way of thinking methodically.

Through this article, I will be sharing a methodical approach that has helped me solve the above problem and come up with comprehensive set of test scenarios and test cases no matter how complex the feature under test was.

Let's begin

Assumption:

You are familiar with the requirements of the application under test and are ready to begin with test case writing.

Laying the Foundation:

This is one of the most important step that will feed into the next steps. Before you start writing, take few minutes to think through and come up with high level testing areas. These are not scenarios but different verticals altogether. Here are few examples of testing areas: CRUD operations, Happy Path testing, Acceptance Criteria Confirmation, Validation testing, Role based testing, Negative scenarios, Impact areas (Regression), Browser Compatibility, Performance testing, Integration with other software(s) or features etc. You can also list down areas where you need clarity or have open questions so that you do not forget.

Building Blocks:

As an outcome of prior step, you must have come up with few test areas. Write these down somewhere. I normally use Microsoft Excel or a mind map tool (this is personal favorite) and will refer the same in this article. Denote a column in excel (Say column 'A') for all such high level thoughts/areas.

Make sure that you restrict your focus only around the high level areas that are important and should be covered in your testing. This is the time to think out of the box. Think from all aspects and come up with remaining high level areas making sure that there is nothing left out. All these should go to column A in excel.

Here is how the excel will look like after this step:

Drill down:

Now that we have the building blocks as per excel's column A (or the first node in mind map) it is time to pick one testing area at a time and drill down to come up with a list of items that needs to be tested in that area. The outcome should go into Excel's Column B (or the sub-node in Mind map). Referring the CRUD operation example mentioned in Step1, I can split all the four operations (Create, Read, Update and Delete) into four excel rows (or sub-nodes in Mind map).

Here is how the excel will look like after this step:

Further Drill Down:

Pick items in Column B one at a time and think through all possible test cases. Referring the above CRUD example , pick operation C and think of all Create (C) related test cases. This is where you should think of as many test cases as possible.

Here is how the excel will look like after this step:

Being a big fan of mind map, I try to use it as often as I can. In this case, I have used it to think and write down test scenarios and test cases, here is how the same looks like in mind map.

Keep going:

Once you are done with one item from Column B, pick next item from Column B and break them down into test cases till you are done with all items that are mapped to Column A.

There you go:

Once done with one item in Column A, go to the next item in that column and repeat the above activity till you are done with all the listed items in column A.

That is it! We are ready with our test cases. It might take some time before one becomes efficient with this approach but believe me with practice it will get easier.

There are a bunch of benefits we get by using it, I have listed a few of them below.

Advantages of this approach:

• Focus: One of the challenges while thinking of test scenarios and cases is to stay focused. Any interruption in your train of thoughts takes you back to the initial steps. In this approach you are focused on a small unit for short period and since you are building on your thoughts, chances of loosing the track is rare and even if you do so, you can come back quickly.
• Quick: I have found this approach to be very efficient as it helps to come with high level test areas in no time.
• Good Coverage: Since you are following the top-down approach, thinking of the building blocks first and then breaking them down systematically, it gives you time to think in various directions there by increasing the testing coverage. Chances of missing any test case becomes rare.
• Confidence: Since the coverage is high, it increases a tester's confidence on their test cases as well on Quality.
• Effective pairing: A Dev-QA or QA-QA can pair to come up with the scenarios. The very nature of this approach invites pair thinking.

Bringing it all together:

I have been using this approach for a while now and it helps me in de-clustering the thoughts and get efficient as a QA in test case thinking and coming up with Acceptance Criteria as a BA.

I would love to hear from you on other approaches that you follow to breakdown the requirements.

Please reply and comment your thoughts.

Happy Testing!!