� Software Unit Test
� Software Integration Test
� Software Validation Test
� Software Alpha / Beta Test
� To Do List
� Team Request Forms
� Revision History
<List the individual software units/modules, including displays and subprograms, along with a pointer to their tests and a link to the drivers or stubs used to test the unit (drivers and stubs should have enough documentation so that the students next semester can use them). Enough tests should be present to test every part of a display, every line of unit code and every branch/loop in the unit code.
Drivers and stubs are components, such as functions, procedures, classes, web pages, etc., that stand in place of some component of the tested software. A driver would control the execution of one or more of the software components. A stub would act in place of one of the software components. Drivers and stubs should only be developed enough to be able to test all of the software components.
The table has the following entries:
|
Software Manual Cross-Reference ID / |
Files Containing Tests |
Driver and Stub File Names |
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
<The table entries are:
>
|
Total Number of Test Cases |
Total Number of Test Cases Executed |
Total Number of Test Case Passes |
Total Number of Test Case Failures |
|
|
|
|
|
<Once you have completed unit testing or a portion of it, you can start integration testing. Give a description of how you will take the individual software units and integrate them together in an orderly fashion. Test cases should be developed to make sure the integrated parts work together correctly. Drivers and stubs from the unit testing may be taken and changed if necessary (including their names so we don't lose them for unit testing) to work for integration testing (drivers and stubs should have enough documentation so that the students next semester can use them).
Hopefully, the unit tests have thoroughly exercised the units and so you would want to start testing things like use case scenarios where appropriate, random control sequences, erroneous control sequences, and correct control sequences. Examples might be trying to make a withdrawal from a bank account before a user has entered their ATM card and pin number, trying a login-withdrawal-deposit-withdrawal-balancecheck-deposit-withdrawal-logout sequence, and trying a login-fastcash-logout sequence.
Regression testing of the unit test cases is also appropriate here as well to be sure that no errors have been introduced while integrating.
The table has the following entries:
|
Unit Names |
File Containing Tests |
Driver and Stub File Names |
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
|
<ALL/SOME/NONE/NA> PASS:
|
DRIVER:
STUB:
|
<The table entries are:
>
|
Total Number of Test Cases |
Total Number of Test Cases Executed |
Total Number of Test Case Passes |
Total Number of Test Case Failures |
|
|
|
|
|
<The Validation Test tests each requirement, its subrequirements, and each use case.
You may wish to have one test case file per requirement and let it contain all test cases for that requirement and its subrequirements.
Although drivers and stubs might not be used during this test, you may still require some additional software to perform the test. For example, you may want to use software to simulate a device to force the tested software into error conditions. This software should be listed and linked if written by the test team or the software package used should be listed with its version number.
The table has the following entries:
|
Requirement / Use Case ID |
File Containing Tests |
Support Resources |
|
<ALL/SOME/NONE/NA> PASS:
|
|
|
<ALL/SOME/NONE/NA> PASS:
|
|
|
<ALL/SOME/NONE/NA> PASS:
|
|
<The table entries are:
>
|
Total Number of Test Cases |
Total Number of Test Cases Executed |
Total Number of Test Case Passes |
Total Number of Test Case Failures |
|
|
|
|
|
<During the Alpha / Beta test period, the software is tested by the client. The Alpha test would be conducted on the development server. The Beta test would be conducted with the software installed on the client's system and all appropriate user manuals and documentation given to the client. SQA analysts and other appropriate team members take the software to the client's computers and install it. The analysts also assist the client in learning the software so that the client can effectively test it. If available, the trainers may assist in this effort.
The clients should be given a set of paper forms or an email template to fill out for change requests and/or problems encountered.
The analysts should forward copies of all filled out forms to the software manager and software team via a team request form. The software manager and software team should respond with Decision/Reason and Date Resolved entries in a timely fashion.
Change requests should be summarized in the table below and entries should contain the following:
|
Change |
Reason |
Date Received |
Decision/Reason |
Date Resolved |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
<Problem reports should be summarized in the table below and entries should contain the following:
|
Problem |
Function Performed |
Date Received |
Decision/Reason |
Date Resolved |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
|
|
|
<MM/DD/YYYY> |
|
<MM/DD/YYYY> |
<List of items to be completed in THIS artifact.>
|
Items |
|
|
|
|
|
|
<List of issues/questions needing to be resolved by other team members. Should be organized by receiving team member and within that by reverse chronological order.>
|
Date |
Name |
Revision |
|
|
|
|
|
|
|
|
|
|
|
|