How to Write Test Cases with the Help of Business Requirement

Test cases are an important part of any project or test document because it is the first step in any test cycle, and if you do any mistake at this step, effects are extrapolated as you move forward in software testing life-cycle. Test Case acts as the starting point for the test execution and after applying a set of input values, the application has a definitive outcome and leaves the system at some endpoint. Test cases can be organized into groups called test scenarios or test suites.

Before we move right on to the tips, lets concisely understand, “What is a Test Case?”

“A test case is a combination of test inputs, execution steps, and expected results developed or to verify with a specific requirement.”

Source: http://testorigen.com

While the Development team start to builds the software system, the testing team gets ready for the test cases that would help us test the system once it is ready, i.e. at the end of the code phase.

You can use start writing test cases on the excel sheet. You can continue with excel or choose open source or paid test case management tool from the variety of lists like Quality Center, Test Director or TestLink etc. These tools support excel import feature so that you can import above written test case easily.

Why we write test cases?

The basic purpose of writing test cases is to validate the testing coverage of the application. You will find that there are some organizations where follow test cases standards mandate. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

Types of test cases

There are two types of test cases as mentioned below:

  1. Formal test cases: We create formal test cases according to known input and we characterized it by an expected output, which is worked out before the test is executed. we can get all the information in it like preconditions, input data, output data, postconditions, etc. with predefined inputs which will provide the expected output.
  2. Informal test cases: We create Informal test cases without having exact requirement input and output. In order to test them, the formal test cases are not authored but the activities are done and the outcomes are reported once the tests are run.

Big Confusion between Test Cases and Test Scenario

In easy term, we can say that Test cases are derived (or written) from test scenario. The scenarios are derived from use cases. Whereas A test case is a set of steps to be executed by the tester in order to validate the scenario. Once these test scenarios are determined, test cases can be written for each scenario. Test scenarios are the high-level concept of what to test.

  • Module Name: Mention the name of the main module or the sub-module.
  • Test Designed By: Name of the Tester
  • Test Designed Date: Date when it was written
  • Test Executed By: The Tester who executed this test, name of that tester to be filled on this field only after test execution.
  • Test Execution Date: Date when the test was executed.
  • Test Case ID: Unique Test Case Identification Number for each test case.
  • Prerequisite: Conditions that must be met before the test case can be run. For example, the user must be logged in.Any prerequisite that must be fulfilled before execution of this test case. List all the pre-conditions in order to execute this test case successfully.
  • Case Summary: A short sentence about what is being tested and.
  • Test Data: List of variables and possible values used in the test case. Examples: Username = {Valid Username, invalid username, valid email, invalid email, empty} password = {valid, invalid, empty}.Use of test data as an input for this test case. We can provide different data sets with exact values to be used as an input.
  • Test Steps: Detailed steps for test case execution. List all the test execution steps in detail. Write test steps in execution order in which they should be executed. Make sure to provide as many details as you can. Tip – In order to manage a test case efficiently with a lesser number of fields use this field to describe test conditions, test data and user roles for running the test.
  • Expected Results: How the application should perform after executing the above testing steps.What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on the screen.
  • Actual Results: How application actually behaved after executing the above testing steps. Describe system behavior after test execution.
  • Result/Status: Does the test “Pass” or “Fail”.If actual result is not as per the expected result mark this test as failed. Otherwise, update it as passed.
  • Comments/Notes/Questions: This is where the tester can add additional helpful information like screenshots and descriptions to provide the developers with the information they will need to correct any defects found.We can write the things or special conditions here which support the above fields, which can’t be described above or if there are any questions related to expected or actual results then mention them here.

Note: This is a standard test case format. Specific fields may vary from company-to-company. In addition to these fields, we write the QA reviewer, Modified by, Date Modified, Date of Execution Start, Executed by, Date of Execution End, QA cycle No, Cycle Status.

Details of Test Case Development

In simple terms, we can say that a test case is a document which describes pre-conditions, input, set of execution steps and Expected result. An effective test case is the one when with the help of it we can find defects and it must be cover all the combinations or we can say cover most of the test scenario on the system under test. It can be any application or any website or any software.

Here is the step by step guide on how to write test cases:

1) Detailed understanding of the application under test

  • Before writing test cases, we should have a detailed knowledge of the application which we are going to test.  We should try to get as much information as possible through available documentation such as software requirement specification ie. SRS, with the help of use cases, user guides, tutorials, or by having hands on the software itself.
  • Collect all the possible positive scenarios which tend to forward sequentially and also the odd cases which can fail the system (Destructive testing) such as stress testing, uncommon combinations of inputs etc.

2) Written in simple language

  •  While writing a test case, You should keep in mind to write in a simple and understandable language means easy to understand so that a new person can also understand without having the knowledge of application requirements.
  • Use assertive language like go to home page, enter data, click on this and so on.
  • Steps should be point to point and accurate so that client or anyone can be able to execute easily.
  • Exact and consistent names for e.g. of forms or fields under test must be used to avoid ambivalence.

3) Test case template

Let us look at each parameter should be included good test cases:

i) Test Case ID: This field depends that what type of system we are going to test. Standard rules are as follows:

  • If there is an application which doesn’t have any module and we have to create test cases for that then Id would start as TC001 or TC_01.
  • If there is an application which is module specific then Test Case ID would be like Module Name 001 or Modulename_01.
  • Sometimes it might be possible that a test case has more than one expected result then we make it as version number wise. E.g. TC001.1, TC001.2 etc. All these test cases are the subpart of TC001.

In this way, we can maintain all the test case IDs and we can change it if any requirement gets changed or added then we can just add new test cases.

ii) Test Case Name: By the name of the test case id they are identified easily when finding bugs or identifying a software requirement at a later stage. This field of test cases contains following things:

  • Requirement number from the specifications
  • Requirement name as classified in client’s document
  • Name of the feature you are testing
  • Name of the particular field
  • Name of a particular Button or input box

iii) Description: In the description field you should write what you are going to test and include any other relevant information such as the test environment, test data, and preconditions.

iv) Pre-Conditions: When the system needs to be in a particular base state for the function to be tested, these preconditions should be defined clearly. Preconditions must be met prior to the test being executed.

Pre-conditions could be:

  • A certain page that a user needs to be on
  • A certain data that should be in the system
  • A certain action to be performed before “execution steps” can be executed on that particular system.

v) Execution steps: We must be followed these steps to get the expected output.Steps must be defined in a clear manner and must be precise. They are written and executed number wise.

vi) Expected Results: These are the expected outcomes from the execution steps performed. We should write Expected results for each step. It describes what the client expects from that particular activity.

vii) Actual result: In this field, we write the actual outcomes after the executing the steps. when we execute the test cases and if we find that the results match with the expected ones then we mention that “As expected”, otherwise we need to mention the exact result observed.

viii) Status: This field can have following values based on the actual result we got, they are:

  • “Passed” – The expected and actual results match
  • “Failed”- The actual result and expected result do not match
  • “Not tested”- The test case has not been executed
  • “Not Applicable”-when the requirement changed or modified then test case does not apply to the feature.
  • “Cannot be tested” – This may be because precondition is not met. There could be a defect in one of the steps leading up to the function under test.

ix) Comments: This column is for additional information. So for e.g. if the status is set to “cannot be tested” then tester can give the reason in this column.

Conclusion

Test case creation vastly depends on the detailed understanding of the requirement. The requirements are given by the client is not only the sufficient factor, but think from a user point of view is also important while writing test cases.

I hope I am clear on the topic by far. But, what are you waiting for now? Learn, grasp and start writing Test Cases now!!!

Follow me!

1 thought on “How to Write Test Cases with the Help of Business Requirement”

Leave a Comment