Bug reporting for dummies, или Шпаргалка молодого тестировщика

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Большая часть этой статьи была написана давно и предназначена в первую очередь для Junior/Intern QA Engineers с маленьким опытом работы. В тексте в общих чертах описано, что должен сделать QA до, во время и после написания бага, а также даны общие напутствия и пожелания.

Текст может содержать ошибки и неточности, и уж точно не является идеально правильным подходом, однако может пригодиться начинающим специалистам по тестированию.

QA-отдел в Groupon (© Life@Groupon)

Information listed in this document is not obligatory; it’s only a recommendation, based on my own experience.

List of abbreviations

BB — Bug Base;
SAO — Same as Original;
N/A — Not Applicable;
CNT — Cannot Test;
CNR — Cannot Reproduce;
N/T — Not Tested;
OS — Operation System;
e.g. — exempli gratia (for example).

Steps to be done before submitting a bug

1. Make sure that the bug is missing in BB.
2. Make sure that you have done as deep investigation as possible (if the bug is not SAO) and have found the real cause of the bug.
3. Look through other bugs in BB, making sure the steps you are going to write are similar to those that exist, so that the same actions are described similarly.
4. Make a list of words (or word combinations) that you have problems translating and ask your QA Lead to help you.
5. Build sentences correctly, basically the sentence structure looks like this: subject, predicate, objects. As an example:
   “N” access key is assigned both to “New Page” and “Clone” items in “Insert” menu:
   Subject: “N” access key
   Predicate: is assigned
   Object 1: both to “New Page” and “Clone”
   Object 2: in Insert menu.
6. Design a sequence of filling the fields while writing a bug and always follow it. This will exclude the possibility of forgetting to fill some fields.

Steps to be done while you are submitting a bug

1. Bug summaries should be as accurate as possible; it should describe the sense of the bug. You should not write all steps as one sentence in the summary.
2. Detailed description is needed only in the case when a more extensive description is required to describe the bug before performing the steps to reproduce it.
3. The number of steps should be minimal, but enough to reproduce the bug.
   Do not write unnecessary steps.
   Do not describe trivial actions in several steps (if they don’t cause the bug).
4. Actual and Expected results. Actual result is an already received feedback, so it’s written in present or past tense, never in future. Examples:
   ⋅ Application crashes.
   ⋅ Document isn’t saved.
   ⋅ Dialog freezes.
   ⋅ Buttons have pressed appearance.
   Expected result is the feedback that is awaited by end user, but it doesn’t mean that it should be always opposite to the actual result. Frequently “must/should” is used to describe it. As an example, if application crashes at attempt to call Open File dialog, actual and expected results will look so:
   Actual: Application crashes.
   Expected: Open dialog should appear.
5. Do not use additional line breaks (except those that are between steps and actual result, actual and expected results, etc.)
6. Remember the meanings of abbreviations:
   N/A — not Applicable (functionality was changed, is missing in original, OS/Platform is missing etc.)
   CNR — cannot reproduce (bug is absent on this OS/Platform or cannot be reproduced due to some conditions).
   CNT — bug cannot be tested (e.g. because of a blocker bug)
   Fixed — bug occurred, but it was verified fixed on this OS/Platform after the retest.
   N/T — not tested (this bug wasn’t tested on this OS/Platform).
   
7. If it’s possible, never leave informative fields (e.g. Environment, Functionality, OS version, etc.) empty if they may help to localize the bug.

Steps to be done after you finished writing the bug

1. Check spelling in all fields.
2. Carefully look through all fields, making sure that everything is written correctly.
3. Perform steps exactly as they are written, making sure that bug indeed can be reproduced by following them.

P.S. Always remember:

• it’s better to ask than to miss the issue;
• always do Smoke tests of a newly received build before performing any retests and testing itself;
• always update your test list (or other test documentation) after finishing testing an object/area if something is missing in it or is outdated;
• don’t be afraid to discuss anything if you have a different point of view about something (but don’t forget to be polite);
• always keep your mailbox online (it’s better to set mail auto receiving to <=5 minutes);
• customer’s word is law. :) You may have another (or even opposite) point of view, nevertheless, customer’s thoughts always have priority;
• customer’s bugs always are “Critical” and have Visibility “Up to 100%”;
• don’t be afraid to make mistakes, only those who do nothing make no mistakes;
• don’t forget to check the existence of bugs that have “QA to Retest/Resolved” status and are assigned to you.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU