Writing test cases can be a daunting task when sitting down to tackle it all at once – i.e. after all tasks have been completed and you’re wanting to do a final testing round (or UAT) prior to launch. Also, making sure that you capture every single possible edge case can seem overwhelming. The best way to break it down is to tackle this throughout the build process so that when you enter final UAT, the work is already done for you! In this post I’ll outline how to write thorough and effective test cases that will help you improve the quality of output for your team, helping you catch bugs and un-managed edge cases before they go to production.

Writing test cases during the active build phase

Oftentimes we just send something over the fence for testing, such as “test the featured resources block.” 

Let’s take a step back: what does it really mean to test the featured resources block? 

The best way to think about this is to put ourselves in the shoes of someone who has absolutely no idea what this feature is or does (but we can safely assume they do have some basic technical abilities).

With that lens, we see there are a few parts to it: content has to be entered in the CMS and then we have to ensure it appears on the frontend as expected. Then we have to test out other configurations and edge cases to ensure we’ve covered all our bases. 

This leads us to the three elements of effective test cases:

1. The steps someone has to take to achieve the expected outcome 
2. The expected outcome when they follow those steps
3. Other acceptance criteria for us to consider this a success

Ask yourself: What steps do I need to take to achieve my expected outcome?

Steps:

• Step 1: Log into the develop CMS here: myurl.com/cms-login
• Step 2: Navigate to the promo block curation page (create > promo block).
• Step 3: Fill in the fields: title, body, image, CTA, and url
• Step 4: Click save
• Step 5: Navigate to the frontend of the page (myurl.com/page) and view the featured resources block. 

Next, ask yourself: what are we expecting to happen if we follow the above steps?

Expected outcome:

• You should see a featured resources block that looks like mock underneath the article and before the recommended section.
• You should be able to click the CTA and arrive at the url.

Ask yourself: what else needs to happen for us to consider this ticket complete?

Acceptance Criteria:

Some ideas: entering invalid characters, leaving some fields blank, testing on different breakpoints / browsers / AMP, putting in images that are too large / too small, etc. Think about the expected outcome as your “happy path” and the acceptance criteria as your edge cases.

• This should look like the mock on desktop, tablet, mobile, and AMP.
• If styling html is entered into any of the fields, it should be ignored on the frontend.
• If a portrait image is input, it should stretch to fill the square. 
• If a square image is input, it should fill the space available.
• If over 140 characters are entered into the body, the rest of the text should truncate.
• The CTA button should have a hover state that matches the mock.
• The CTA button, once clicked, should open in a new tab.
• If the url field is left blank, the CTA button does not appear and the box condenses.

If all of the above bullet points pass, then we can say our acceptance criteria has been met and the ticket is approved.

Re-testing prior to launch

The final testing phase, or UAT (user acceptance testing) phase, should happen after you’ve brought all of these (previously tested) puzzle pieces together. Since we know we’ve already tested each of these items thoroughly and for all possible edge cases, we just need to ensure all of the elements have been brought together successfully and there are no regressions. 

At this point you have two paths:

1. Have everything re-tested as thoroughly as it has been previously, following the same test cases as before.
2. Re-test everything holistically from a higher level (this is generally what I follow).

When following either path, pulling all of the necessary test cases together from your tickets into one place (such as a spreadsheet or a Kanban board) will give you a overview of your work in one view, and make everyone’s job easier.

Once all test cases are approved, you should feel confident that you will be launching bug-free (or as close to that as possible!).

Additional reading:

> Read more about Kanban boards in What is a Kanban board and when should I use it?
> Learn how to design and create a Jira workflow in How do I design and create a Jira workflow
> Understand more about team velocity in Understanding Scrum Team Velocity