A good software testing strategy is shaped not only by product risks, but also by factors within the project. Technical experts with advanced level ISTQB certification prescribe following project-based strategic principles:
1) We should not lose our bugs in the cracks between the software testing engineers. Unless we apply diverse half measures or overlapping software testing assignments, we face a real risk of not testing something because it lies on the boundary between the assignments of two testers (or teams).
2) We should frequently test what we have been asked to test. We should remember that we are testing on behalf of many clients. What do they think we should test? We should find out and make sure that we are doing at least some of it.
3) Occasionally we should test what we are asked not to test. Sometimes we are asked not to test certain parts of the product. This can be a delicate matter, and it is difficult to tell as to what to do. However, sometimes the things we are asked not to test are the things that need it most.
4) We should test the confusion and conflict. Wherever there is confusion and conflict, bugs will certainly come. If the programmer seems not quite sure what a feature is supposed to do, we should test it. If he is new to the technology, we should test it. If two programmers are building units that interface with each other, we should test the interface. This way we will not be disappointed.
5) We should not beat a dead feature. When it is clear that a feature seems full of bugs, we should not continue to test it unless we check in with the developer. It may be a bad build or a bad configuration. Also, if a component is so bad that it is going to be replaced rather than revised, any bugs we find will be summarily closed, so we should not bother software testing.
6) More change means more Software Testing. Theoretically, the smallest change in the product can create large and non-local effects. That means any change can potentially invalidate all the software testing we have ever done on the product. In reality, most changes have a fairly localized effect. However, it is certainly true that we must follow the changes with our software testing. The more change in the product, the more software testing we must do. This becomes a big deal in the end game of a project.
These principles have been pointed out in the syllabus for ISTQB Certification CTFL as well.
1) We should not lose our bugs in the cracks between the software testing engineers. Unless we apply diverse half measures or overlapping software testing assignments, we face a real risk of not testing something because it lies on the boundary between the assignments of two testers (or teams).
2) We should frequently test what we have been asked to test. We should remember that we are testing on behalf of many clients. What do they think we should test? We should find out and make sure that we are doing at least some of it.
3) Occasionally we should test what we are asked not to test. Sometimes we are asked not to test certain parts of the product. This can be a delicate matter, and it is difficult to tell as to what to do. However, sometimes the things we are asked not to test are the things that need it most.
4) We should test the confusion and conflict. Wherever there is confusion and conflict, bugs will certainly come. If the programmer seems not quite sure what a feature is supposed to do, we should test it. If he is new to the technology, we should test it. If two programmers are building units that interface with each other, we should test the interface. This way we will not be disappointed.
5) We should not beat a dead feature. When it is clear that a feature seems full of bugs, we should not continue to test it unless we check in with the developer. It may be a bad build or a bad configuration. Also, if a component is so bad that it is going to be replaced rather than revised, any bugs we find will be summarily closed, so we should not bother software testing.
6) More change means more Software Testing. Theoretically, the smallest change in the product can create large and non-local effects. That means any change can potentially invalidate all the software testing we have ever done on the product. In reality, most changes have a fairly localized effect. However, it is certainly true that we must follow the changes with our software testing. The more change in the product, the more software testing we must do. This becomes a big deal in the end game of a project.
These principles have been pointed out in the syllabus for ISTQB Certification CTFL as well.
No comments:
Post a Comment