|
In http://en.wikipedia.org/wiki/Software_engineering - software engineering , the most common definition of a test case is a set of conditions or variables under which a tester will determine if a http://en.wikipedia.org/wiki/Requirement - requirement or http://en.wikipedia.org/wiki/Use_case - use case upon an http://en.wikipedia.org/wiki/Software_application - application
is partially or fully satisfied. It may take many test cases to
determine that a requirement is fully satisfied. In order to fully test
that all the requirements of an application are met, there must be at
least one test case for each requirement unless a requirement has sub
requirements. In that situation, each sub requirement must have at
least one test case. This is frequently done using a http://en.wikipedia.org/wiki/Traceability_matrix - Traceability matrix . Some methodologies, like http://en.wikipedia.org/wiki/RUP - RUP ,
recommend creating at least two test cases for each requirement. One of
them should perform positive testing of requirement and other should
perform negative testing. 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.
If the application is created without formal requirements, then test
cases can be written based on the accepted normal operation of programs
of a similar class. In some schools or testing, test cases are not
written at all but the activities and results are reported after the
tests have been run.
What characterizes a formal, written test case is that there is a known input and an expected output, which is worked out before the test is executed. The known input should test a http://en.wikipedia.org/wiki/Precondition - precondition and the expected output should test a http://en.wikipedia.org/wiki/Postcondition - postcondition .
Under special circumstances, there could be a need to run the test,
produce results, and then a team of experts would evaluate if the
results can be considered as a pass. This happens often on new
products' performance number determination. The first test is taken as
the base line for subsequent test / product release cycles.
Written test cases are usually collected into http://en.wikipedia.org/wiki/Test_suite - Test suites .
A variation of test cases are most commonly used in http://en.wikipedia.org/wiki/Acceptance_test - acceptance testing . Acceptance testing is done by a group of http://en.wikipedia.org/wiki/End-user - end-users
or clients of the system to ensure the developed system meets their
requirements. User acceptance testing is usually differentiated by the
inclusion of happy path or positive test cases.
Structure of test case
Formal, written test cases consist of three main parts with subsections:
- Information contains general information about Test case.
- Identifier is unique identifier of test case for further references, for example, while describing found defect.
- Test case owner/creator is name of tester or test designer, who created test or is responsible for its development
- Version of current Test case definition
- Name of test case should be human-oriented title which allows to quickly understand test case purpose and scope.
- Identifier of requirement which is covered by test case. Also here could be identifier of http://en.wikipedia.org/wiki/Use_case - use case or http://en.wikipedia.org/wiki/Functional_specification - functional specification item.
- Purpose contains short description of test purpose, what functionality it checks.
- Dependencies
- Test case activity
- Testing environment/configuration contains information about configuration of hardware or software which must be met while executing test case
- Initialization describes actions, which must be performed before test case execution is started. For example, we should open some file.
- Finalization describes actions to be done after test case is
performed. For example if test case crashes database, tester should
restore it before other test cases will be performed.
- Actions step by step to be done to complete test.
- Input data description
- Results
- Expected results contains description of what tester should see after all test steps has been completed
- Actual results contains a brief description of what the tester saw after the test steps has been completed. This is often replaced with a Pass/Fail. Quite often if a test case fails, reference to the defect involved should be listed in this column.
|