The V-Model for Software Development specifies 4 kinds of testing:
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
You can find more information here (Wikipedia):
http://en.wikipedia.org/wiki/V-Model_%28software_development%29#Validation_Phases
What I’m finding is that of those only the Unit Testing is clear to me. The other kinds maybe good phases in a project, but for test design it doesn’t help much. It is hard to say which tests should go in a system test, an integration test or an acceptance test.
In Action Based Testing(tm) (ABT) we have a concept called “test modules”, that I feel can work much better. A test module is a collection of tests with similar scope, designed to be executed together. In practice the test module is a sheet like document with “actions”: lines specific test actions (and checks), each starting with an “action keyword” (or “action word”), followed by arguments.
In ABT we focus strongly on what we call the high level test design, in which we identify the test modules and groups of test modules. I have written about this in my articles on test design. This process is dependent on the context of the project and the system under test, and can therefore lead to different results in different circumstances. What it typically never leads to is “integration testing”, “system testing” or “acceptance testing”. It will rather be a mix of modules like “user interface tests”, “financial transactions”, “database integrity”, “security”, etc.
Once a list is established, the next step is make a schedule, with for each test module: (1) when to develop the module, and (2) when to execute it. The development scheduling typically depends on availability of specifications. for a mortgage calculation test module this will be early in a project, when the business rules are expect to be available, while for a UI test of a dialog one has to wait until the dialog has been specified in detail. For the execution scheduling generally the order reverses: tests that verify details of the user interaction need to pass before it makes sense to run tests that enter and verify financial transactions.
The result is that the V Model is still visible as a pattern in the sense that tests developed earlier are commonly executed later. However, the traditional interpretation of “integration testing”, “system testing” and “acceptance testing” is not commonly seen, and in particular does not appear to be a good starting point for the test development planning.
