Appendix ATest Case Specification Template2001 - Software Quality Engineering - Version 7.0 A - 17 Test Case Specification Template (IEEE 829-1998) Test Case Specification Identifier • Some type of unique company generated number to identify this test case specification, its level and the level of software that it is related to. Preferably the case specification level will be the same as the related software level. Ideally the case naming convention should follow the same general rules as the software it is related to. This is to assist in coordinating software and testware versions within configuration management. • Unique "short" name for the case • Version date and version number of the case • Version Author and contact information • Revision history Test Items • Identify the items or features to be tested by this test case. Keep in mind the level for which this test case is written and describe the items/features accordingly. The item description and definition can be referenced from any one of several sources, depending on the level of the test case specification. It may be a good idea to reference the source document as well. • Requirements specification • System Design specification • Detail Design specification • Users Guide • Operations manual • Installation guide Input Specifications • Identify all inputs required to execute the test case. Again these may vary based on the level the case is written for. Be sure to identify all required inputs not just data elements and values. • Data • Values • Ranges • Sets • Tables • Human actions • Conditions • States2001 - Software Quality Engineering - Version 7.0 A - 18 • Initial • Intermediate • Final • Files • Databases • Control files • Transaction files • Relationships • Timing • It is also acceptable to simplify the documentation process by using tables for elements and values. It is even conceivable to create a test case that can be used a multiple levels of testing (Unit, Integration, etc.). Notes can be used to document common rules and processes for elements that have shared characteristics. Case Numbers Test Element Valid Values Valid Response Invalid Response R1 R 2 R 3 ATT Proc Dep Where R1 is the valid value rule (i.e. Run one test for each value at the beginning and end of the valid set , you should get the valid response) (this uses the equivalence partitioning/boundary value technique) R2 is the invalid rule (i.e. Run one test for each value just before the beginning and just after the end of the valid set , you should get the invalid response) (this uses the equivalence partitioning/boundary value technique) R3 is the navigation rule between tests ATT is any field specific attributes, (bold, reverse image etc. Proc is the procedure to follow for the case. It may be internally documented or a separate document Dep are any element or case dependencies Output Specifications • Identify all outputs required to verify the test case. Again these may vary based on the level the case is written for. Be sure to identify all required outputs not just data elements and values. • Data • Values • Sets • Tables • Human actions2001 - Software Quality Engineering - Version 7.0 A - 19 • Conditions • States • Initial • Intermediate • Final • Files • Databases • Control files • Transaction files • Relationships • Timing • Response times • Duration • Outputs can also be simplified using tables as noted above and may even be included in the same table as the associated input to further simplify the documentation and improve its usefulness. Environmental needs • Hardware • Configurations • Limitations • Software • System • Operating systems • Compilers • Tools • Other Application • Mix of applications • Other • Facilities • Training Special Procedural Requirements Identify any special constraints on the test case(s). If the test case specification covers more than one test case this may be the common procedure for several sets of tests or there may be more than one set of steps or external procedures identified. Focus on key elements such as: • Special Setup • Operations intervention • Output location and identification • Special wrap-up2001 - Software Quality Engineering - Version 7.0 A - 20 Inter-case Dependencies • Identify any prerequisite test cases. It is also recommended that the relationship of test cases be documented at both ends of the relationship. The precursor should identify any follow-on test cases and the post cases identify all