Как не надо заводить баги. Часто встречающиеся ошибки

Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага.

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

Итак первый баг - «Вот в эту систему захожу и нажимаю отключить»

непонятно:)
непонятно:)

Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).

  • «При кодировке UTF 8 русские слова переносятся кракозябрами»

милая ккракозябра
милая ккракозябра

Единственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?

Самое горькое и печальное – это последующие коммуникации по подобным багам с краснеющим от стыда лицом. Еще хуже – краснеть перед разработчиками и аналитиками за баг, который перешел к тебе «по наследству» от уволившегося тестера. Объяснять, что это не мое – «меня заставили» – последнее дело, зачастую всем абсолютно все равно, но при этом каждый коллега по такого рода багам предопределяет уровень «горе-тестировщиков». Подобные случаи встречаются очень часто и, к сожалению, влекут за собой немало неприятных последствий, а именно:

  • подрыв репутации конкретного тестировщика и всех тестировщиков компании;

  • занижение значимости процесса тестирования;

  • дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);

  • появление разговоров о том, что тестирование – это проще некуда – горе-тестировщик смог, значит, и обезьяна сможет.

Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».

Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:

1. Работа на скорость

Скорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден?.

2. Отсутствие конкретики

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

3. Использование сленга при формулировке бага

Как уже говорилось в примере про «крокозябру»: если не хватает технической грамотности, Гугл в помощь. В противном случае, в глазах коллег вы будете олицетворять мальчугана с картинки: смешно и нелепо.

4.Пренебрежение примерами и скриншотами

Этот широкий жест не будет лишним и сэкономит много времени для скорейшего закрытия задачи.

P.S. Не стоит путать: скрин – нужное и дельное дополнение, но не полное описание бага. Скрин не должен заменять описание.

5. Своевременный перевод бага на разработчика

Гораздо приятнее, чтобы разработчики увидели актуальную на текущую дату и четко описанную версию бага. Это избавит от лишней траты.

6. Актуализация критериев приёмки

Условия игры могут меняться прямо во время тестирования. А зачастую и не единожды. Обсуждения могут происходить не только на общих встречах со всеми коллегами. Есть также официальная и неофициальная переписка, обсуждения по телефону, комментарии в задаче в баг-треккере и в различных мессенджерах.  И тут уже сотрудникам хочется быстрее дойти до истины, и часто никто не дублирует в режиме реального времени в задачу и не актуализирует критерии приемки.

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

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

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

7. Заведение «псевдобагов»

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

Из банальных примеров – при входе на страницу авторизации логин и пароль предлагаются автоматически. Это устранится очисткой cookies. Другой пример – кроссбраузерность. В одном браузере картинка четкая и на экране отображается прекрасно, в другом браузере – поля наезжают друг на друга. Возможно, дело в масштабе? Прежде чем бить панику, стоит сначала убедиться, что установка одинакового масштаба в обоих браузерах не устранит проблему.

8. Изменение ожидаемого результата

Бывают случаи, когда тестировщику не хватило информации для полного понимания процесса (отсутствие или наличие недостаточной/ слабый анализ). И может возникнуть такая ситуация, что через какое-то время после заведения бага выяснится, что ожидаемый результат, который вы указали, неверный. Он должен быть другим. И вот тут начинается самое интересное: тестировщик, чтобы замести следы «преступления» удаляет описание ожидаемого результата или (что еще хуже) начинает препираться с разработчиком, что подразумевалось другое.

Допустить ошибку - это нормальная рабочая ситуация. Не надо бояться её признать и исправить: либо закрыть задачу с соответствующими пометками и создать новую с актуальной информацией, либо по согласованию с командой изменить описание в текущей задаче.

Другая жизненная ситуация – заведение бага без ожидаемого результата. В таком случае надо пенять на себя и осознавать, что разработчик поправит так, как он поймет из описания. И далеко не факт, что правка будет совпадать с тем, чего вы ожидали. И отклонять решенную задачу с претензией, что вы ожидали «чего-то другого» будет непрофессионально. Поэтому все свои ожидания и пожелания надо обязательно указывать в критериях приемки.

9. Неумение отличить фронт от бэка

Одним из важных критериев при заведении бага является умение отличить, к какой части сервиса относится баг – к фронтенду или к бэкенду.

Пример: в поле не работает валидация. Баг задублировался и пришел и к фронтовым, и к бэкендовым командам. Обе команды тратят время и ресурсы на то, чтобы поправить баг.

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

10. Работа с логами

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

 

бывает и так
бывает и так

Работа тестировщика напрямую и неотъемлемо связана с багами: мы их обнаруживаем, заводим в баг-трекинговые системы, контролируем их устранение. Поэтому очень важно правильно их заводить, ведь без них никуда. Баги –жизненно необходимый орган в процессе системы. Постарайтесь внимательнее их заводить, тогда всем станет лучше.

