17 Attributes of a (IEEE 829) Test Plan Template

-

Test Plan :

 A Test Plan is a document describing software testing scope and activities. It is the basis for formally testing any software/product in a project. In test planning phase test leader or test manager will create test plan documents.

 There are 2 types of test plan document are :

  • MTP (Master test plan): A single high-level test plan for a project/product that unifies all other test plans.
  • STP (System Test Plan): It is also called a Phase test plan. It is nothing but the test plan for each level of testing

17 Attributes of an (IEEE 829) Test Plan Template :


Test Plan Identifier: Provide a unique identifier for the test plan document. It also includes the version number also.

References: These attributes mention the document which is referred to create the test plan documents. List the related documents, with links to them if available, including the following:
  • Project Plan
  • Configuration Management Plan
Introduction: Provide an overview of the test plan. Specify the goals/objectives. Specify any constraints.

Test Items: The items that are going to be tested within the scope of testing that is mention here

Features to be Tested: List the features of the software/product to be tested. Provide references to the Requirements or Design specifications of the features to be tested

Features Not to Be Tested: List the features of the software/product which will not be tested. Specify the reasons these features won’t be tested.

Test deliverables: The documents which are created during the testing process will be mention here.
  • Test Plan (this document itself)
  • Test Cases
  • Test Scripts
  • Defect/Enhancement Logs
  • Test Reports
Strategy/Approach: Mention the overall approach to testing.
Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [(Manual/Automated) White Box/Black Box/Gray Box]

Schedule: Provide a summary of the schedule, specifying key test milestones or provide a link to the detailed schedule.

Roles and responsibility: List the responsibilities of each team member will mention here.

Software risk issues: It is also called a Product risk issue. The risk which is going to affect the product will mention here.

Risk and contingencies: It is also called as a Project risk. The risk which is going to affect the project will mention here.

Test Environment: Specify the properties of the test environment: hardware, software, network, etc. List any testing or related tools.

Staffing and Training Needs: Specify staffing needs by role and required skills. Identify training that is necessary to provide those skills, if not already acquired.

Suspend and Resume Criteria: Specify criteria to be used to suspend the testing activity. Specify testing activities which must be redone when testing is resumed.

Item Pass fails Criteria: It is also called as Exit Criteria or completion criteria. Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

Approvals: Specify the names and roles of all persons who must approve the plan. Provide space for signatures and dates. (If the document is to be printed.)

Comments

Post a Comment

Popular posts from this blog

Implicit and Explicit requirements

-
Implicit and Explicit requirements Explicit Requirements​ :    ● The Things business analyst Wrote Down.  ● These are the requirements explicitly stated or mentioned by the customer.  ● Explicit requirements are most commonly found in documents communicated by stakeholders to the development team.   ● This is the simplest type and the easiest to test.  ● The development team might take the form of an elaborate design specification, a set of acceptance criteria.  ● Explicit requirements in the form of claims that is, communications to end-users about things the software can do.   Implicit Requirements​ :  ● The Things client Will Expect  ● These are the requirements that are not explicitly stated by the customer, but implied or derived from the requirement stated by the customer.  ● These are all the things that users are going to expect that were not captured explicitly.  ● Examples include performance...
Read more

Software Configuration Management (SCM)

-
Software configuration management (SC) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SC helps in identifying individual elements and configurations tracing changes and version selection control and baselining.   SC is also known as software control management. SC aims to control changes introduced to large complex software systems through reliable version selection and version control.   Software Configuration Management does​ ​   ● Introduction to Software Configuration management and Configuration management for software Testers.  ● Software configuration management (SC) is the discipline for systematically controlling the changes that tae place during Software evelopment.  ● Software development software consists of a collection of items (such as program documents etc..) that can easily be changed. uring software...
Read more

Identified for Configuration Management

-
The term configuration item (CI) refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents software models and plans. The configuration-management system oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification change management status accounting and audits. This system aims to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.     Configuration Management Activities ​:     1. ​Configuration Item Identification ​:  ​In this phase, the item will be identified for making changes.  Example: ​Requirement document design document source code etc    2. ​Change Control ​: ​ Controlling the release and changes of the product throw out the software life cycle here CCB team will approve or disapprove changes prioritize the change...
Read more