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

Велика частина цієї статті була написана давно і призначена в першу чергу для 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;

eg - exempli gratia (for example).

Steps to be done before submitting a bug

Make sure that the bug is missing in BB.
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.
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.
Make a list of words (or word combinations) that you have problems translating and ask your QA Lead to help you.
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.
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

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.
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.
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).
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.
Do not use additional line breaks (except those that are between steps and actual result, actual and expected results, etc.)
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 (eg 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).
If it's possible, never leave informative fields (eg Environment, Functionality, OS version, etc.) empty if they may help to localize the bug.

Steps to be done after you finished writing the bug

Check spelling in all fields.
Carefully look through all fields, making sure that everything is written correctly.
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
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.

Опубліковано: 22/02/12 @ 02:17
Розділ Різне

SEO Блог