Misplaced Pages

Test plan: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 17:20, 7 April 2018 editWalter Görlitz (talk | contribs)Extended confirmed users, Pending changes reviewers294,571 edits Reverted 1 edit by 2405:205:C942:50AB:7937:7E2:3DF0:B190 (talk) to last revision by Walter Görlitz. (TW)Tag: Undo← Previous edit Latest revision as of 14:19, 26 May 2024 edit undoBlueBirdBlues (talk | contribs)Extended confirmed users653 editsm Adding short description: "Type of document"Tag: Shortdesc helper 
(31 intermediate revisions by 21 users not shown)
Line 1: Line 1:
{{Short description|Type of document}}
A '''test plan''' is a document detailing the objectives, resources, and processes for a specific test for a ] or hardware product. The plan typically contains a detailed understanding of the eventual ]. A '''test plan''' is a document detailing the objectives, resources, and processes for a specific test session for a ] or hardware product. The plan typically contains a detailed understanding of the eventual ].


==Test plans== ==Test plans==
⚫ A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from ]s.<ref>{{Cite book |last1=Dale |first1=Nell |url=https://books.google.com/books?id=0GN7EAAAQBAJ&dq=Test+plan+programming&pg=PA253 |title=Programming and Problem Solving with C++ |last2=Weems |first2=Chip |last3=Richards |first3=Tim |date=2022-07-15 |publisher=Jones & Bartlett Learning |isbn=978-1-284-15732-1 |language=en}}</ref>
{{unreferenced section|date=August 2010}}
⚫ A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from ]s.


Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include a strategy for one or more of the following: Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include a strategy for one or more of the following:
* ''Design Verification or Compliance test'' - to be performed during the development or approval stages of the product, typically on a small sample of units. * Design verification or compliance test – to be performed during the development or approval stages of the product, typically on a small sample of units.
* ''Manufacturing or Production test'' - to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. * Manufacturing test or production test – to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control.
* ''Acceptance or Commissioning test'' - to be performed at the time of delivery or installation of the product. * Acceptance test or commissioning test – to be performed at the time of delivery or installation of the product.
* ''Service and Repair test'' - to be performed as required over the service life of the product. * Service and repair test – to be performed as required over the service life of the product.
* ''Regression test'' - to be performed on an existing operational product, to verify that existing functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading the platform on which an existing application runs). * Regression test – to be performed on an existing operational product, to verify that existing functionality was not negatively affected when other aspects of the environment were changed (e.g., upgrading the platform on which an existing application runs).
A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components. A complex system may have a high-level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components.


Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: Test Coverage, Test Methods, and Test Responsibilities. These are also used in a formal ]. Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: test coverage, test methods, and test responsibilities. These are also used in a formal ].<ref>{{Cite book |last1=Laganà |first1=Antonio |url=https://books.google.com/books?id=6gUhDn3z2WoC&dq=test+coverage,+test+methods,+and+test+responsibilities&pg=PA1075 |title=Computational Science and Its Applications -- ICCSA 2004: International Conference, Assisi, Italy, May 14-17, 2004, Proceedings |last2=Gavrilova |first2=Marina L.|author2-link=Marina Gavrilova |last3=Kumar |first3=Vipin |last4=Mun |first4=Youngsong |last5=Gervasi |first5=Osvaldo |last6=Tan |first6=C. J. Kenneth |date=2004-05-07 |publisher=Springer Science & Business Media |isbn=978-3-540-22054-1 |language=en}}</ref>


===Test coverage=== ===Test coverage===


Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access. Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during ], but not repeated during acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access.


===Test methods=== ===Test methods===
Line 24: Line 24:


===Test responsibilities=== ===Test responsibilities===
Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also includes, what data will be collected, and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties. Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also include what data will be collected and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties.


==IEEE 829 test plan structure== ==IEEE 829 test plan structure==
Line 50: Line 50:
** 829-1998 ''IEEE Standard for Software Test Documentation'' (superseded by 829-2008)<ref>{{Cite book | title = 829-1998 — IEEE Standard for Software Test Documentation | doi = 10.1109/IEEESTD.1998.88820 | year = 1998 | isbn = 0-7381-1443-X }}</ref> ** 829-1998 ''IEEE Standard for Software Test Documentation'' (superseded by 829-2008)<ref>{{Cite book | title = 829-1998 — IEEE Standard for Software Test Documentation | doi = 10.1109/IEEESTD.1998.88820 | year = 1998 | isbn = 0-7381-1443-X }}</ref>
** 829-1983 ''IEEE Standard for Software Test Documentation'' (superseded by 829-1998)<ref>{{Cite book | title = 829-1983 — IEEE Standard for Software Test Documentation | doi = 10.1109/IEEESTD.1983.81615 | year = 1983 | isbn = 0-7381-1444-8 }}</ref> ** 829-1983 ''IEEE Standard for Software Test Documentation'' (superseded by 829-1998)<ref>{{Cite book | title = 829-1983 — IEEE Standard for Software Test Documentation | doi = 10.1109/IEEESTD.1983.81615 | year = 1983 | isbn = 0-7381-1444-8 }}</ref>
* 1008-1987 ''IEEE Standard for Software Unit Testing''<ref>{{Cite book | title = 1008-1987 - IEEE Standard for Software Unit Testing | doi = 10.1109/IEEESTD.1986.81001 | year = 1986 | isbn = 0-7381-0400-0 | pmid = | pmc = }}</ref> * 1008-1987 ''IEEE Standard for Software Unit Testing''<ref>{{Cite book | title = 1008-1987 - IEEE Standard for Software Unit Testing | doi = 10.1109/IEEESTD.1986.81001 | year = 1986 | isbn = 0-7381-0400-0 }}</ref>
* 1012-2004 ''IEEE Standard for Software Verification and Validation''<ref>{{Cite book | title = 1012-2004 - IEEE Standard for Software Verification and Validation | doi = 10.1109/IEEESTD.2005.96278 | year = 2005 | isbn = 978-0-7381-4642-3 | pmid = | pmc = }}</ref> * 1012-2004 ''IEEE Standard for Software Verification and Validation''<ref>{{Cite book | title = 1012-2004 - IEEE Standard for Software Verification and Validation | doi = 10.1109/IEEESTD.2005.96278 | year = 2005 | isbn = 978-0-7381-4642-3 }}</ref>
** 1012-1998 ''IEEE Standard for Software Verification and Validation'' (superseded by 1012-2004)<ref>{{Cite book | title = 1012-1998 - IEEE Standard for Software Verification and Validation | doi = 10.1109/IEEESTD.1998.87820 | year = 1998 | isbn = 0-7381-0196-6 | pmid = | pmc = }}</ref> ** 1012-1998 ''IEEE Standard for Software Verification and Validation'' (superseded by 1012-2004)<ref>{{Cite book | title = 1012-1998 - IEEE Standard for Software Verification and Validation | doi = 10.1109/IEEESTD.1998.87820 | year = 1998 | isbn = 0-7381-0196-6 }}</ref>
** 1012-1986 ''IEEE Standard for Software Verification and Validation Plans'' (superseded by 1012-1998)<ref>{{Cite book | title = 1012-1986 - IEEE Standard for Software Verification and Validation Plans | doi = 10.1109/IEEESTD.1986.79647 | year = 1986 | isbn = 0-7381-0401-9 | pmid = | pmc = }}</ref> ** 1012-1986 ''IEEE Standard for Software Verification and Validation Plans'' (superseded by 1012-1998)<ref>{{Cite book | title = 1012-1986 - IEEE Standard for Software Verification and Validation Plans | doi = 10.1109/IEEESTD.1986.79647 | year = 1986 | isbn = 0-7381-0401-9 }}</ref>
* 1059-1993 ''IEEE Guide for Software Verification & Validation Plans'' (withdrawn)<ref>{{Cite book | title = 1059-1993 - IEEE Guide for Software Verification and Validation Plans | doi = 10.1109/IEEESTD.1994.121430 | year = 1994 | isbn = 0-7381-2379-X | pmid = | pmc = }}</ref> * 1059-1993 ''IEEE Guide for Software Verification & Validation Plans'' (withdrawn)<ref>{{Cite book | title = 1059-1993 - IEEE Guide for Software Verification and Validation Plans | doi = 10.1109/IEEESTD.1994.121430 | year = 1994 | isbn = 0-7381-2379-X }}</ref>


==See also== ==See also==

{{portal|Software Testing}}
* ] * ]
* ] * ]
Line 73: Line 73:
* Public domain ] test plan template at (templates are currently inaccessible but sample documents can be seen here: ) * Public domain ] test plan template at (templates are currently inaccessible but sample documents can be seen here: )


] ]

