Scribd Logo
Upload

Welcome to Scribd!

  • 176 views

    Qe Test Case Specification Template

    Uploaded by

    Akshat Sinha
    This document provides a template for test case specifications according to the IEEE 829-1998 standard. The template includes sections for test case identification details, test items or features to be tested, input specifications, output specifications, environmental needs, special procedural requirements, and inter-case dependencies. The sections provide guidance on the type of information to include for each level of testing, such as unique identifiers, requirements, inputs, outputs, hardware/software configurations, and prerequisites. Tables can also be used to simplify documentation of test cases and their associated elements and values.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Qe Test Case Specification Template

    Uploaded by

    Akshat Sinha
    176 views4 pages
    This document provides a template for test case specifications according to the IEEE 829-1998 standard. The template includes sections for test case identification details, test items or features to be tested, input specifications, output specifications, environmental needs, special procedural requirements, and inter-case dependencies. The sections provide guidance on the type of information to include for each level of testing, such as unique identifiers, requirements, inputs, outputs, hardware/software configurations, and prerequisites. Tables can also be used to simplify documentation of test cases and their associated elements and values.

    Original Description:

    test case

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document provides a template for test case specifications according to the IEEE 829-1998 standard. The template includes sections for test case identification details, test items or features to be tested, input specifications, output specifications, environmental needs, special procedural requirements, and inter-case dependencies. The sections provide guidance on the type of information to include for each level of testing, such as unique identifiers, requirements, inputs, outputs, hardware/software configurations, and prerequisites. Tables can also be used to simplify documentation of test cases and their associated elements and values.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    176 views4 pages

    Qe Test Case Specification Template

    Uploaded by

    Akshat Sinha
    This document provides a template for test case specifications according to the IEEE 829-1998 standard. The template includes sections for test case identification details, test items or features to be tested, input specifications, output specifications, environmental needs, special procedural requirements, and inter-case dependencies. The sections provide guidance on the type of information to include for each level of testing, such as unique identifiers, requirements, inputs, outputs, hardware/software configurations, and prerequisites. Tables can also be used to simplify documentation of test cases and their associated elements and values.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 4

    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 - 17

    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

    R
    1

    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 - 18

    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 - 19

    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 prerequisites.

    2001 - Software Quality Engineering - Version 7.0


    A - 20

    You might also like