To help the IT team – “Regulations for creating bugs” or “How to make the task clear to you from vacation”

To help the IT team – “Regulations for creating bugs” or “How to make the task clear to you from vacation”

Prehistory

I wrote this regulation based on my experience as a leader in an IT company with a web application. Its points have been verified by practice. The initial versions were (naturally) based on best practices from the Internet, agile and the experience of previous and current managers.

It is worth noting that although I was at some point in the role of a QA lead, I do not have the appropriate training, but I know many QA engineers and leads.

I personally recommend the following algorithm: copy paste, adjustment to your specifics, practice of use. It is important to pay attention to the needs of developers, PMs, system analysts and other team members who will analyze bugs.

This regulation does not focus on any specific task tracking system. It can be used for JIRA, Kaiten, GitLab, Trello, and for an excel table.

general information

Key principles of bug creation:

  • imagine that the bug will be reviewed by a person practically unrelated to the developed software (for example: PM, scrum master, developer from another team or you after vacation); the more detailed, clear and succinctly the bug is described, the better

  • a bug may become irrelevant after some time – this is normal, but it will still have to be checked (maybe in a year or two)

When creating a bug, you must specify the following points:

  1. Name

  2. Priority

  3. Environment

  4. Playback steps

  5. Expected result

  6. Actual result

  7. Additional Information

  8. Connections

It is also possible to optionally add additional information to the bug in the form of screenshots (indicating the problem), videos, correspondence, links to other bugs/tasks, etc.

The points of the bug

The name of the god

This point should reflect in 3-5 words the general problem of functionality. The main criterion of the title is clarity for the reader.

At the beginning, you can add conditional tags in square brackets (no more than 3), which can display the name of the feature, the location of the bug, etc., which is understood by most of the team.

If it is not possible to compose the correct name of the bug in 5 words, you can use conditional tags + key phrase. In this case, the clarity will be less, but this name will make it easier for the participants of the discussion to understand what the conversation is about.

PS This is a very important point. The ability to correctly indicate the name is very valuable.

Priority

This is the importance of the bug to the product.

By default, several criteria are used to assess the priority of a bug:

  1. Impact on key scenario

    • blocking (↑) or not blocking (↓)

    • visibility of the bug for the user (↑) or conditionally invisible bug (↓)

  2. Periodicity of reproduction

    • total probability of reproduction (higher chance – higher priority)

    • constant playback (permanent bugs ↓)

  3. Other factors

    • importance for the customer

    • assignment deadline

    • importance to the interacting department

    • etc.

Conventionally, the priorities can be:

  1. Blocking (handover feature or user script) – сделать срочно

  2. Critical (Visual bugs) – сделать в первую очередь

  3. Medium priorityсделать во вторую очередь

  4. Lowсделать когда будут свободны руки или никогда

Depending on the criteria, even a visual bug can be a low priority, and a refactoring (a change invisible to the user) – critical. The priority may change over time. The primary assessment is based on a set of criteria and conditional priorities (see the priorities in parentheses).

Environment

This is a set of software (with an indication of the versions) in which the bug is reproduced. Information on reproduction and analysis of the bug is given.

Mandatory points are:

  1. Frontend version

  2. Backend version

  3. Browser(s) + browser version

  4. Stand (or git branch)

Playback steps

This is a user case – a script for reproducing a bug. This information is necessary to reproduce and analyze the bug. The more detailed the steps are, the better. The use of screens with applied pointers is allowed.

Requirements for the point:

  • the steps are formed in the form of a list that is enumerated

  • steps are indicated from a key point (login/visit to the site, etc.)

  • the steps are specified as accurately and in detail as possible; more information is better than less

PS If you want/need to use screens in the steps, I recommend using footnotes and marking the screen (example: in the text – “screen 2”, in the picture, sign “2” above). This will significantly improve reading.

Expected result (OR)

This is the result that should be observed in the system in the conditional norm.

Requirements:

  • screenshot with the browser console open on the network tab

  • screenshot with the browser console open on the console tab

  • tabs should be scrolled down

If a design screen from figma is used for the OP, then the console is not needed.

PS The network tab can be combined with the console tab (the esc key in chromium when the network tab is open).

Recommendations:

  • indicate the result in one phrase or an unnumbered list

  • indicate a reference to the source of truth (it can be a task, documentation or person)

Actual result (FR)

This is the actual result of the system after performing these steps.

The recommendations and requirements are the same as in the OP.

Additional Information

This item includes any information that may be useful for bug analysis. These can be links to tasks, features, screenshots, people, etc.

Separately, you can indicate your assumptions about the breed of the bug. This can be extremely useful in the future when analyzing a backlog or fixing a bug.

Connections

This is a link to tasks, problems, people, documentation, etc., with the indication of the reason for creating the connection (if the functionality allows it).

Related posts