Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть

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;
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.
👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: Soundcloud | Google Podcast | YouTube


27 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Автор местами жжет. Наконец-то я увидела откуда ростут ноги в кривом баг-репортинге. Пришлось сподвигнуться на развернутый комментарий, как QC manager.
>>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.

С одной стороны вроде оно так, но junior специалистам такое советовать не стоит, они просто могуть закапаться и не выкопаться ;)

>>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.

Вот, как раз то, что я советую начинающим QC: будьте проще, используйте простые предложения. Чего советую и автору ;)

>>Build sentences correctly, basically the sentence structure looks like this: subject, predicate, objects.

А не проще сказать,что предложения должны бать согласно грамматике английского язика Не стоит использовать грамматические структуры, которые не знаете.

>>Bug summaries should be as accurate as possible; it should describe the sense of the bug.

Вообще-то summary describe core of the problem, но это уже продвинутые тонкости :)))

>>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).
Вы мне скажите какой это джуниор различает эту грань между нужными и ненужными шагами. Более того, классика жанра говорит и том, что нужно писать все шаги: а) не факт, что кажущийся незначительным шаг не станет ключевым в определении проблемы; б) не все программисты, особенно джуниоры, настолько классно знают продукт, что могут найти в программе фичу, написанную не ими, 2 года назад без детальных шагов.

А где про альтернативные варианты воспроизведения?

>>Remember the meanings of abbreviations...

Используйте абревиатуры по минимуму — люди в команде меняются, это могут читать не только члены команды (например заказчики), поэтому чем меньше непонятных буквосочетаний тем лучше (это же касается сленга)

>>don’t be afraid to discuss anything if you have a different point of view about something (but don’t forget to be polite);

Мы все еще про баги или уже перешли в плоскость философии обсуждая что-либо с кем-либо в вежливой манере :)))

>>customer’s word is law. :)

Ну и чему вы учите молодую поросль? Все что касается заказчика очень сильно варьируется от проекта к проекту. Бывают достаточно открытые заказчики.

>>customer’s bugs always are «Critical» and have Visibility «Up to 100%»;

Из той же оперы. Если команды заказчика и подрядчика интегрированны, то баги будут иметь равноценное значение. Правильные говорить, что баги с продакшина всегда критичны.

В нашем «мире» вообще все относительно, о чем я и сообщил в самом начале заметки.

Большинство (а с моей колокольни — так вообще ВСЕ) ваших замечаний так же специфичны и относительны, как и мои слова. Могу «разбить в щепки» все ваши напутствия, Вы же, в свою очередь, сделаете тоже самое с моим ответом... и зачем все это?

У вас одна специфика, у нас другая.
Не вижу смысла разводить из этого дискуссию.

Если с вашей точки зрения тут что-то есть «вредное» для новичков и при этом не касается специфики и вариативности нашей с вами работы — я весь во внимании!

>>>>don’t be afraid to discuss anything if you have a different point of view about something (but don’t forget to be polite);

>>Мы все еще про баги или уже перешли в плоскость философии обсуждая что-либо с кем-либо в вежливой манере :)))

А тут я согласен с автором. Всегда лучше обсудить если считаешь что-то более уместным. И вежливость в команде играет тоже немаловажную роль, вы всё же вместе одно дело делаете)).

Напомню про отличную статью Егора Егорова «Эффективные багрепорты» dou.ua/...ve-bug-reports

Как всегда посты на англ. заканчиваются соревнованием у кого лучший английский :)

Александр, действительно, что за причина была для написания поста на английском? В чем профит? :)

Было написано 2 года назад на старом месте работы для обучения новичков. Я спросил стоит ли переводить — сказали нет — вот и не переводил.

Я не претендую на идеальный английский и идеальное описания чего-либо.

Но я считаю что любой начинающий QA может отсюда вынести полезности.

Если для кого-то тут ничего интересного и полезного нет — значит это просто не для Вас и Вам не надо. :)

Да я про себя не говорю. Каждому нужен свой материал. Мне было любопытно на счет языка и свое любопытство я удовлетворил.
Видимо ваши новички не плохо знали английский.

