We don't know of a test method that can prove the absence of bugs in any nontrivial system. Testing can only prove the presence of bugs.
But we do know two things:
That is why we start testing very early in the project and require that your team and users participate in these tests. We conduct four types of tests : reviews, unit-tests, subsystem tests, and system tests.
We conduct a few formal and several informal reviews throughout the project.
During Analysis, we conduct CRC card sessions to ensure that a common vocabulary and understanding of requirements exists between users and developers. We also validate the domain model against the requirements.
During Design, we walk through the class interfaces, their protocols, and patterns of collaboration to ensure that the design can sufficiently and completely realize the domain model.
During Coding, we conduct peer inspections of code. Every line of code is read, understood and verified by at least one other developer and the technical lead of the team. The code is hand executed for correctness and checked for consistency, clarity, reusability, and maintainability.
Unit testing is the lowest level of code testing. Individual developers are responsible for testing their classes and methods. The developer builds a set of scripts and programs that act as the driver for the class being tested. Test drivers are not part of the final version of the system. However, once written, they can be used to retest the program whenever it changes. A good collection of reusable drivers is a powerful testing tool.
The next higher level of code testing is Subsystem Testing. Large clusters of classes that should work together are hooked up and tested together. Subsystem Testing is the responsibility of the technical lead who owns that cluster of classes. Subsystem test-drivers validate the cluster for its overall behavior rather than the detailed behavior of the individual classes contained in the cluster.
System Testing is the highest level of testing. A semi-independent team tests each release of the completely integrated system against original requirements and use-cases. The test team reports problems to the development group. The individual developer is ultimately responsible for eliminating the problem.
Because every release is tested regressively and fixes are made in the order of severity, the system gradually converges into a stable system. When the system is stable enough for the user, it is transitioned to a limited set of users. The users perform real field testing, called beta testing. End of beta testing marks the end of System Testing.
Some development groups will offer a guarantee that, if you find a problem within a limited number of days after you accept the system, they will fix the problem at no additional cost. Because software doesn't decay or degrade over time, we think that there should be no time limit for free bug-fixing. That is why we offer free bug-fixing for the entire life of the software. If such a commitment and guarantee to quality is important to you, please contact us. We will help you build a high-quality software system.
