Functional Test Cases
A manual or functional test case is a set of conditions or variables under which a tester determines whether a system under test satisfies requirements and works correctly.
Simply put, a test case is a pre-determined set of steps and criteria that a tester follows during test execution.
The act of writing a test case, although considered to be a planning activity, also forms an important part of the test activities since it is often the first, and/or most detailed, point at which a somewhat independent in-depth review is conducted of the requirements.
Writing out test cases and the accompanying test matrices often draws out inconsistencies or ambiguities in the proposed solution, driving questions back to the business that need to be answered in order for a quality product to be delivered.
All instructions should be completed and documented as indicated to evaluate the correct behaviour and functionality of the application or system.
While the agile methodology has largely cast aside this practice in its larger-scale form, there is inherent value in an Agile tester creating a set of instructions, variables, boundaries, etc that will properly exercise and satisfy the acceptance criteria for each story, taking into consideration how these fit together as a whole.
What should be included in the Test Case?
Often a test case will contain an opening section with the following items listed for clarity:
Test Case ID:
Unique Test Case Identification Number – used to differentiate and discuss individual tests.
Summary:
A short statement about the scenario under test.
Prerequisites:
Conditions required before the test case can be run. For example, what devices, environments, etc must be available.
Test Data:
List of variables and values to be utilised in the test case. Should also list the test data source, ie to be created (and how) or sourced (from where).
The main body of the test cases will then list out the following, in adjacent column format:
Test Steps:
Detailed steps for test case execution. The level of detail will depend upon the reusability requirements of the test, the tester’s expertise and knowledge (both planner and executor), and any future automation plans for the test.
Expected Results:
How the application should perform after executing the above testing steps.
Actual Results:
How the application actually behaved after the testing steps were executed.
Pass/Fail:
Does the test or test step pass or fail. If fail, list or link the defect information.
Comments:
Any additional helpful information such as screenshots, further comments, etc that may provide the engineers with the information they need to resolve any defects or issues found.
Hopefully, that helps you to decide on the format and content of your test cases. For any further guidance please reach out to us at [email protected]
