Articles in this section

Test Case creation guide

Avatar
Tester Work
  • Updated
Follow

 

Clear. Thorough. Consistent.

 

    1. Clear

The test cases converted/created by us should always be simple, clear & concise for our testers (mainly - because they will interact 1st hand with them) and ultimately to our customer's satisfaction.

It is very helpful - from a creator perspective - to always go through the flows/scenarios as you would execute them and make sure the person who will execute them is able to clearly & easily understand the  instructions from an English perspective as well as a functional perspective. 

  • As a tester, I expect to understand the English level and to be guided through the app in a clear, direct and fluent way.

    2. Thorough

The customer is confident that all the features are thoroughly and extensively tested during the test case execution rounds so it's very important to find a balance between elaborating instruction / steps to reproduce and leaving out details due to already too many details.

  • As a customer, I expect to have the entire app covered before an important release.

     3. Consistent

Always write the test cases in the same manner indifferent of the app/customer. We need to be able to show the same level of quality and detail each time we create a new suite of test cases. 

  • As a customer, I expect the test case suites to have the same layout, structure, and overall quality every time. 

 

Best practices!

  • When converting/creating test cases that were received from a customer, always be sure to check them against the app or website that is in the scope of the creation round. Usually, the documentation that we receive from our clients is:

    • not-up-to-date with their app/website; 

    • do not cover the entirety of the product;
    • inconsistent in terms of language/vocabulary, formatting, logical order - aspects that contribute to a very poor experience & quality in terms of understanding (functionality) and results;

  • It is not encouraged to copy the information from the provided documentation and simply paste it in your working document and manipulate it via small changes. This will take much more time & effort than creating them from scratch and the quality & effort is easily comparable;

  • Always apply the same formatting and structure when converting/creating test cases, unless the indications of the creation round instructs you otherwise;

  • Unless otherwise instructed, include all scenarios you've managed to find while getting used to the app - including negative scenarios (where the outcome of the test case is expected/intended to be failed);

  • As mentioned above, it's critically important to make sure the tester will check every element available while maintaining a clear and concise test case structure regarding the expected behavior;

  • The tester must understand the application while using it in order to avoid false positives due to unclear functionalities - make the test case as logical as possible;

 

Getting started

A. Familiarize yourself with the application

  Even if the creation scope is limited to a few specific scenarios, it is of utmost importance that you familiarize yourself with the entire application - many applications have systems that interact in discreet ways (eg. a setting that slightly changes the UI, such as region-specific features) which may affect even the limited scope of the test case suite.

   Before starting to create the flows, take as much time as you need to properly understand how the application or website functions. This will give you a panoramic overview of your task and will give you a more complete picture of how to reach the goal of the task more easily.

 

💡 Useful steps to perform:

  • Use/check every button;

  • Change every setting;

  • Check every section to see what has been affected by the changes and how;

  • Understand how the application functions;

  • Play around with anything and everything, consider it a free-for-all Functional Exploratory check;

  • Never limit yourself to what is immediately obvious because this can lead to late & unexpected/unpleasant surprises;

 

B. Identify and isolate the layers of functionality

  Every piece of software is composed of layers of different systems that interact with each other. For instance, when considering a video streaming app such as YouTube, these have two major layers: the account management system, and the video streaming system. YouTube’s basic video streaming system can be used with or without an active account (videos can be watched without issues), but several advanced features are unavailable if you are not logged in (eg. the Watch Later feature, the Likes system, the Playlist creation system, etc.)

  This means that the account management system directly affects the video streaming system and scenarios should be developed to cover both possible situations and all affected elements. This can also apply to apps that offer Free and Paid variants (more features will become available once the free user becomes a paid user), applications containing region-specific features (eg. a shopping app will offer USPS settings when the user is detected as being within the US, settings which won’t be available to a user from Europe), and many more.

  An essential element of the test case creation process is identifying these layers and the interactions between them, as not all layers have the same magnitude of effect on the application. This will help immeasurably in forming a logical journey through the app.

 

💡 Useful steps to perform:

  • Identify the base functionalities / settings - they are the ones that are affected the least when changes are made (logged in vs. logged out, as this layer exists before the user reaches the app’s main features), but which affect the largest percentage of the application when changed;

  • Identify the secondary/tertiary/etc. layers - they are generally more fluid in terms of functionalities (a Free user will have far fewer functionalities available to them than a Paid user, meaning that the functionalities available to Free/Paid users are secondary to the account system layer);

  • If there is no obvious delimitation between the application’s layers in terms of significance, isolate them by interactions:

I.e.: an application that supports setting different themes will not have its functionalities affected by the themes themselves, but the UI design will generally vary greatly from one theme to another - this must be taken into consideration when performing visual and functionality checks, as, for example, a button may have its tappable area misaligned with its graphical element when using a specific theme.

 

C. Make the logical breakdown and journey

