Test plan

Last updated

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.

Contents

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. [1]

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:

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. [2]

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. [3] These stages are:

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

See also

Related Research Articles

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

<span class="mw-page-title-main">VHDL</span> Hardware description language

VHDL is a hardware description language that can model the behavior and structure of digital systems at multiple levels of abstraction, ranging from the system level down to that of logic gates, for design entry, documentation, and verification purposes. The language was developed for the US military VHSIC program in the 1980s, and has been standardized by the Institute of Electrical and Electronics Engineers (IEEE) as IEEE Std 1076; the latest version of which is IEEE Std 1076-2019. To model analog and mixed-signal systems, an IEEE-standardized HDL based on VHDL called VHDL-AMS has been developed.

In engineering, a requirement is a need that a particular item must satisfy for it to be acceptable.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

<span class="mw-page-title-main">V-model</span> Graphic of a systems development lifecycle

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

A software design description is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

A software review is "a process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".

In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems". The reviews are also performed by assessors, specialists, etc. and are suggested or mandatory as required by norms and standards.

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

Verification and validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. These are critical components of a quality management system such as ISO 9000. The words "verification" and "validation" are sometimes preceded with "independent", indicating that the verification and validation is to be performed by a disinterested third party. "Independent verification and validation" can be abbreviated as "IV&V".

Unified Power Format (UPF) is the popular name of the Institute of Electrical and Electronics Engineers (IEEE) standard for specifying power intent in power optimization of electronic design automation. The IEEE 1801-2009 release of the standard was based on a donation from the Accellera organization. The current release is IEEE 1801-2018.

IP-XACT, also known as IEEE 1685, is an XML format that defines and describes individual, re-usable electronic circuit designs to facilitate their use in creating integrated circuits. IP-XACT was created by the SPIRIT Consortium as a standard to enable automated configuration and integration through tools and evolving into an IEEE standard.

A concept of operations is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system. Examples include business requirements specification or stakeholder requirements specification (StRS). CONOPS is used to communicate the quantitative and qualitative system characteristics to all stakeholders. CONOPS are widely used in the military, governmental services and other fields.

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. 1 2 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.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.