Unit Testing also known as components, module or program testing. It is done by developers before the setup is handed over to the testing team to formally execute the test cases. It is performed by the developers on the individual units of source code assigned areas. The developers use test data that is different from the test data of the quality assurance team. Most often stubs and drivers are used to replace the missing software and simulate the interface between the software components.
A Unit is not ready for formal unit testing until there is a formal unit test plan document that should contain:
- Identification of the unit, its programmer, the module of which it is a part, the date submitted for formal unit testing, version number, and any other information required to properly track it.
- A brief statement of its purpose and function and references to the unit’s formal requirements specification
- A brief description of how it works and references to the detailed documentation
Assumptions and pre requisites for testing. For example, program version, data base, hardware configuration, special test gear, and so on.
Test sheet for each test with the following information:
- Test number and type (path test, syntax test, state test, functional test, and so on)
- Date attempted, outcome (pass/fail), rework or corrective action with dates, reschedule date
- Database prerequisites
- Initialization method or initial conditions assumed
- Inputs
- Outcomes
- Method of verifying outcomes
- Instrumentation plan
- Context of runs
Test plan should be reviewed prior to execution. Three different reviews with three different objectives:
- By the programmer
- By the programmer’s supervisor or peers (the most important review)
- By Quality assurance (a formality if #2 is fully done or redone)
Also Check:
