Custom Search

Documentation Errors

The purpose of error reporting is fixing it. About how to describe the error, what it consists of a description of the error and how it might look like the example tells this story.

So you found a bug. Not shelving them to start to write a bug report (not to procrastinate, then you can forget to write a report, to forget in what place was a mistake to miss part or even misquote the situation).

The first step is desirable to calm down and not make any sudden movements, not to press extra buttons, etc. We must remember the sequence of actions that have been made and try to reproduce the situation. Better to do it in a new browser window (if it is a web-application). Come and write data input / command buttons are pressed, in any menu jump to, what kind of reaction system to these actions, what error message is displayed.

Now we need to write their own actions. Record should be brief, but clear and understandable. Find a middle ground. If you write a memoir, the programmer will not read them or think that the error is very difficult and would defer until later, and ultrashort report no one will understand. As a consequence, error correction (bug) will hang in the air and sent back to you marked "not play" or ask clarifications, thereby simply and your spending and your time. Also, do not enter into one report more than one error. Motive is the same.

The report is written not only for ourselves but for others. So, it should be written so as to understand everything, but had no idea that you would like to say, do not ask again. Ask yourself a question: whether to repeat your actions the person who first sees the product?

If possible, try different options to express exactly the problem.

It is also desirable to avoid jargon or expressions which may be difficult to understand others.

In no case does not need to pass an oral report bugs, write an e-mail, icq, etc.! In most cases, forget about them, not treat them seriously and, if not corrected, especially in this case will blame you. You need this? All errors must be observed and described and have its own unique number. Then, for uncorrected errors will be the responsibility on the programmer.

These records will need another bug testers to work with you, the managers for them to see that you work and work productively, testers, who will come for you, as well as for writing reports.

Error Description

We now turn to the description of the error. Depending on what the company bagtrekingovaya system (accounting system errors), there will be different input fields.

At the beginning of opening a new bug report. It is possible that you will see a lot of lines for the filling, but it is possible that they do not all have to fill. It is better to consult with other testers, a manager or head of the group testing. But most likely have to fill out the following fields:

  • Priority (as a serious mistake and a speed of execution requires. Must be corrected quickly or you can wait)
  • Designate (who will deal with an error)
  • Class (this is what kind of error-serious, minor, typo …)

Header Error

The headline should concisely and fully describe the problem. We spend a lot of time leafing through the bugs database and browsing the headlines errors. Much time can be saved if the headlines are clear and not have to open the error description to understand what was meant.

Problem Description

Describe the problem better by using "arrows". With them, the text of the report is discarded many unnecessary words that interfere with understanding the essence.

Example: I opened -> introduced in the word bbb ccc -> clicked ddd -> get errors: ddd

An example from the life

Title: The problem with the menu "forgot password"

Problem Description: Go to the login page -> click "Forgot Password" - "in the" Personal Account "enter 2389 -> in the« e-mail »enter -> System says:" Error sending message . (# 1) "

If necessary, the data in the operating environment, configuration, logs. Is there a dependence on the configuration, installation, condition, options, settings, version, etc.


To make the report more detailed and vivid can and must resort to:

  • links
  • screenshot
  • video recording


Well here everything is clear. Popped up an error - is taken link to this page, and inserted into the report. It is desirable also with screenshots. (Assuming that the tested Web application - approx. Editor)


A very useful thing to visualize the problem. Make a screenshot of the problematic area. (The simplest thing - it's on the keyboard to find the button Print Screen, then press it to open the program from Paint (if we are in the operating system of family Windows - approx. Editor), which is automatically installed in Windows and in her press Ctrl-V, then cut out unnecessary , store (preferably in the format JPG))

Although there is a more professional program that are more adapted to this kind of action and have a lot of very useful features, such as SnagIt, HyperSnap, HardCopy, RoboScreenCapture, FullShot 9, HyperSnap-DX 5, TNT 2. Screenshot want to attach to the bug report.


If the error difficult to describe, it is the most appropriate method. Program: SnagIt, CamStudio.

See Also

No comments: