Home Basic SDP Test Case Web Testing FAQ Others
You are here: Home>>Basic Concept>> Software Review Process

Introduction

Testing Types

Black Box Testing

GUI Test Checklist

Stubs and Drives

Decision tables

Equivalence Class

Standards for software

Integration

you are here Software Review

Usability Testing

Load / Stress Testing

QA Glossary


We need your help! To keep the site alive, please make the donation by clicking the button below.
Thank you very much!

How to Make a Donation Using PayPal Without an Account?

Software Review Process

Software Review Process

* Product Documentation
* Requirements review
* Pre-test actives
* Document Review and release

Product Documentation

* US DoD-STD-2167A Product Documentation
* Minimal set of documents

US DoD-STD-2167A Product Documentation

* DoD: Department of Defense
* STD: Software Test Description

US DoD-STD-2167A Product Documentation

* Software Test Description
  - Describes the test case
  - Criteria for evaluating test results
* Software test Procedure
  - Describes the details step-by-step test
  - Expected results for each step

US DoD-STD-2167A Product Documentation

* Computer-system operator’s manual
  - Detailed procedures for initialing operating,monitoring and, shutting down the system
* Software User’s Manual
* Computer system Diagnostic

US DoD-STD-2167A Product Documentation

* Software Programmer’s Manual
  - Programming feature
  - Equipment to perform compilations, linkages
* Computer Resources Integrated support Manual
  - Information for planning life cycle support(hardware, software..)

US DoD-STD-2167A Product Documentation

* Firmware support Manual
  - Instructions for loading software into ROM, PROM, etc
* Version Description Document
* Software Product Specification
  -Program listings
  -Detailed Design Document

Minimal set of documents

* A definition of what the user really wants to do
* A definition of what you are going to build
* A definition of how to prove what you built equals what the user wanted

Minimal set of documents

* Project Plan(s)
* Requirements specification
* Design document
* Test Specification
  -A definition of how to prove what you built equals what the user wanted

Minimal set of documents

* User’s Manual
* Version Description Document and software code
  -A definition of what you have built

Requirements review

* Requirement analyst
* Requirement Spec
* Requirement check list

Requirement Analyst

* Detect and resolve conflicts between requirements
* Discover the bounds of system, and how it interacts with it’s environments
* Elaborate the software requirements, from the system requirements

Requirement Spec

* Functionality
  -What is the software supposed to do?
* Performance
  -What speed, availability, response time, recovery time of each software function

Requirement Spec

* External Interfaces
  - How does the software interact with people, system hardware, other hardware, and other software
* Attributes
  - Considerations for maintainability, and security

Requirement Spec

* Design constraints
* Do not include design project requirements

Requirement check list

* Are requirements feasible ?
* Are requirements likely to change during product lifetime ?
* What if (e.g.error conditions) ?
* Are requirements testable ?
* How can requirements be measured, and relative to what ?

Pre-test actives

* Product and test requirements are known
* Test cases cover all functions
* Test cases are reviewed by peer
* Test plan and procedures are approved
* Verify all documents particularly revision level  and configuration control

Pre-test actives

* Verify all test equipments are ready
* Verify successful “dry-run” of test(The software is ready)
* Verify that all software is under CM control
* Verify all test environments are set up properly

Document Review and release

* Document review checklists
* Document release

Document review checklists

* Why use checklists?
* Source info for checklists?
* How to create checklists?

Why use checklists

* Reduces variations, due to skill level, experience,etc of different reviewers
* Provides guidance to junior-level staff
* Consistency of review is very important

Source info for checklists

* U.S.military Data item descriptions(DI-IPSC-81435)
* IEEE Standard
* ISO standard
* Internal company standards/templates

Creating A Checklist

* Title page or identifier: the document shall include a title page containing,
as applicable: document number; volume number; and the handling of document
date, title…

Creating A Checklist

* Does the document has title page?
* Does the title page has document number?
* Does the title page has volume number?

Identify object of review

* Has the document been review and signed by the originator’s department manager? (Note: if not, return to originator)
* Does the document list of approval authorities conform to company requirements

Generic questions

* Each “shall” should be return into a checklist question
* In the case of “if any” or “as applicable”, these are options , so this can be addressed by two (or more) questions in sequence

Generic questions – “shall”

* Each requirement shall be assigned a project unique identifier to support testing and traceability and shall be start in such a way that an object test can be defined for it
* Is each requirement assigned a project-unique identifier?
* Is each requirement stated in clear and unambiguous terms, such as an object test can be defined for it

Generic questions- “if any”

* This paragraph shall specify the requirements, if any, regarding the environment in which the CSCI must operate
* 1. Are they any requirements regarding the environment in which the CSCI must operate
* 2. if the answer to 1 is “yes” are the requirements identified and described?
* 3. if the answer to 1 is “no” is/are there reference(s) to external documents describing the CSCI operating environment?

Document release

* Formal review meeting
* Approved by manager
* Under CM control

Question & Answer