Comments on: Introduction of Test Case http://www.dbuggr.com/abhaybharti/introduction-test-case/ Share Knowledge & Be Rewarded Wed, 28 Jul 2010 06:02:35 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: Kunal http://www.dbuggr.com/abhaybharti/introduction-test-case/comment-page-1/#comment-1012 Kunal Thu, 24 Dec 2009 11:12:25 +0000 http://www.dbuggr.com/abhaybharti/introduction-test-case/#comment-1012 A test case is a set of conditions or variables under which a tester will determine if a requirement upon an 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. 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. If the application is created without formal requirements, then test cases are written based on the accepted normal operation of programs of a similar class. Written test cases are usually collected into Test suites. Formal, written test cases consist of three main parts with subsections: Introduction/overview 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 use case or 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 contain 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. A test case is a set of conditions or variables under which a tester will determine if a requirement upon an 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. 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.
If the application is created without formal requirements, then test cases are written based on the accepted normal operation of programs of a similar class. Written test cases are usually collected into Test suites.

Formal, written test cases consist of three main parts with subsections:
Introduction/overview 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 use
case or 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 contain 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.

]]>