What is a “Test case” in software testing?

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?