How to write test cases

Our service EasyQA contains the simplest but the most varied functionality which will help users to write test cases easier and faster.

USEFUL LINK: EasyQA YouTube channel

In our article we give answers to the following questions:

Test Case? What is this?

There is no doubt that the writing of the effective Test Cases is the must have skill for QA specialists. Like to any skill it could be acquired and improved. The main principles and tips of effective Test Case writing will be considered in this article.

Before starting it, let us to fully understand what the Test Case is. Imagine you need to test some functionality of the application.  You should step by step initiate the situation where it could be implemented.

Put it simply, Test Case is a set of such well-designed and easy understandable steps (actions) executed to verify a particular feature or functionality of your software application.  Keep in your mind “well-designed” and “easy understandable”. It has an important sense as you will see a little later.

So, now we can start. Here we will divide Test Case to the components and try to analyze what should be done as well as what shouldn’t be to write it with high efficiency.

The main parts of the Test Case


Test Case ID

This is a unique number of Test Case in test management system or in document. As a rule all modern test management systems like Jira, TestRail, and Zephyr automatically to assign the ID to new created Test Case. So, there is no ability to make a mistake with this component.

But, it should be noted, that on some projects is still used Excel for testing. That is why you always should to remember the rule: “There are no Test Cases with same ID in you test management system. Even these are Test Cases from finished projects”.

Test Case Title

Strong Title is the mandatory attribute of the effective Test Case. What does it mean?  The key features of the strong Title are: easy to understand and laconic. Besides that, Test Case Title must to represent the module name or functional area you are going to verify.

Let imagine that we have a task to check what will be happen if we input invalid symbols like $,&, * in the "e-mail" field of the registration form of Test Management System EasyQA. According to the above mentioned principles, the Test Case Title should be look like: "E-mail field invalid input in the Registration form".

Let's consider the example of not strong title. "E-mail field "$&*" symbols input in the Registration form of the “EasyQA”. Here we have at least two mistakes.

  • The excessive length of the title. There is no need to mentioned “EasyQA”, because this Test Case is a part of Test Plan for this Test Management System. So, all test cases are concerned to “EasyQA”.
  • Concretization of the special symbols "$&*". Other invalid symbols also could be inputted for executing this kind of test case. So, "invalid symbols" is more suitable definition for this title.

Some Test Management Systems, including EasyQA, simplify this process by creating special module field for each Test Case.

Test Plan is divided into modules, which includes particular Test Cases. That is why it is easier to create strong title for test case.

Test Case Description

Before starting testing, you should to mention all the details about what you are going to test. They are: Test Data to be used, Preconditions (Presteps), Test Environment Details, Testing Tools.

If you give Test Data to be used wherever applicable for the Test Case within the test case description or with the specific Test Case step, you will help not only yourself, but your colleagues-testers too. There is a serious mistake to write Test Cases only for yourself.

Preconditions (Presteps) describe different kinds of the Test Execution dependencies:

  • Any special set up is needed to be done
  • Dependencies on any other Test Cases – does the Test Case need to be run before/after some other Test Case
  • User data dependency - which page should the user start the journey; the user should be logged in.

Test Environment is a setup of software and hardware for the testing teams to execute test cases. In other words, it supports test execution with hardware, software and network configured.

When people mention about Testing Tools, Automated Testing is often suggested. Of course they are previously concerned to this type of testing. But there are also simple tools for Manual Testing. Mind mapping tools like Xmind, screenshots managers like Jing are easy to use even for new comers to QA area. Anyway, if some special tool is mandatory for testing you should mentioned it in Test Case Description.

Of course, if the same Tool is used for execution of some group of Test Cases, it would be better to describe it on Test Module/Submodule or even in the Test Plan.

There is some kind of typical mistake you should focus on. Some testers with less of experience confuse Steps with the Presteps. Make a note, that Presteps is the way to getting situation the Test Case Execution could be started. Steps are the most effective way to get the Actual Result of the Test Case Execution.

