What is V model in testing?
The V model map's the type of test to the stage of development in the project.
Figure: - V Model
1) Unit Testing:
The Starting from the bottom to the first test level is "Unit Testing". It includes checking that each feature specified in the "Component Design" has been implemented in the component.
In the theory an independent tester should do this, but in practice the developer usually does it, since they are the only people who understand how a component works. The main problem with a component is that it performs only a small section of the functionality of a system, and it relies on co-operating with other parts of the system, that may not have been built yet. To overcome this, the developers either builds, or uses the special software to trick the component into believe it is working in a fully functional system.
2) Integration Testing:
As the components are constructed & tested they are then linked together to check if they work with each other. It is a fact that 2 components that have passed all their tests, if connected to each other produce one new component full of faults. These tests can be completed by developers, or by the specialists.
The Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in "System Design". The "System Design" defines a relationship between all components.
The tests are organized to check that all the interfaces, until all the components have been built and interfaced to each other producing the entire system.
3) System Testing
Once the whole system has been built then it has to be tested against the "System Specification" to check if it delivers the features needed. It is still developer focused, although specialist developers termed as systems testers are generally employed to do it.
In the essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one of the giant components.
The System testing can include a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may involve the following types of testing for the non-functional requirements:
- Performance - Are the performance criteria met?
- Volume - Can large volumes of the information be handled?
- Stress - Can peak volumes of the information be handled?
- Documentation - Is the documentation usable for system?
- Robustness - Does the system remain stable under adverse circumstances?
4) Acceptance Testing:
The Acceptance Testing checks the system against the "Requirements". It is same to systems testing in that the entire system is checked but the main difference is the change in focus:
The Systems testing checks that the system which was specified has been delivered. The Acceptance Testing checks that the system will deliver what was requested.
The customer must always do acceptance testing and not the developer. The customer always knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. The testing is more of getting the answer for whether the software delivered as defined by the customer. It is like getting a green flag from the customer that the software is up to the expectation and ready to be used.