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

Unit Testing

Improve quality with David Bowman’s information management guidelines for unit 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 software unit testing.

What is module testing?

The objective of modeul testing is to certify that each individual module is built to design specifications in the developer’s personal schema and is ready for system testing in a system test environment

Information management projects generally have the following development work:
  • Data integration software;
  • Data conversion software;
  • Data cleansing routines;
  • Data base development DDL; and
  • Business intelligence and reporting analytical solutions.
Module testing validates that each module's logic meets design specification. It  is generally conducted by the developer who develops the code.

Scope

Should focus on testing individual modules to ensure that they perform to specification, handle all exceptions as expected, and produce the appropriate alerts to satisfy error handling.

Entrance Criteria
  • Should ensure that code has been reviewed by a lead developer or by a data integration architect;
  • Should ensure that unit test cases have been reviewed by a lead developer or by a data integration architect;
  • Should certify that testing may proceed based on a  recommendation by a data integration architect.
Test Cases
  • Should be created by the individual developer responsible for the module;
  • Should be documented in the project test tool, or in some project documentation folder; and
  • Should be reviewed and approved by a lead developer or data integration architect prior to commencing unit testing.
Test Data
  • Should be created by the individual developer responsible for the module; and
  • Should be more comprehensive than system and integration test data. 
Test Scripts

Should be created by the individual developer

Test Execution

Should be performed in personal schema's by the individual developer responsible for module development.

Defects
  • Should be resolved by the individual developer and Lead Developer; and
  • Should not be recorded as defects in the project defect tracking tool.
Test Results

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

Exit Criteria
  • Should ensure that test results have been reviewed by a lead developer or by a data integration architect;
  • Should ensure that a module readiness review has been completed; and
  • Should certify that system testing may proceed based on a  recommendation by a data integration architect.
Best Practices
  • Should focus on testing individual modules to ensure that they perform to specification, handle all exceptions as expected, and produce the appropriate alerts to satisfy error handling;
  • Should be performed in the development environment;
  • Should be conducted by the software developer who develops the code;
  • Should validate the module's logic, adherence to functional requirements and adherence to technical standards;
  • Should ensure that all module source code has been executed and each conditional logic branch followed;
  • Should ensure that test data and test results are recorded and form part of the release package when the code moves to production;
  • Should include a code review to  provide additional verification that code conforms to data integration best practices and security requirement; and verifies  that test results confirm that all conditional logic paths were followed and that all error messages were tested properly.
Testing Process
  • Should include a design specification review with a data integration architect;
  • 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 be conducted in a developers personal schema; and
  • Should store test cases and test results in project documentation repository.
Code Review
  • Should commence after code is checked into a code repository
  • Should be conducted by a lead developer or data integration architect;
  • Should involve the author, i.e. the developer who created the code; a reader, i.e. a developer who will read the code during the code review, who may also be the author; and a scribe, i.e. a developer who will take notes;
  • Should verify that code and 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 a code repository.
  • Should document action items; and
  • Should validate that code readiness review has been completed.
Summary...

The objective of unit testing is to certify that each individual module is built to design specifications in the developer’s personal schema and is ready for system testing in the system test environment.

This site provided information management guidelines for software unit testing.