Комментарии 17

    +1
    памятка супер
      +1
      Смерть на взл
        +1
        Краткость сестра та…
        +1

        Я вот не понял: если у вас баги заводят тестировщики — их же можно проинструктировать, ка делать хорошо. Логи, скриншоты, термины общепринятые… Если баги заводят пользователи — для чего тогда нужны тестировщики, непонятно.

          0
          Конечно, в организациях есть правила на разные случае, в т.ч. и на оформление багов, но иногда это общие требования. Более чёткие требования или правила формируются по ходу работы и развития продукта. Так же, лексикон зависит и от региона.
          На этапе тестирования не всегда можно отловить все ситуации. Некоторые (например, если речь про мобильную версию сайта или мобильное приложение) могут быть специфичными для конкретного устройства, системы или оператора связи.
            0

            Тем более. У каждой ошибки есть фамилия, имя и отчество ;). Плохо оформленный баг можно вернуть автору для уточнения. Можно отбросить с пометкой "not reproduced". Ошибаются все, нет смысла делать из этого трагедию.

          +4

          Имхо очень многие проблемы из перечисленных пропадают если тестировщиков и разработчиков объединить в одну скрам команду и работать не по-одиночке, а совместно:


          • баги на этапе функционального тестирования новой фичи вообще можно не заводить — достаточно дейли митинга, командного чатика и общения с разработчиком напрямую
          • если багу таки решают завести в системе — скорей всего она некритичная и/или не может быть исправлена во время разработки (как вариант — решили не чинить сознательно). При этом разработчик уже в курсе событий и помогает оформить так, чтоб было понятно другим разработчикам
          • баги от клиентов проходят через команду (включая разработчиков) и, точно так же, как и баги на этапе разработке — оформляются более подробно
          • благодаря постоянному сотрудничеству и общению разработчиков и тестировщиков, последние лучше понимают технические детали реализации, а также на что обращать особое внимание во время тестирования
          • если дать тестировщикам возможность писать интеграционные тесты на стадии разработки, синергия становится ещё сильнее
          • в идеале, тестировщики также должны уметь читать и анализировать не слишком сложный код — это позволяет находить нетривиальные проблемы
            +3
            Если IT специалист не знает слова кракозябра (а применительно к шрифтам я синонима в одно слово сам не подберу, подскажите а?), то он наверное не видел даже BSoD WinXP. Так что проверьте возраст, возможно с ним еще нельзя заключать трудовой договор.

            Дошел до пункта 7, то есть если у меня не ожидаемый хром, а скажем фаерфокс и сайт разъезжается на масштабе отличном от 100%, то я должен ломать глаза уменьшая
            масштаб? Мда, с таким начальством тестировщики не нужны, сколько багов не найдут всё будет фичей.
              0
              Согласен, «кракозябра» нормальный термин для компаний в которых программистов не заставляют ходить в костюмах. Надеюсь, таких большинство. Остальные могут использовать «нечитаемый/непонятный символ».
              +1

              Бнопня а не кракозябра. Это называется бнопня.

                0
                не путайте бнопню и кракозябру, бнопня это когда cp1251 читается как кои8, а кракозябра это когда русификатор не прогрузили, и пишут будто подгрузили (для однобайтных кодировок).
                0

                Случай из практики. Разрабатывал backend сервиса доставки уведомлений. Заказчик и ПМ — 100% уведомлений должны придти вовремя. Ок, понятно. Тестировщик гоняет приложение днями и ночами. И иногда прибегает ко мне с глазами полными ужаса — у меня половина уведомлений недоставлена, я тебе тикетов наделал. Садимся, рассказываю flow, еще раз кидаю ссылку на документацию с описание бизнес-логики, показываю, что это нормальная ситуация, уведомления недоставлены потому, что их мобильное устройство получателя выключено, поэтому backend перевел уведомления в состояние "недоставлено в срок". Прошу, почитай доки, спроси меня, прежде чем тикеты создавать, от количества которых у ПМ уже нервный тик. Ок? Ок. Как вы понимаете, итерации повторялись с определенной периодичностью.
                Вывод, тестируя бизнес-логику надо понимать бизнес-логику, а не додумывать ее. Очевидное, но порой невероятное открытие для некоторых тестировщиков.

                  0
                  По-своему, вы правы. Даже просто правы. Но с точки зрения всего проекта, это часто значит, что и пользователи будут так же поднимать это вопрос. И кого они будут считать виноватым в этом? Скорее всего программиста. Впрочем, если вам от этого не икается, то всё нормально.
                    0

                    "пользователи будут так же поднимать это вопрос"


                    Задокументированные баги становятся фичами. Если недоставленное уведомление это норма — надо делиться этим знанием. А то будет как с тем принтером, который не печатает, потому что бумага кончилась. а положить пачку бумаги в лоток умеет только Главный Администратор.

                  0
                  Вы просто не поняли
                  Второй пункт был очень поучительный и он о том, чтобы описывать баги полностью
                    +1
                    Улыбнуло:
                    При заведении бага следует прикладывать ссылки на логи с целью уменьшения экономии времени.

                    Но все-таки, наверно, формулировку лучше поправить ;-)
                      0
                      четко описанную версию бага.
                      У свеженайденных багов есть версии? Не понял этот пункт.

                      6. Актуализация критериев приёмки
                      Четыре абзаца текста, на мой взгляд, можно было свести к одному, донеся простую мысль — указывайте ожидаемый результат.

                      заведение бага без ожидаемого результата.
                      Этот абзац относится к пункту 6, а не 8.

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

                      Самое читаемое