Author: Neftaly Malatjie

• • Identify Features to Test
  • Using the Functional Specification, Preliminary and Detailed Design Specification (Unit Procedural Description) identify:
  •  All Functions performed by the Unit
  •  All Inputs to the Unit
  •  All Outputs from the Unit
  • Define all ranges and discrete values of the test data necessary to run the tests
  • Prepare the Unit Test Plan following the Unit Test Plan guidelines

  Note:   See the Appendix entitled Templates for the template to be used and a description of the cover page contents.

  •  Design a set of Test Cases
  •  Use the checklists for the five types of coverage and outlined functions, inputs and outputs to create the minimum set of test cases for testing the functionality of the unit
  •  For each test case identified in the first point:
  • State the condition that will be tested by the test case (this should be used as the title of the test case)
  • List the steps/actions to be performed in order to accomplish the test
  • For each action performed identify the expected result
  • Create test data necessary to create the condition being tested and for each piece of data, indicate the expected results
  • For example, a test case for an invalid id on a data entry screen could be named “Invalid id”. The title states the condition of the test.  The procedure for testing this condition should indicate in which data entry field the cursor should be positioned and what key should be pressed to trigger the edit.  A table containing the various data elements to be entered can be attached and referenced by one of the steps in the procedure.  This data table could also contain the expected results for each data item to be entered.
  • Note:  Skeletons for the test plan and test case are available as templates in Word for Windows.

  
  

• Unit tests are created and executed by the developer of the unit.  The procedure for unit testing is as follows:

  • Create a unit test plan following the Unit Test Plan guidelines
  • Conduct the unit test as specified in the test cases
  • Identify and fix or report any problems encountered
  • Re-run the necessary tests
  • Sign the Test Plan Cover Page (Tested By and Date)
  • Package the Test Documentation and pass it to the development team leader
  • The development team leader is to verify that the documentation is complete, sign the Test Plan Cover Page (Reviewed By and Date) and submit the package to Quality Assurance for review and Configuration Management for promotion
  • Promote script or command files used to run the tests along with the unit

  
  

The goal of unit testing is to assure that all functions and features of a single compilable unit of code perform as specified in the Design Specification.

A unit test covers the testing of a software unit, or a group of closely related units, as a single entity.  Unit testing is performed in isolation, using test drivers to simulate higher level units, and/or stubs to simulate lower level units.  Unit Testing Procedures consist of:

• Creating a Unit Test Plan
• Creating test data
• Conducting tests according to the Unit Test Plan
• Reporting and reviewing the results of the test

These procedures are performed by the team member responsible for programming and testing of the unit.

A Unit Test Plan is a set of test cases arranged in the sequence of chronological execution.  The Unit Test Plan is created before the programming of the unit is started, and the test cases should cover the functional, input, output, and function interaction of the unit.

Documents Required

The following documents provide information required to create the Unit Test Plan and are recommended reading before creating the Unit Test Plan.

          Design Report

          Requirements Reports

          Change Requests

Unit Test Design Guidelines

The guidelines to be followed during the creation of Unit Test Plans are:

• A test case must exist for every branch in the code
• Design test cases and test data which reveal errors in software
  Design test data that will ensure all conditions and quality of data edits are covered
• Create test cases for special formulae and extreme conditions (e.g., Test case “File is Empty” shall be used for all files.)
• Test the interaction between units within the task
• To minimize the number of test cases, combine test cases into one if they test the same feature. (i.e., can cover a group of units or a full task)
  Use test cases which already exist wherever possible.  Include the generic test plan
  Arrange test cases in the order that minimizes the effort required for test setup and that keeps related functions together
• Where possible, arrange the test cases in the chronological order in which they will be performed

On completion of this section you will be able to apply the test procedure to networked IT systems. 

1. The application ensures correct preparation of the test procedure. 
2. The application tests the networked IT systems involved by using the selected test procedure. 
3. The application ensures that all performance parameters and operational requirements are tested. 
4. The application identifies any problems with the test procedure and takes appropriate action. 
5. The application complies with all relevant regulatory, licensing, contractual and health and safety requirements. 

1. The format and content of a software test plan vary depending on the processes, standards, and test management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for software test documentation, provides a summary of what a test plan can/should contain.

   Test Plan Identifier:

   • Provide a unique identifier for the document. (Adhere to the Configuration Management System if you have one.)

   Introduction:

   • Provide an overview of the test plan.
   • Specify the goals/objectives.
   • Specify any constraints.

   References:

   • List the related documents, with links to them if available, including the following:
     • Project Plan
     • Configuration Management Plan

    Test Items:

   • List the test items (software/products) and their versions.

   Features to be tested:

   • List the features of the software/product to be tested.
   • Provide references to the Requirements and/or Design specifications of the features to be tested

   Features Not to Be Tested:

   • List the features of the software/product which will not be tested.
   • Specify the reasons these features won’t be tested.

   Approach:

   • Mention the overall approach to testing.
   • Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]

   Item Pass/Fail Criteria:

   • Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

   Suspension Criteria and Resumption Requirements:

   • Specify criteria to be used to suspend the testing activity.
   • Specify testing activities which must be redone when testing is resumed.

   Test Deliverables:

   • List test deliverables, and links to them if available, including the following:
     • Test Plan (this document itself)
     • Test Cases
     • Test Scripts
     • Defect/Enhancement Logs
     • Test Reports

    Test Environment:

   • Specify the properties of test environment: hardware, software, network etc.
   • List any testing or related tools.

   Estimate:

   • Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

   Schedule:

   • Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

   Staffing and Training Needs:

   • Specify staffing needs by role and required skills.
   • Identify training that is necessary to provide those skills, if not already acquired.

   Responsibilities:

   • List the responsibilities of each team/role/individual.

   Risks:

   • List the risks that have been identified.
   • Specify the mitigation plan and the contingency plan for each risk.

    

   Assumptions and Dependencies:

   • List the assumptions that have been made during the preparation of this plan.
   • List the dependencies.

   Approvals:

   • Specify the names and roles of all persons who must approve the plan.
   • Provide space for signatures and dates. (If the document is to be printed.)

   TEST PLAN GUIDELINES ·         Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan. ·         Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition/Version as well, not just the OS Name. ·         Make use of lists and tables wherever possible. Avoid lengthy paragraphs. ·         Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform. ·         Update the plan as and when necessary. An out-dated and unused document stinks and is worse than not having the document in the first place.