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

System Testing

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

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 system testing.

What is quality assurance testing?


The objective of testing is to certify that a related group of modules is built to design specifications and is ready for integration testing in an integration test environment.

Scope

Should focus on testing a group of similar modules e.g. data integration modules, GUI modules or reporting modules, to ensure that they perform to specification, interact as intended, handle exceptions as excepted, and produce the appropriate alerts to satisfy error handling.

Entrance Criteria
  • Should ensure that unit test exit criteria have been met;
  • Should ensure that test cases have been reviewed by a data integration architect;
  • Should ensure that test data has been reviewed by a data integration architect;
  • Should ensure that code to be tested has been migrated to a test environment;
  • Should ensure that a test readiness review has been completed; and
  • Should certify that testing may proceed based on a  recommendation by a data integration architect.
Test Cases
  • Should be created by the lead developer or data integration architect responsible for testing; and
  • Should be more comprehensive than integration test data. 
Test Data
  • Should be created by a production support development team;
  • Should be extracted from production data;
  • Should be a sub-set of production data;
  • Should be augmented by the data integration architect as required to test module interaction, unique and/or negative conditions;
  • Should be retained in the staging environment so that the same data can be re-used as new components are developed; and
  • Should be based entirely on pre-approved test data i.e. testing should be based on augmented production data but should not involve testing with live production data.
Test Scripts
  • Should be created by the data integration architect; and
  • Should not be retained.
Test Execution

Should be performed in a separate test environment by a data integration architect.

Defects
  • Should be resolved by the individual developer and data integration architect; and
  • Should be recorded as defects in the project defect tracking tool.
Test Results

Should be recorded by the data integration architect in the project test tool e.g. HP Quality Center, as an attachment to the test case.

Exit Criteria
  • Should ensure that test results have been reviewed by a data integration architect;
  • Should ensure that an integration test readiness review has been completed; and
  • Should certify that integration testing may proceed based on a  recommendation by a data integration architect.
Summary...

The objective of testing is to certify that a related group of modules is built to design specifications and is ready for integration testing in an integration test environment.

This site provided information management guidelines for system testing.