Отлично!

Бэй, пацань, хай сы фащем хора ши сы ни прикалим оляыкэ де джуниорий иштя, аха?

Alexander, do you really think that there are so many junior QA are going to read this post in English?

Why don’t you translate it in Russian/Ukrainian?

The experienced people already know most of the tips you gave. Junior QA will not read this post, first of all because of the foreign language. For whom you are writing for?

А гугловский переводчик пробывали применять?

Ага, вы до сих пор верите в Гугловый переводчик?
Вот пример:

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.
Ошибка резюме должно быть как можно более точным, он должен описать чувства ошибка. Вы не должны записывать все шаги, как одно предложение в резюме.

Google Translate отлично переводит с русского на украинский, и английского США на Британский Английский. А вот с английского на русский — плохо.

I read this tips and I’m not even a junior tester, but I hope I’ll become...

I was sure that the level of English command required from any Junior QA should be more than enough to read such simple texts as this one. Am I wrong?

Вообще-то тестировщики и должны знать английский более углубленно чем девелоперы, ведь им нужно описывать баги на английском.

Если у Junior QA который это прочитал есть серьезные проблемы с пониманием написанного — это повод задуматься об уровне языка и все таки попытаться перевести, но не гуглом, а со словарем!... Гугл Транслейт — зло!

И мне захотелось тут позлорадствовать чуток)) я как-бы Junior и прочёл всё очень доступно. Как по мне знание языка не должно иметь сколько нибудь значимый приоритет. Можно быть и Senior QA и не знать английского(хотя наверное таких сеньоров и не сыскать)

Можно быть и Senior QA и не знать английского
Ам... простите, но нельзя :)
Ребята, вы или па русски или не па русски пжалуйста.
п.с.
Не все начинающие спецалисты читают на ненашем.

п.п.с.

Check spelling in all fields.

Аффтар, сделай сам сначала!

Заметили опечатку? Не томите, расскажите нам о ней.

напр.:

Make sure that the bug is missing in BB.
а далі варіація :
Perform steps exactly as they are written, making sure that bug indeed can be reproduced by following them.
Звиняйте, можливо я не правий, але перше що кидається в тексті
— артиклі, то є то нема, то означений, то не означений;
— підрядні речення із that, їх море; внутрішній голос каже, що з цим щось не так;
— аналогічно із реченнями з but;
— «as they are written»;
Резюме: мовою або язиком було би краще, хоча б для цілевої аудиторі.

Да, спасибо, с артиклями есть проблема, похоже.

— підрядні речення із that, їх море; внутрішній голос каже, що з цим щось не так.

А ваш внутренний голос не приложил ссылку на правило или что-нибудь типа того? Вроде как предложение с that само по себе ошибкой не является, да и носитель языка, который это читал, проблемы не увидел.

З технічної точки зору, текст правильний, та кидається в очі «руский англійський». Якими конструкціями людина мислить на одній мові, лоб в лоб переносить на іншу (чим не гуугл перекладавка в покращеній формі).
Щось схоже було з інтерв"ю про одну з львівських фірм, написане дівчиною, яка думає українською, а текст викладає російською.
Якщо достатньо читаєш на різних мовах, такі н«юанси кидаються в очі.
Це так як почуття доброго смаку, підручника з чіткими правилами нема, якщо воно розвинуте, то достатньо погляду, що відчути річ є «комільфо» чи не дуже.
п.с.

Ми ж вболіваєм за якість ДОУ, чи не так?

простите, но помоему вы придераетесь, особенности акцента и диалекта будут всегда бросаться в глаза, я считаю это нормальным порядком вещей, с этим необходимо мириться, «человек не рубль, чтоб нравится всем»))))

кидається в очі “руский англійський”. Якими конструкціями людина мислить на одній мові, лоб в лоб переносить на іншу

Приведите пример где мною было так написано и напишите свой, как вы считаете — правильный, вариант!

— «as they are written»;

Обычная пассивная форма. Ниче такого.

Подписаться на комментарии