After having familiarized yourself with the entire application and identified the various layers of functionality, organize your notes in the most logical and free-flowing manner possible - you should end up with a tour through the entire application with as little backtracking as possible. The easiest and most straightforward way of composing a logical test case journey is to go from high-level changes to more granular ones. 

Using YouTube as an example, a potential test case structure for the video streaming layer should look like this:

  1. Access YouTube without an active account (instruction):

    • Ensure that the basic video streaming system works as intended (expected behavior to validate/check):

      • Videos can be played without issues;

      • Playback options (resolution, speed, volume, closed captions) work as intended;

    • Ensure that the advanced video streaming functions are not available;

  2. Log into a valid YouTube account (instruction):

    • Ensure that the basic video streaming system still works as intended (this step can be compressed down to a quick recheck of scenario 1a - expected behavior to validate/check):

      • Videos can be played without issues;

      • Playback options work as intended;

    • Ensure that the advanced video streaming functions are available (instruction);

    • Ensure that the advanced video streaming functions can be used without issues (instructions);

 

💡 Useful steps to perform:

Cluster the changes you want to cover in your test cases in an episodic manner - segment them based on changes you can bring to the base layer of functionality:

    1. Base change 1 (eg. not logged in):

      • check the secondary layers 

        • check the tertiary layers

      • modify the secondary layers 

        • re-check the secondary layers

          • re-check the tertiary layers

    2. Base change 2 (eg. logged in)

      • check the secondary layers

        • check the tertiary layers

      • modify the secondary layers

        • re-check the secondary layers

          • re-check the tertiary layers

If there is no obvious differentiation between the various layers of the application, cluster the changes in whichever way seems the most logical and easiest to follow.

 

Specifics

A. Formatting

  1. Always write a single sentence for each action and each expected result

  2. Always use straight sequential numbering for steps and expected results, as this will help with the test case count - it is always easier to add two numbers than to count all verbs

    • Avoid using skipped numbering for Expected Results (eg. steps are 1 - 2 - 3, expected results are 1 - 3, as step 2 has no check attached to it) as it’s an unusual procedure and will lead to confusion more often than not

  3. If the expected result implies a content check, formulate it as a list - it will be counted as a single step

Test case ID

Section

Sub-section

Steps to reproduce

Expected result

TC-01

Section 1

Sub-section 1

  1. Action 1

  2. Action 2

  3. Action 3

  4. Action 4

  1. Expected result 1

  2. Expected display 1

  3. Expected content 1:

    • item 1

    • item 2

    • item 3

    • item 4

  4. Expected result 2

 

B. Content

  1. Always formulate clear and concise sentences - each step must indicate a single action.

    • Exception: when a scenario includes a process that has already been covered (eg. logging in, creating an account, etc.), it can be shortened to a single step (eg. "Log in"), or be conveyed through only the essential steps required to fulfill the process.

  2. It is not necessary to have the same number of steps and expected results within a single scenario - try to link the expected results to their related steps through contextualized formulations.

    • Example: "When tapping the “X” button, the application must [...]"

  3. Avoid covering the same expected results in multiple scenarios - if you've already been through all of them once, it is ok to forgo their usage.

    • Exception: this does not apply when the context of the application changes significantly around the tested features (eg. more options become available when upgrading an account), as these new features may still have an effect on elements that have been covered.

  4. Always highlight specific in-app names for features, buttons, sections, etc. with quotation marks. For example, if the application's log in button has the [Log In] label, use "Log In" when referring to it within the test case.

 

C. Structure

  1. When creating any test case, the very first scenario must be centered around the first thing you see in the application. This also applies when the test cases are created for a limited portion of the application - start with the first screen / functionality / flow encountered within the said portion.

  2. Always structure the test cases so that they form a journey, not a list. This will make test cases much easier to follow, as well as offer the testers a greater understanding of how the application is intended to function.

  3. Always start the test case flows with the scenarios which lead to the least amount of progress navigation-wise. For example, when covering the log-in flow, the natural scenarios are: 

    • "no input - click log in > error"

    • "invalid email input - click log in > error"

    • "invalid password input - click log in > error"

    • "valid inputs - click log in > logged in"

    In this case, the scenarios should be arranged in the order exemplified above, as all four scenarios can be covered without leaving the targeted section.

  4. Avoid using redundant navigational/set-up instructions for scenarios that take place within the same section where the tester has been guided to in the previous ones - scenarios should flow one into the other, not reset the tester’s progress each time a new scenario is reached.

    • Example: once the tester has been instructed to proceed to a certain screen, treat all subsequent actions as a coherent whole - there is no point in instructing the tester to log in and proceed to the profile page to change their avatar, only to then instruct them to log in and proceed to the profile page again in order to change their profile name;

  5. When making combo test cases for two applications that interact with one another (for example an app that has a front-end for the user and a set-up back-end for the admin), structure the test cases so that the jumps between the applications are as few as possible while covering as many functionalities in one leap.

  6. Avoid too many section switches within the same scenario:

    • if the action is a general functionality check (eg. clicking "Next"), move it to the first scenario related to the subsequent screen / section;

    • if the functionality is an integral part of a flow (eg. clicking "Sign Up" after inputting required information), keep it in the same scenario - in this situation, add the subsequent section's basic content / display expected results within the same scenario as well;

    • If the action leads to briefly checking a dead-end page (eg. a brief “How To” article which has no further redirects) and the tester must then return to the initial screen, add the navigation to and from the dead-end page in the same scenario;

