Test Case Design Mindset At a Glance

Shopee Volleyball Interest Group

How do you write test cases? What comes to your mind when you think of trying a new product, a newly released video game, or a new dish?

I struggled to understand how to design a good test case when I first started as a junior software quality assurance engineer (QA) in Shopee. One of the attribute from a good test case design should be able to speak by-itself. Yes! I mean reader should be able to understand it without much of the owner explanation. I hope with this article it can help anyone to break into a career in QA or simply ensuring a product/feature quality.

Test case template should be something that anyone start with to ensure the quality of a new product/feature changes. It can be serve as the thinking process direction, logic coverage, a guide or even artefacts to all the stakeholder in the entire software development life cycle (SDLC).

What should be in a test case design?

From here onwards I will be sharing on my approach to design a test case from a technical and non-technical example using grey box testing methodology:

Non-technical: volleyball

Technical: place order API

Categories

The first and most part of your test case design should be covered with multiple levels of categories like a tree with many branches.

Because the tree came first (reddit source: Kelly240361)

Try to start by thinking what is the most general category for your testing object? Follow by a sub-category that should be related to the parent’s category.

Non-technical: volleyball

• Display: colors, fonts
• Touch: sizes, shapes
• Smell: ball materials
• Taste (I know is disgusting and ridiculous): ball materials, color paint

Overview of Volleyball Mindmap

Technical: place order API

• Request parameters: shop_ids, buyer_id, item_qty
• Internal logic (business requirements): order types, item promotions
• External Dependencies: other APIs, Database, Cache, kafka, error handlings, fallback logic
• Integration (end-to-end): Frontend, upstream/downstream APIs, race conditions, edge cases

Overview of API Mindmap

Steps

After you reach the point that you are unable to break down the category further, it should be a hint to start writing your steps which can be described as the testing action to execute the test case. Furthermore, the testing steps serve as one of the most crucial references when we are doing automation testing. I will pick one category to describe in my example below.

Non-technical: volleyball

Touch (Beach Volleyball)

1. Hitting the volleyball with an adult hand palm towards the ground.

2. Hitting the volleyball with adult hand fingers towards the ground.

Technical: place order API

Request parameters

1. Sending combined multiple shop_ids [1212, 1234, 1512] to place order API in a single request via postman
2. Sending an insufficient item_qty to place order API via postman

Expected Result

When a testing step is described, one should already have an expected result in mind. Be it right or wrong, it can be clarified later with the respective stakeholders when the test case design is completed. With the condition that it must be measurable as much as possible for the benefit of readability and assertions in automation testing. Upon finishing this phase, the test case design should be ready for review by anyone. (Senior QA, Product Managers, Developers)

Non-technical: volleyball

Touch (Beach Volleyball)

1. Ball able to bounce back up to the adult height (180cm).
2. Ball drop on the ground with no bouncing.

Technical: place order API

Request parameters

1. API response with an order_id.
2. API response with insufficient_stock_error_code.

Detail

Last but not least, when the test case design is finalized it should come with a detailed column for each row of the test cases. It serves as an initial artifact for the tested logic and behavior. It can be referred to in any stage of SDLC after testing.

Non-technical: volleyball

1. Link to video of ball bouncing.
2. Speed and time took for the ball to bounce back.

Technical: place order API

1. Sample log of place order API with request and response from the server.
2. Sample log of item API with request and response from the server.

Summary

A good test case design should have multiple categories, steps, expected results, and detail with but not limited to the below quality:

• Able to speak by-itself. (with no to minimum explanation)
• Precise and measurable for automation testing.
• Reusability: flexible enough for any ad hoc changes.
• Effort estimation based on test count and complexity.

What after a good test case design? Make it interesting and fun!

• Have your peers review your test case design.
• Review and challenge the code from the merge request.
• Build the tool you need to generate the test data.
• Call the dependencies API to meet your test data requirements.
• Create/Maintain your test automation framework (UI/API).
• Continue to learn, explore and mentor.