Home Basic SDP Test Case Web Testing FAQ Others
You are here: Home>>Basic Concept>> Software Review Process
Sunday, 5/25/2025

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