Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

IEEE 829-1998 by Mind Map: IEEE 829-1998
0.0 stars - 0 reviews range from 0 to 5

IEEE 829-1998

IEEE 829-2008, also known as the 829 Standard for Software and System Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in eight defined stages of software testing and system testing, each stage potentially producing its own separate type of document. The standard specifies the format of these documents, but does not stipulate whether they must all be produced, nor does it include any criteria regarding adequate content for these documents. These are a matter of judgment outside the purview of the standard. The documents are: Master Test Plan: The purpose of the Master Test Plan is to provide an overall test planning and test management document for multiple levels of test. Level Test Plan: For each LTP the scope, approach, resources, and schedule of the testing activities for its specified level of testing need to be described. The items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the associated risk need to be identified. Level Test Design: Detailing test cases and the expected results as well as test pass criteria.

Test Plan

A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of the eventual workflow.

Test Plan Identifier

Introduction

Test Items

Features to be Tested

Features not to be Tested

Test Approach

Item Pass/Fail Criteria

Suspension Criteria & Resumption Requirements

Test Deliverables

Testing Tasks

Environmental Needs

Responsabilities

Staffing & Trainning Needs

Schedule

Risks & Contingencies

Approvals

Test Summary Report

Test summary report is the report which is prepared after testing is complete.

Summary

Variances

Comprehensiveness Assessment

Summary of Results

Evaluation

Summary of Activities

Test Case Specification

The Classification Tree Method is a method for test design, as it is used in different areas of software development. It has been developed by Grimm and Grochtmann in 1993. Classification Trees in terms of the Classification Tree Method must not be confused with decision trees. The classification tree method consists of two major steps: Identification of test relevant aspects and their corresponding values as well as Combination of different classes from all classifications into test cases. The identification of test relevant aspects usually follows the specification of the system under test. These aspects form the input and output data space of the test object. The second step of test design then follows the principles of combinatorial test design. While the method can be applied using a pen and a paper, the usual way involves the usage of the Classification Tree Editor, a software tool implementing the classification tree method.

Objectives

Preconditions

Input Specification

Output Specification

Postconditions

Inter-case Dependencies

Test Procedure / Script specification

- Test Procedure - Manual- Test Script - Automated

Purpose

Special Requirements

Procedure / Script Steps

Test Design specification

Specification may refer to an explicit set of requirements to be satisfied by a material, design, product, or service. Should a material, product, or service fail to meet one or more of the applicable specifications, it may be referred to as being out of specification; the abbreviation OOS may also be used. In casual usage, underspec or overspec are used when something is worse or better than specified, though in general there is only a notion of "in spec" or "out of spec", not "better" or "worse". A specification is a type of technical standard. A technical specification may be developed by any of various kinds of organizations, both public and private. Example organization types include a corporation, a consortium, a trade association, a national government, a professional association, a purpose-made standards organization such as ISO, or vendor-neutral developed generic requirements. It is common for one organization to refer to the standards of another. Voluntary standards may become mandatory if adopted by a government or business contract.

Test Conditions (coverage Items)

Detailed Approach

High Level Test Cases

Test Incident Report

Test Incident Report is another name for bug report. Is how incidents are reported with as much information as possible to help developers solve the issue.Involves incident description and the impact of the issue.

Report ID

Summary

Description

Impact