We will not dwell on how important it is to "find and eliminate" bugs in the software developed on the assumption that if you visited our site, we have independently come to realize that or chose the rather challenging profession tester. So start with the most important thing.
What is a bug? The answer to this question is both easy and difficult. First of all, a bug in the program realize the error, which is manifested in its use. Bug can be called as well, and undocumented or unwanted "side" reactions to the program or that the user as well as using it in conjunction with other software or hardware configuration to another.
There are other definitions of bugs. For example, in his book "Software Testing" Sam Kaner and colleagues determine the cause and Myers Beizer: "If the program does what the user of it reasonably expect, then there is a programming error.
There is no absolute definition of error, no exact test of having them in the program. We can only say how the program is not doing its job – it’s entirely subjective response. "
They (Kaner et al) indicate that the determination of errors as discrepancies between the program and its specification – not true. Since even the exact specifications of the corresponding program contains errors in that case, if there are errors in the specification itself.
Robert Culbertson and colleagues in his book "Rapid testing" gives a definition of software errors: "In simple terms, a programming error – neither more nor less than a flaw in software development, which causes inconsistency of expected results of a software product and in fact the results obtained. Defected may occur at the encoding stage, the stage of formulating the requirements or design stage, or is it the reason may lie in an incorrect configuration or data. The defect could also be something else that does not meet the expectations of the customer and that may or may not be defined in the specification of the product. "
As we see in literature can be found a number of synonyms for that concept. In addition to the bug quite common terms such as an error, the problem, defect, fault and of course the "slang" glitch. But whatever term we are not using it is not changed.
Not to be confused bugs (errors, defects, etc.) with the so-called features done. We tend to unite under this concept above all those features and properties of the program, which it has not, but in our view it is would not mix. Of course, features – a purely subjective. As a rule, well-organized and planned projects to meet them should not, because all of the functionality of the program must be specified before the start of development (see life cycle). This is especially true of projects that are being made for a specific customer. That he (the customer) and ultimately determines what features / properties / functions should have a program.
Typically, most systems for tracking problems (bug tracking system – bug tracking system) can form not only reports on bugs (Bug Report), but also to make Request properties that allows testers to offer suggestions to improve the test program.
Classifications, there are many bugs. First of all, in my opinion, this is due to the fact that these classifications are based on different criteria. Part of the classifications is more theoretical in nature, a part – will be useful from a practical point of view. Unfortunately, covering all possible classification – a difficult task, and it is hardly expedient. I will try to highlight some of the most important of them.
On the point of application bugs can be divided into:
Sam Kaner et al, in his book "Software Testing" results in a much more complete classification error on the grounds.
In our opinion, more practical classification is used in some software-collectors (or as they are called – issue tracker (bug tracking systems), for example, BugCollector Pro by Nesbitt Software Corporation and many others – see Software).
Unfortunately, not all systems use tracking one and the same classification. Moreover, the flexibility of setting most of them can easily change the concepts used by those who are more accustomed to you or received by your company.
In general, following the above classification is purely practical in nature, is my interpretation and is far from perfect, but nevertheless, it allows you to provide sufficient continuity between the developer and tester:
Causes crash – the name speaks for itself. Under it together all those bugs that can cause a crash or hang the entire system, disrupt the stability of its work.
Cosmetic – under this concept combine design errors (for example, is not the line color or font), user interface, etc. In other words, all those bugs that do not interfere with work program, but spoil it "marketable."
Critical – all that which leads to freeze or crash the program without affecting the operating system as a whole.
Error Handling – bugs in error handling.
Functional – bugs in functionality.
Setup – Installation bugs.
Minor – theoretically irrelevant, or no bugs utochnennnogo genesis.
Suggestion – the so-called proposal. In our opinion it is best to refer feature.
To describe the bugs are special tools, as they describe in a word processor – not only tedious but also useless. Examples of such tools can serve BugCollector Pro (Nesbitt Software Corporation). We propose to consider the following:
Report – includes a more detailed message about what exactly is the error.
Steps to recreate – a detailed step by step description of what the tester, which lead to the appearance of the described errors.
Workaround – description of ways to get around the error, if any.
Sonfiguration – description of hardware and software configurations, and configuration settings in the software being tested.
We have presented only the most important in our opinion the information that must accompany each described Bagua. Of course, all these parameters can vary widely depending on the type of software development and testing purposes, as well as many other factors.