Latest revision as of 14:19, 26 May 2024

Type of document

A test plan is a document detailing the objectives, resources, and processes for a specific test session for a software or hardware product. The plan typically contains a detailed understanding of the eventual workflow.

Test plans

A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from test engineers.

Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include a strategy for one or more of the following:

  • Design verification or compliance test – to be performed during the development or approval stages of the product, typically on a small sample of units.
  • Manufacturing test or production test – to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control.
  • Acceptance test or commissioning test – to be performed at the time of delivery or installation of the product.
  • Service and repair test – to be performed as required over the service life of the product.
  • Regression test – to be performed on an existing operational product, to verify that existing functionality was not negatively affected when other aspects of the environment were changed (e.g., upgrading the platform on which an existing application runs).

A complex system may have a high-level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components.

Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: test coverage, test methods, and test responsibilities. These are also used in a formal test strategy.

Test coverage

Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during design verification test, but not repeated during acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access.

Test methods

Test methods in the test plan state how test coverage will be implemented. Test methods may be determined by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods also specify test equipment to be used in the performance of the tests and establish pass/fail criteria. Test methods used to verify hardware design requirements can range from very simple steps, such as visual inspection, to elaborate test procedures that are documented separately.

Test responsibilities

Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also include what data will be collected and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties.

IEEE 829 test plan structure