For example, if we have to test the functional abilities of registered user, there would be mistake to create special user registration steps for each Test Case in appropriate module. The right decision is to display it in the Presteps for all register user Test Suites module: user should be registered. The process of registration is verified in particular Test Suite.

As it was mentioned before, Steps are the way to the Expected Result. Another thing that should be remind Steps in the effective Test Case are well-designed and easy understandable. These two points are the basic for understanding how to plan Steps for you Test Cases.

The main attributes of well-designed Steps:

  1. Optimal quantity of Steps. No need to write additional steps as well as “to eat” step. The things looked obviously for you, couldn’t be so clear for your colleagues.
  2. One Test Case covers only one independent functionality. There is a mistake to verify different functionality in one Test Case.
  3. Steps are easy executable.
  4. Steps should not only cover the functional flow but also each verification point which must be tested.

The main attributes of easy understandable Steps:

  1. Steps are to-the-point. You shouldn’t write an essay to describe your Steps.
  2. Clear expression. You should avoid using ambiguity in your Test Case Steps.
  3. Understandable even for beginners. Your colleagues, who probable are not so experienced should be able to understand how to execute each Step.

The application performance after executing the above testing steps is displayed in the Expected result. So, before writing Test Cases, you should fully recognize what page/screen you expect to appear after the test and, any updates you expect as an outcome to be made in back-end systems or database.

Hope, you remember that one Test Case covers one independent functionality. That is why, it would be a mistake to write Test Case with more than one Expected result.

Comments/Post Conditions are not mandatory components of the Test Case, but it really makes higher the efficiency of you Test Case. Here you can put additional helpful information like screenshots and descriptions to provide the developers with the information they will need to correct any defects found.

Post Conditions are also used to give guiding instruction to restore the system to its original state for it not to interfere with later testing. For example, this is quite useful if you mention the changes to be made to a Test Data for it to be used for a later Test Case for the same functionality.

Different Test Management systems offer variety variants of Test Case field. The test case in EasyQA Test Management tool has the following ones:

  1. Title
  2. Module – to choose the module our Test Case refers to. – If you press Add case in the module, this field will be entered by default.
  3. Type – select a type of the test case from drop-down list according to the following description:
  • Positive is a test case using only correct data.
  • Negative is a test case using not only correct data.
  • Boundary is a test case using max/min values.
  • Integration is a component of integration testing.
  • UI is testing of a user graphic interface.
  • Localization is testing of locations, languages etc.
  1. Pre Steps
  2. Steps
  3. Expected Result

In this picture you can see the process of test case adding with the fields filled in.

Once you have added the Test Cases you can choose them with the corresponding check boxes. After you have chosen one or few test cases you can move them where you need them to be. You are able to edit or delete them.

Test Case Simple Example

Now, when you have some theoretical knowledge about writing Test Cases, try to use it for next task decision.

Task data:

  1. There is a Test Management System “EasyQA” -
  2. You have to verify registered user ability to create new Test Plan for project called “Blogger” according to the specification.
  3. User e-mail is “[email protected]”, password is “gEORGe52”

Let’s consider how to create each step.

Of course, the unique ID will be automatically assigned by Test Management System you use.

Firstly, you should to do is to choose the appropriate title, module, and testing scenario for Test Case. Naturally, the module could be “Registered user”. And other Test Cases testing registered user functionality will be put to this module. The strong Title looks like “Test Plan creation ability”.  Test scenario is positive.

As well as you have to check registered user functionality, you need to display the way to registration in the Pre Steps. These Pre Steps will be the same for all Test Cases in the “Registered user” module.

In Steps field you have to show how to achieve the Expected Result.

Let’s determine Expected Result as “Registered user has an ability to create Test Plan”.

We can see result of our actions using EasyQA Test Management tools.


Login and password form Test Cases: Positive, Negative, Boundary

Let’s consider some typically Test Cases based on different scenario.

Task data is almost the similar to previous task:

  1. There is a Test Management System “EasyQA” -
  2. “Sign Up” form is needed to be tested.
  3. Minimal length of password is 6 symbols. Maximal length is 128 symbols
  4. You can use only Latin alphabet letters from A to Z and figures in “Login”, “Password”, “Confirm Password" fields.

