The main reason why we use the term “error”, and not the official term “defect”, is that the “defect” implies that someone should bear responsibility for it. It is supposed that the programmer is dishonest, lazy or incompetent. Errors made by a qualified programmer running modern software in the appropriate software development environment are not defects (Hopefully you will not blame us, authors of this article for not being strong enough).
In good, well-thought out software, errors mostly occur due to limited ability of people to combat complexity in product designing, but not to their stupidity. The better the program process is, the less likely that the errors which persist during behavioral testing are errors made certain programmers. Most of the errors that are found in well-designed, quality software during behavioral testing result from unpredictable interaction between components or between programs, or unpredictable side effects caused by seemingly completely innocent processes.
Technical writing company is in haste to create quality document for your project so that you can take advantage over your competitors! Prepare actual, truthful, reliable and comprehensible content for the target audience.
If the errors found through behavioral testing are simple and can be easily categorized, this indicates that the workflow is not satisfactory, but not because the programmer has made mistakes. We take it for granted that the programmer is well trained and competent and has the proper tools. This is called “the competent programmer hypothesis”. Since the person who conducts behavioral testing is not necessarily the same person who writes the software, it is important to keep this hypothesis in mind, believing that human flaws and dislikes do not invade the programming process.
Three broad categories of errors are useful: module / component errors, integration errors, and system errors, named this way in accordance with the development phase in which errors are most likely to be found.
Errors of modules / components can be found and avoided most easily. When we test the system and the test reveals an error, we cannot say what was the cause of it – a module error, an integration error, or a system error. We learn this only after the error is eliminated. Since system testing requires much more resources than module / component testing, identifying module errors that remain uncorrected at the time system testing begins is a waste of effort. Thus, the task of module / component testing is to reduce the number of errors that leak into subsequent stages of the process.
Add Comment