Test Template Page

This section establishes the scope and purpose of the test plan. This is where to describe the Fundamental aspects of the testing effort.

1. Test Planning Introduction

   • Purpose - Describe why the test plan was developed--what the objectives are. This may include documenting test requirements, defining testing strategies, identifying resources, estimating schedules and project deliverables.
   • Background - Explain any events that caused the test plan to be developed. This can include implementing improved processes, or the addition of new environments or functionality.
   • Technical Architecture - diagram the components that make up the system under test. Include data storage and transfer connections and describe the purpose each component serves including how it is updated. Document the layers such as presentation/interface, database, report writer, etc. A higher level diagram showing how the system under test fits into a larger automation picture also can be included if available.
   • Specifications - list all required hardware and software including vendors and versions.
   • Scope - briefly describe the resources that the plan requires, areas of responsibility, stages and potential risks.
   • Project Information - identify all the information that is available in relation to this project. User documentation, project plan, product specifications, training materials and executive overview materials are examples of project information.
2. Requirements

   This section of the test plan lists all requirements to be tested. Any requirement not listed is outside of the scope of the test plan.

   • Business Requirements - possible questions to ask:
     • What does the business do today?
     • How does it do this?
     • Who does it?
     • When and where does it happen?
     • Why is it needed?
   • Functional Requirements - possible questions to ask:
     • What are the functions?
     • What are the qualitative descriptions for the functions?
     • What is the context and relationship?
     • Who performs the activities?
   • Technical Requirements - possible questions to ask:
     • Are there any constraints that apply?
     • Are there any quality and performance related requirements?
   • Writing Good Requirements

     1. Keep sentences short.
     2. Never express more than one requirement in a single sentence, avoid the use of 'and' in sentences.
     3. Avoid the use of jargon, abbreviations and acronyms unless you are completely confident that they will be understood by all readers of your documentation.
     4. Keep paragraphs short. No paragraph should be made up of more than 3-4 sentences.
     5. Use lists and tables wherever possible to present information sequences.
     6. Use terminology consistently. Make a glossary or dictionary to define terms.
     7. Use words such as 'shall', 'should', 'will', and 'must' in a consistent way with the following meanings:
        • shall - indicates that the requirement is mandatory
        • should - indicates a feature that is desirable but not mandatory
        • will - indicates something that will be externally provided
        • must - is best avoided. If used, it should be a synonym for 'shall'.
     8. Do not express requirements using nested conditional clauses (if 'x' then if 'y' then 'R1a' else if 'z' then 'R1b'...)
     9. Use the active rather than the passive voice, particularly when describing actions taken by people or the system.
     10. Express complex relationships in diagrams explained in natural language description. Diagrams are much more effective, but are a challenge for many to create and understand.
     11. Never use anonymous references. When possible, refer to other requirements, tables or diagrams, give a brief description of what you are referring to, as well as the reference number.
     12. Pay attention to spelling and grammar
   • SMART Requirements

     SPECIFIC	Have only one interpretation and does not leave doubt in the reader's mind
     MEASURABLE	Are quantified in a manner that can be verified
     ATTAINABLE	Can be achieved using available tools and methods at a definable cost
     RELEVANT	Are essential to the defined set of requirements being developed and will cause a deficiency if they are removed or deleted
     TRACEABLE	Are linked to one another within a specific document and to/between other project documents

   • Requirements Prioritization Scale example

     Requirements management is used to ensure that identified testing requirements are linked to test cases and tracked throughout the project.

     NECESSARY	Mission critical
     IMPORTANT	Supports necessary system operations
     DESIREABLE	Provides functional, quality, or usability enhancement