Test case
From Wikipedia, the free encyclopedia
A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system meets specifications. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings an oracle could be a requirement or use case. It may take many test cases to determine that a software program or system is functioning correctly. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.
Contents |
[edit] Formal, requirement-based test cases
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 traceability matrix. Some methodologies, like 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.
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 precondition and the expected output should test a postcondition.
[edit] Informal requirement-based test cases
For applications or systems without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.
In scenario testing, the least formal form of testing, hypothetical stories are used to help the tester think through complex problems or systems. These scenarios are usually not written down in any detail.
[edit] Typical written test case format
A test case is a sequence of steps to test the correct behaviour/functionalities, features of an application.
Additional information that may be included:
- test case ID
- test case Description
- Expected Output
- Actual Output
- Pass/Fail
- Remarks
- test step or order of execution number
- related requirement(s)
- depth
- test category
- author
- check boxes for whether the test is automatable and has been automated.
Larger test cases may also contain prerequisite states or steps, and descriptions.
A written test case should also contain a place for the actual result.
These steps can be stored in a word processor document, spreadsheet, database or other common repository.
In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table.
Test suites often also contain
- Test summary
- Configuration
[edit] Further reading
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.
A variation of test cases are most commonly used in acceptance testing. Acceptance tests are done performed by a group of end-users or clients of the system to ensure the developed system meets the requirements specified. User acceptance tests are differentiated by the inclusion of happy path or positive test case.
Besides a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted, the most time consuming part in the test case is the test scripts. Writer, BA or QA engineer has to spend tons of time to list out the detail of input, expected output, precondition and postcondition. Knowledge transformation is also hard if there are many members involved in this test cycle. Reading test script is time consuming, communication is expensive, the misunderstanding could happen everywhere. How can we simplify the process of writing test script, modifying the test script to sync the change of the requirements and design, and improve the quality of QA? Nowadays, many companies are using screen capture or screen recorder software to generate a video as the primary part of test scripts. This will reduce the misunderstanding, shorten QA cycle and improve the productivity.
[edit] External links
- Writing Software Security Test Cases - Putting security test cases into your test plan by Robert Auger
|
||||||||||||||||||||
