TL;DR
In the previous post, we described the activities of the test engineers. When we talk about testing levels, that level should be related to something. Testing levels are related to software activities. We will introduce you to software testing based on the remarkable book, Introduction To Software Testing by Paul Ammann and Jeff Offutt.
The testing level is determined by software activities. Source code, design artifacts, requirements, and specifications are software activities. Do not forget that all requirements and specifications will not come from your client. Some requirements are implicit. For example, if a client wants a spreadsheet program, that you could compare its feature set with Google docs or Excel (HICCUPPS).
Testing Levels
Here are testing levels related to software activities:
- Acceptance testing – assess (provide information) software related to requirements and specification
- System testing – assess (provide information) software related to architecture
- Integration testing – assess (provide information) software related to subsystem design
- Module testing – assess (provide information) software related to detailed design
- Unit testing – assess (provide information) software related to source code
When we align on left side testing levels, and on right side software activities, we get popular V testing model:
We can see that module design activity is related to unit testing, which means that it is missing a detail design testing level.
Goals
Acceptance testing must include clients because, with acceptance testing, we assess does program satisfies client needs.
The system test assesses program architectural design. An example is when a team needs to choose in web application between a single page architecture or Model-View-Controller architecture. Here we assess would software architecture be able to satisfy client requirements. The system is testes as a whole, and the assumption is that individual modules work correctly.
In Integration testing, we assess the interfaces between modules, and the assumption is that modules individually work correctly.
The detailed design phase produces module architecture and Module testing assess module design, where the module is a collection of units. The unit is an individual procedure with inputs and outputs. The module could be a package or class. We assess module interaction with other modules, units design, and data structures used in this module.
Unit testing assess source code. Here we write tests that exercise module implementation. Unit tests are a very important regression testing artifact, where we test changes in the codebase.
Remember that hard bugs are easy to make but hard to catch.