IEEE 829-2008, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in defined stages of software testing, each stage potentially producing its own separate type of document. These stages are:

  • Test plan identifier
  • Introduction
  • Test items
  • Features to be tested
  • Features not to be tested
  • Approach
  • Item pass/fail criteria
  • Suspension criteria and resumption requirements
  • Test deliverables
  • Testing tasks
  • Environmental needs
  • Responsibilities
  • Staffing and training needs
  • Schedule
  • Risks and contingencies
  • Approvals

The IEEE documents that suggest what should be contained in a test plan are:

  • 829-2008 IEEE Standard for Software and System Test Documentation
    • 829-1998 IEEE Standard for Software Test Documentation (superseded by 829-2008)
    • 829-1983 IEEE Standard for Software Test Documentation (superseded by 829-1998)
  • 1008-1987 IEEE Standard for Software Unit Testing
  • 1012-2004 IEEE Standard for Software Verification and Validation
    • 1012-1998 IEEE Standard for Software Verification and Validation (superseded by 1012-2004)
    • 1012-1986 IEEE Standard for Software Verification and Validation Plans (superseded by 1012-1998)
  • 1059-1993 IEEE Guide for Software Verification & Validation Plans (withdrawn)

See also

References

  1. Dale, Nell; Weems, Chip; Richards, Tim (2022-07-15). Programming and Problem Solving with C++. Jones & Bartlett Learning. ISBN 978-1-284-15732-1.
  2. Laganà, Antonio; Gavrilova, Marina L.; Kumar, Vipin; Mun, Youngsong; Gervasi, Osvaldo; Tan, C. J. Kenneth (2004-05-07). Computational Science and Its Applications -- ICCSA 2004: International Conference, Assisi, Italy, May 14-17, 2004, Proceedings. Springer Science & Business Media. ISBN 978-3-540-22054-1.
  3. ^ 829-2008 — IEEE Standard for Software and System Test Documentation. 2008. doi:10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5747-4.
  4. 829-1998 — IEEE Standard for Software Test Documentation. 1998. doi:10.1109/IEEESTD.1998.88820. ISBN 0-7381-1443-X.
  5. 829-1983 — IEEE Standard for Software Test Documentation. 1983. doi:10.1109/IEEESTD.1983.81615. ISBN 0-7381-1444-8.
  6. 1008-1987 - IEEE Standard for Software Unit Testing. 1986. doi:10.1109/IEEESTD.1986.81001. ISBN 0-7381-0400-0.
  7. 1012-2004 - IEEE Standard for Software Verification and Validation. 2005. doi:10.1109/IEEESTD.2005.96278. ISBN 978-0-7381-4642-3.
  8. 1012-1998 - IEEE Standard for Software Verification and Validation. 1998. doi:10.1109/IEEESTD.1998.87820. ISBN 0-7381-0196-6.
  9. 1012-1986 - IEEE Standard for Software Verification and Validation Plans. 1986. doi:10.1109/IEEESTD.1986.79647. ISBN 0-7381-0401-9.
  10. 1059-1993 - IEEE Guide for Software Verification and Validation Plans. 1994. doi:10.1109/IEEESTD.1994.121430. ISBN 0-7381-2379-X.

External links

  • Public domain RUP test plan template at Sourceforge (templates are currently inaccessible but sample documents can be seen here: DBV Samples)
Category: