How to write Test Case ?

Designing test cases can be time consuming in a testing schedule, but they are worth giving time because they can really avoid unnecessary retesting or debugging or at least lower it. Organizations can take the test cases approach in their own context and according to their own perspectives. Some follow a general step way approach while others may opt for a more detailed and complex approach. It is very important for you to decide between the two extremes and judge on what would work the best for you. Designing proper test cases is very vital for your software testing plans as a lot of bugs, ambiguities, inconsistencies and slip ups can be recovered in time as also it helps in saving your time on continuous debugging and re-testing test cases.

What is a test case?

A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.
- A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not
- A Test case is a sequence of steps to be executed to test the expected results for a part of an application.
- Test cases are Set of Input and Action that makes sure S/w or product is as per specification and user required.
- Test cases is a sequence of steps to test the correct behavior of a functionality/feature of an application
Test Case is like a check list to make sure that all the requirements are covered in the/this testing.
- It is the well define Scenario to perform a task to validate the Inputs and outputs.
Test case is a document that describes an event, action & expected output in a correct program & it will check whether feature of the application is working correctly or not.
- Test Case provides process or way to test.
A test case should have an input description, Test Sequence and an Expected Behavior.

Formal test cases:

In order to fully test that all the requirements of an application are met, there must be at least two test cases for each requirement: one positive test and one negative test; unless a requirement has sub-requirements. In that situation, each sub-requirement must have at least two test cases. Keeping track of the link between the requirement and the test is frequently done using a traceability matrix. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted. A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a post-condition.

Informal test cases:

For applications or systems without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run. In scenario testing, hypothetical stories are used to help the tester think through a complex problem or system. These scenarios are usually not written down in any detail. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate. They are usually different from test cases in that test cases are single steps while scenarios cover a number of steps.

There are levels in which each test case will fall in order to avoid duplication efforts:

Level 1:
In this level you will write the basic test cases from the available specification and user documentation.
Level 2:
This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3:
This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10.
Level 4:
Automation of the project. This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

Test Case Structure

A formal written test case comprises of three parts -

  1. Information/Introduction : Information consists of general information about the test case. Information incorporates Identifier, test case creator, test case version, name of the test case, purpose or brief description and test case dependencies.
  2. Activity : Activity consists of the actual test case activities. Activity contains information about the test case environment, activities to be done at test case initialization, activities to be done after test case is performed, step by step actions to be done while testing and the input data that is to be supplied for testing, Pre-conditions and Post-conditions.
  3. Results: Results are outcomes of a performed test case. Results data consist of information about expected results, actual results and Pass/Fail.

Test Case Format :

Prashant Vadher

Fields in test cases:

Test case id: Test Case Identifier

Test Category (Smoke/Core/New): Choose a Category of this Test Case. Is this used to Perform a SMOKE test?

Pre-Conditions: Input Conditions to be prevalent, before the test is executed.

Unit to test: What to be verified?

Test Description: Give a brief Description of the Test Case

Steps to be executed/Test Steps: Write detailed Steps to be executed

Test data: Variables and their values. Input Test Data, that will be used in this Test Case
Expected result: What is the Expected Result for this Test Case ?

Actual Results: This column will be populated during test execution to mark whether the Actual Results matched the Expected Results

Pass/Fail: Choose an appropriate Result for this test

Test Execution (Manual / Automated): Select the mode of execution, Will this test be executed manually or by Automated Suite ?

Bug ID: Specify defect numbers from iMatrix if this Test case has failed

Comments: Write some additional comments here..

Try writing the simple test cases as mentioned in above test case format. Generally I use Excel sheets to write the basic test cases.

prashant, vadher, prashant vadher, ahmedabad, qa engineer, software tester, digicorp, software testing, software testing jobs, mobile testing, prashant, vadher, prashant vadher, ahmedabad, qa engineer, software tester, digicorp, software testing, software testing jobs, mobile testing

Thanks & Regards ,

Prashant Vadher | QA Engineer


Post a Comment

Design by Prashant Vadher