Test case ID

Section

Sub-section

Steps to reproduce

Expected result

TC-01

Account set-up process

Sign-up screen > Welcome

1. Launch the application

  2. Select "Sign up" from the lobby screen

  3. Input a valid email

  4. Input a valid password

  5. Tap "Sign up"

  1. You are taken to the lobby screen after launching the application

  2. The sign-up form page is displayed when selecting "Sign up"

  3. The "Sign up" form page contains the following elements:

  • an "email" field
  • a "password" field
  • a "Sign up" field
  • a "Terms of Use" hyperlink

  4. Values can be input without issues within the form

  5. The user is taken to the "Welcome" screen after providing a valid email / password combination and selecting "Sign up"

  6. The "Welcome" screen contains the following elements:

  • a "Welcome to Unicorn Land!" header
  • a paragraph containing starter tips and a funny message
  • a "Next" button

TC-02

Terms of Use

1. Select "Terms of Use"

2. Select "Back"

  1. The user is taken to the "Terms of Use" page

  2. The page contains no display or grammatical errors

  3. Selecting "Back" returns the user to the "Welcome" screen

TC-03

Welcome > Home screen

1. Select "Next" within the "Welcome" screen

  1. You are taken to the application's Home screen

  2. The Home screen contains the following elements:

  • the "Unicorn Land" logo
  • a "Unicorns" button
  • a "Gear" button
  • a "Friends" button
  • a Settings (gear wheel) button
  • a Profile button

  3. There are no display or grammatical errors

 

A structured set of test cases

Test case ID

Section

Sub-section

Steps to reproduce

Expected result

TC-01

Lobby

Lobby

1. Launch the application

  1. The Lobby is reached

  2. The Lobby contains:

  • (list of elements)

  3. There are no display or grammar errors

TC-02

"Sign Up"

1. Tap "Sign Up"

  1. The Sign-up page is reached

  2. The Sign-up page contains:

  • (list of elements)

  3. There are no display or grammar errors

TC-03

"Sign Up"

1. Tap "Sign Up" w/o inputs

  1. Errors are displayed for both fields

  2. The user remains on the “Sign-up” page

TC-04

1. Input incorrect values in all fields

  1. Errors are displayed for both fields

TC-05

Home screen

1. Input correct values.

2. Tap "Sign Up"

  1. The inputs are accepted

  2. The user is taken to the Home screen

  3. The Home screen contains:

  • (list of elements)

TC-06

Home screen

Settings

1. Tap Settings

  1. The Settings page is reached

  2. Settings contain:

  • (list of elements)

  3. Settings display OK

TC-07

Settings

Lobby

1. Tap "Log Out"

  1. The user is logged out

  2. Redirected to lobby

TC-08

Lobby

"Log In"

N/A

1. Tap "Log In"

  1. Log-in is reached

  2. Log-in contains:

  • (list of elements)

  3. Lobby display OK

TC-08

"Log In"

1. Tap "Log In" w/o inputs

  1. Errors displayed

  2. Can't advance

 

In the example above: 

  • The first screen within a hypothetical application is the Sign-up / Log-in screen (the Lobby). In this case, the structure of your test case should look something like this:

    • Lobby 1: covering the Lobby's overview (display, grammar, availability of intended buttons, etc.)

    • Lobby 2 / Sign-up 1: tapping the first button - generally "Sign Up" (the user can reach the next page) + covering the Sign-up's overview (display, grammar, availability of intended buttons, etc.)

    • Sign-up 2: covering the functionality of present elements (input fields, warnings for incorrect inputs, buttons, etc.)

    • Sign-up 3: covering the Sign-up flow (correct inputs, account created, etc.)

  • After this point, the user is generally logged into the application with the newly-created account:

    • Home screen 1: covering the Home screens’ overview (you can merge this with the previous Sign-up case)

  • Considering there are still elements left uncovered in the Lobby, orient the flow towards the log-out functionality:

    • Home screen 2: navigate to log-out (cover content of its parent section, display, grammar, and finally the log-out functionality)

    • Lobby 3 / Log-in 1: tapping the second button - generally "Log In" + covering the Log-In's overview

    • Log-in 2: covering the functionality of present elements

Related articles

Comments

0 comments

Article is closed for comments.