Bug Philosophy - Error Description

Having experience in several software testing teams in various projects and companies, ranging from freelancing to outsourcing and product companies, I noticed the fact that each team reports an error report according to its traditions and styles. At the same time, most of the Timlid or leading QA engineers who invented these traditions say that it is their style of describing a bug that is the most correct and as close as possible to Feng Shui. No, I do not want to say that the bug reports are radically different everywhere, no, they are close to the standard view with a title, steps to play, a description of the error and the expected result, but they have their own style from project to project. For example, the details of the description of the playback steps (I will describe my vision on this topic in the next post), the order of the expected result and the description of the error, etc.

Young professionals, coming to the first project in their lives, perceive all the traditions of test documentation and testing as a benchmark, since they have no experience and they have nothing to compare with this process. Taking as a basis any type of error report design, when changing jobs at an interview, disputes may arise when answering the question: “Tell us about the design of the bug report”, because for the team in which you want to work the description style may differ. Here the important point is not to guess this very style, but having voiced one’s own and having heard criticism in his address, be able to substantiate his point of view.

To business

So let's get started. Often, I was confronted with the fact that team members react very painfully to the order of the location of the “Description of error” and the “Expected result”. Some believe that the first thing to be told is how the application should work properly, and then what we actually get, while others do the opposite. I adhere to the opinion of the second group and now I will tell why.
')
Having opened the form for filling in information about a new bug-tracker dweller, do not forget why we are doing this. Yes, yes, we came to tell the whole team about it. And first of all, we will talk about what a handsome man we saw in the open spaces of the software being tested and should try to bring it in all its glory with all the details. Obviously, the priority in the description will go to those details that relate directly to the error itself. These details should be arranged in the sequence in which everyone who wishes to look at the found "beast" will perform the steps for its complete reproduction. Therefore, the first argument for prioritizing the location of the error description is that after performing the playback steps, the programmer or another member of the team should see that these steps did not work out the same way, and not how it should actually work.

The second argument is that after several weeks the team members (especially programmers) are already more or less familiar with the product specification (if any) and know how it should work correctly. Therefore, it will be enough for them to look at the description of the error and immediately understand what is wrong and how it should be without reading the “Expected Result” section, which saves a fraction of the time, especially if the project burns in time and the whole team knocks at the same time with ten fingers keys, trying to invest in these terms.

The third argument follows from the second, and its essence lies only at the level of perception when searching for the necessary information in the report. It is known that not all bugs contain “Expected result”, for example, such where the application does not start at all, if it is desktop, or when entering the page we see an error 500, if it is a web site. In this case, the “Expected result” of the type “Application should work without error 500” or “Website index page shoud be displayed” carries only useless information load, complicating the visual perception of the error report, and often is not inserted into the report. So those who read only the steps for playback and the error description itself will not notice the absence of the “Expected result” block and quickly switch to making further decisions when it is located in the bug reports below the “Error description” block.

This is only purely my opinion and I can confidently say that there are hundreds of people who think differently or who completely agree, adding to the three arguments listed above. Each team works according to the rules and customs that are convenient to it.