Expand
Test

Planning template Test

Planning template

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.

Expand
Requirements Requirements
Excerpt 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?

Expand
Requirements Requirements
Excerpt 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?

• Expand
  Writing Good Requirements Writing Good Requirements
  Keep sentences short. Never express more than one requirement in a single sentence, avoid the use of 'and' in sentences. Avoid the use of jargon, abbreviations and acronyms unless you are completely confident that they will be understood by all readers of your documentation. Keep paragraphs short. No paragraph should be made up of more than 3-4 sentences. Use lists and tables wherever possible to present information sequences. Use terminology consistently. Make a glossary or dictionary to define terms. 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'. Do not express requirements using nested conditional clauses (if 'x' then if 'y' then 'R1a' else if 'z' then 'R1b'...) Use the active rather than the passive voice, particularly when describing actions taken by people or the system. 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. 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. Pay attention to spelling and grammar

• Expand
  SMART Requirements 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