The Best Practices and Advantages of Designing Effective Test Cases

Overview

Test case is a “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.”  The aim is to divide the software function into small units of function that is testable with input, and producing result that is measurable.

So, basically a test case is a feature/function description that should be executed with a range of input, given certain preconditions, and the outcome measured against expected result.

There is a common misconception relating to test cases and test scripts, or even test suite. Many people use them interchangeably, and that is a mistake. In short, a test script (or test suite) is a compilation of multiple test cases.

A good design of test cases should help the testing team to find and remove many logical errors in design, in addition, a good and effective test case should be based on a relevant “Use case”.

Few comments that simplify things:

• Test cases should give confidence that a 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 the 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 the way that testers can make the “Validation” process.

General categories of a “Test” case structure: 

• Test status (Pass, Fail, in progress, Block other test, Blocked by other test/Bug/Etc.)
• Test summery (short description that describes the test and his objective).
• Prerequisites that should fulfil before the test execution.
• Test category (Performance, usability, GUI Etc.).
• Test owner – the tester that 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 a great test case?

• Test cases should be readable by other persons (Project owner, management, testers, Etc.).
• Test cases should be written with the goal to find software errors.
• In my opinion, a good test case is one that can be automated.
• Test cases should write to provide testing coverage.
• Every step should have the corresponding results.
• The test case is logical and easy for execution.
• Designed based on use case / Requirements.
• The test case should be highly detailed.
• Each test case should test a specific functionality, multiple test cases can always be combined to create a test procedure.

What information would the test manager want out of test case document/s? 

• The quality of the application, based on the current testing coverage/results.
• All the relevant data that needed for “Risk Management” process.
• How much testing is still needed to end the current testing cycle?
• The number of errors that 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 that 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?
• The deviation/correctness against the original requirements and specifications.