Here we consider some specifies of this kind Test Cases creation process.

EasyQA “Sign Up” form has following mandatory field: “First name”, “Last name”, “Email”, “Password”, and “Confirm Password». Besides that, there are other fields like “Company” and “Country”, which are not mandatory, but also have to be tested. So, you should divide you “Sign Up” Test Suite module into appropriate sub modules.

Try to analyze some typical scenarios: positive, negative and boundary.

According the Positive scenario, unregistered user inputs only valid data into all fields. So you won’t have problems with creation such kind of Test Cases. You can see how it could be looked at the picture below.

The Expected Result for this Test case is “Latin letters and figures input is possible in the “Password” field”.

But, what will be happened if user enters the invalid symbols in any of previously mentioned fields? We can check it executing Test Cases based on Negative Scenario. In fact, there are plenty of invalid input variants. It could be considered in particular article. Here are only some of that:

  • “&%$” symbols input
  • Spaces input
  • Empty field input
  • Combinations of invalid and invalid symbols input
  • Another cases letter input etc.

At the picture below an example of negative Test Cases is represented.

The Expected Result for this Test case is “Invalid input is impossible in the “Password” field”.

Pay attention to the condition – password length restriction (6-128 symbols). Is it possible to be registered with only 3 symbols password? What about 150 symbols password? Test Cases written by Boundary Value Testing design technique give you answers to these questions.

The basic idea in Boundary Value Testing is to select input variable values at their: minimum, just above the minimum, just below the maximum, maximum. In our example you should write Test Cases for situations with:

  • 5 symbols password input
  • 6 symbols password input
  • 128 symbols password input
  • 129 symbols password input.

Look at the picture below to see how looks Test Case written according to this technique.

The Expected Result for this Test case is “Informational message "The minimal length of password is 6 symbols» is displayed”.

Test Cases for Filter criteria

Different functionalities like searching, ranking, paging also are needed to be tested. These Test Cases also could be written according to scenarios we considered before. They verify normal functioning of:

  • Search fields
  • Page buttons
  • Arrows
  • Ranking by name (A to Z, Z to A)
  • Ranking by price (lowest first, highest first)
  • Dashboard and sidebar menu buttons etc.

Come back to EasyQA Test Management System and write a simple Test Case for checking "Closed issues" button filtering functionality. Here it is.

The Expected Result for this Test case is “Only closed issues are displayed on dashboard menu”.

Test Cases for Security Testing

Security Testing is often provided by special Automated Testing tools like Vega, Google Nogotofail, Wapiti etc. But using you mental activity skills you can write simple Test Case for checking some safety parameters of web site. Come back again to EasyQA Test Management System.  You can see an example of such Test Case below.

Pay attention to the Steps. The Expected Result for this Test case is “EasyQA  Sign In form is displayed after copy/pasting URL from one browser to another”. So, there is no access to user account.

EasyQA Test Management System additional useful features

There are plenty of Test Management tools for helping testers in their work.  EasyQA gives you a wide range of additional useful features:

  1. Export a prepared test plan in CSV format by one button pressing
  2. Import a prepared test plan to our system.
  3. Test Case displaying by various criteria:
  4. Making crash reports
  5. Build distribution
  6. Bug Tracking System
  7. Execute testing
  8. Generate reports
  9. Quick and easy integration with your existing tools.

Put it simply, EasyQA is more than Test Management system. It is an environment for pleasant and efficient work.

10 tips for writing effective Test Cases

  1. Keep on mind, that Test Cases are executed also by your colleagues
  2. Use strong Title
  3. Pay attention to the Pre Steps and Preconditions
  4. Test Case covers one functionality and
  5. Test Case has only one Expected Result
  6. Write well-designed and easy understandable steps
  7. Don’t forget to put the all useful information in the Comments or Post Conditions
  8. Use illustrations and simple testing tools if it is necessary
  9. Test Case must be reusable
  10. Start to practice

Do you want to write effective Test Cases? Just begin to do it. And it will be our pleasure to help you.