top of page

What is a “Test case” in software testing?

Updated: Jan 18, 2022

A test case is a set of conditions executed by a team number (Developer, Tester, etc.) to determine whether the tested system is operated based on the software requirements and specifications. A good design of test cases should help the testing team find and remove many logical errors in design. In addition, a good and compelling test case should be based on a relevant “Use case.”

Few comments that simplify things:

  • Test cases should give confidence that specific functionality is working as designed.

  • Test cases are helpful when you need to analyze and determine the project risks.

  • The same test case should be re-tested with different inputs (Positive/Negative).

  • Test cases are a way to measure the implementation and testing coverage.

  • Test cases are always helpful when you need to provide time estimations.

  • Test cases should always contain a specific input and the expected result.

  • Test cases are always helpful when you need to provide time estimations.

  • A test case should base on the software requirements and specifications.

  • Test cases are how testers can make the “Validation” process.

General categories of a “Test” case structure

  • Test status (Pass, Fail, in progress, Block other tests, Blocked by another test/Bug)

  • Test summary (a short description that describes the test and its objective).

  • Prerequisites that should fulfill before the test execution.

  • Test category (Performance, usability, GUI ).

  • Test owner - the tester that is going to run the test.

  • Test identification number - the test case ID.

  • Dates (created, Modified, and closed).

  • Expected results AND actual results.

  • Based on Requirement ID?

  • Any automation coverage?

  • Based on Use case ID? 

  • Execution estimation.

  • Test environment.

  • Detailed steps.

  • Test Priority.

  • Test Inputs.

How to design an excellent test case

  • Test cases should be readable by other people (Project owner, management, testers).

  • Test cases should be written to find software errors.

  • In my opinion, a good test case can be automated.

  • Test cases should write to provide testing coverage.

  • Every step should have corresponding results.

  • The test case is logical and easy to execute.

  • Designed based on use case / Requirements.

  • The test case should be highly detailed.

  • Each test case should test a specific functionality; multiple cases can always be combined to create a test procedure.

The information that you can get from a detailed test case documentation

  • The deviation/correctness against the original requirements and specifications.

  • The quality of the application, based on the current testing coverage/results.

  • All the relevant data needed for the “Risk Management” process.

  • How much testing is still needed to end the current testing cycle?

  • The number of errors raised based on those test cases?

  • Is the software is ready for Beta/Alpha/Acceptance testing?

  • The Stability of the system against different architectures.

  • The current coverage against the expected timelines?

  • All the relevant data needed for “Risk analysis.”

  • How many use cases are tested and covered?

  • How many bugs are found in specific areas?

  • Is the current testing coverage is enough?

  • Is the software ready for automation?

  • The quality of the test designee?

  • The quality of the code?

19 views0 comments