logo for information-management-architect.com
leftimage for information-management-architect.com

Software Testing Procedures

Improve quality with David Bowman’s information management guidelines for software testing procedures

This site is designed for Information Technology professionals who need to improve quality and require guidance and direction to help teams consistently produce error free results.

It provides information management guidelines for software testing procedures

What is Software Testing?

Standard testing procedures should be specified in the project implementation plan and test plan. They should clearly establish test expectations for all team members.

Unit Testing
  • Should require a design specification review with designer;
  • Should prepare unit test plan before coding;
  • Should create test data and document expected test results;
  • Should ensure that test data validates the module's logic, adherence to functional requirements and adherence to technical standards;
  • Should ensure that test data tests all module source code and each conditional logic branch;
  • Should ensure that unit test is conducted in personal schema;
  • Should document test results;
  • Should place test data and test results in project documentation repository;
  • Should check code into code repository; and
  • Should require code readiness review with Lead Developer.
Code Review
  • Should involve code review with appropriate team members e.g. author, the developer who created the code, reader, a developer who will read the code during the code review (who may also be the author) and scribe, a developer who will take notes;
  • Should validate that code readiness review has been completed;
  • Should verify that code and unit test results conform to data integration best practices;
  • Should verify that all conditional logic paths were followed and that all error messages were tested properly;
  • Should verify that coding security vulnerability issues have been addressed;
  • Should verify that test data and test results have been placed in project documentation repository;
  • Should verify that code has been checked into code repository; and
  • Should document action items.
System Testing
  • Should require design specifications with designer;
  • Should specify system test objectives;
  • Should specify methodology that will be used;
  • Should specify conditions that impact the test;
  • Should specify how tests will progress from one test to the next;
  • Should specify expected test results;
  • Should specify test constraints;
  • Should specify system test acceptance criteria e.g. what determines a successful system test;
  • Should create test data and document expected test results;
  • Should create the system test environment;
  • Should create system test data;
  • Should document expected results;
  • Should move system test data to system test environment;
  • Should migrate code to system test environment;
  • Should back-up system test environment;
  • Should execute work streams that comprise the system test;
  • Should document system test results;
  • Should place system test data and test results in project documentation repository; and
  • Should check code into code repository.
Software Testing Procedures for Defect Management
  • Should notify developer;
  • Should fix code;
  • Should update test data and test results if needed;
  • Should place test data and test results in project documentation repository;
  • Should check code into code repository;
  • Should restore system test environment test data;
  • Should re-migrate corrected code to system test environment;
  • Should execute work streams that comprise the system test; and
  • Should confirm that system test achieves system test objectives.
Integration Testing
  • Should specify integration test objectives;
  • Should specify methodology that will be used;
  • Should specify conditions that impact the test;
  • Should specify how tests will progress from one test to the next;
  • Should specify expected test results;
  • Should specify test constraints;
  • Should specify integration test acceptance criteria e.g. what determines a successful system test;
  • Should create the integration test environment;
  • Should create system test data;
  • Should document expected results;
  • Should move integration test data to integration test environment;
  • Should migrate code to integration test environment;
  • Should back-up integration test environment;
  • Should execute work streams that comprise the integration test;
  • Should document system test results;
  • Should place integration test data and test results in project documentation repository;
  • Should check code into code repository;
  • Should perform system and volume testing;
  • Should perform reconciliation tests;
  • Should perform regression testing;
  • Should perform performance testing;
  • Should create an integration test object migration plan to identify all code included in the test, all data definition language (DDL) scripts, all data manipulation language (DML) scripts, any other scripts such as Unix shell scripts, all system test results, all integration test data; and all project documentation impacted by the code;
  • Should validate that all objects in the object migration plan comprise a planned production release i.e. a set of components intended to move to production as a planned release;
  • Should migrate all integration test objects to integration test environment;
  • Should back-up integration test environment;
  • Should execute work streams that comprise the integration test;
  • Should document integration test results;
  • Should place integration test data and test results in project documentation repository.
Defect Management
  • Should document defects in the defect tracking tool;
  • Should document assign defect severity;
  • Should document assign defect to appropriate developer for correcting;
  • Should fix code;
  • Should update unit test data and test results if needed;
  • Should re-run system test if appropriate;
  • Should place unit and system test data and test results in project documentation repository;
  • Should check code into code repository;
  • Should restore integration test environment test data;
  • Create new version of object migration plan to identify changed objects;
  • Should document migrate modified objects to integration test environment;
  • Should document execute work streams that comprise the integration test;
  • Should document confirm that integration test achieves test objectives; and
  • Should document and close appropriate defects.
Software Testing Procedures for Security Testing

  • Should be performed in the production environment under the direction of the security officer;
  • Should certify compliance with system security and integrity; and
  • Should test system back-up, recovery, security audit trails and tracking.
Software Testing Procedures for Quality Assurance Testing
  • Should specify test objectives;
  • Should specify methodology that will be used;
  • Should specify conditions that impact the test;
  • Should specify how tests will progress from one test to the next;
  • Should specify expected test results;
  • Should specify test constraints;
  • Should specify test acceptance criteria e.g. what determines a successful quality assurance test;
  • Should create quality assurance test data;
  • Should document expected results;
  • Should create the quality assurance test environment;
  • Should move integration test data to integration test environment;
  • Should back-up quality assurance test environment;
  • Should prepare a quality assurance test plan to identify script execution schedule and roles and responsibilities;
  • Should review test plan with production support team, or release team, that may be required to migrate code and/or execute scripts in the quality assurance test environment;
  • Should migrate all quality assurance test objects to quality assurance test environment;
  • Should execute work streams that comprise the quality assurance test;
  • Should document quality assurance test results; and
  • Should place quality assurance test data and test results in project documentation repository.
Object Migration
  • Should specify all code included in the test;
  • Should specify all data definition language (DDL) scripts;
  • Should specify all data manipulation language (DML) scripts;
  • Should specify any other scripts such as Unix shell scripts;
  • Should specify all system test results;
  • Should specify all test data;
  • Should specify all project documentation impacted by the code; and
  • Should validate that all objects in the object migration plan comprise a planned production release i.e. a set of components intended to move to production as a planned release.
Defect Management
  • Should document defects in the defect tracking tool;
  • Should assign defect severity;
  • Should assign defect to appropriate team for resolution;
  • Should resolve defect;
  • Should update unit test data and test results if needed;
  • Should re-run system and/or integration test if appropriate;
  • Should place updated unit, system and integration test data and test results in project documentation repository;
  • Should check code into code repository;
  • Should restore quality assurance test environment test data;
  • Should create new version of object migration plan to identify changed objects;
  • Should migrate modified objects to quality assurance test environment;
  • Should execute work streams that comprise the quality assurance test;
  • Should confirm that quality assurance test achieves system test objectives; and
  • Should close appropriate defects.
User Acceptance Testing

  • Should focus on testing a set of requirements to ensure that they meet user expectations;
  • Should be performed in the quality assurance test environment or in a separate user acceptance test environment; and
  • Should follow similar software testing procedures as the integration test.
Summary...

Standard software testing procedures should be specified in the project implementation plan and test plan. They should clearly establish test expectations for all team members.

This site provided information management guidelines for software testing procedures.