Как улучшить описание багов

Рекомендации по описанию багов в отчете о дефектах

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

Чем лучше у Вас будет получаться описать баги – тем более ценным QA-специалистом Вы станете для работодателей и сможете найти высокооплачиваемую работу.

Поэтому здесь можно дать следующие советы о том, как улучшить описание дефекта ПО в баг-репортах.

1. Заголовок по принципу «Что? Где? Когда?»

Заголовок представляет лаконичное описание дефекта. В связи с этим, он должен быть в понятной сразу формулировке. Поэтому опытные тестировщики советуют записывать заголовок по принципу «Что? Где? Когда? (при каких условиях?».

Например: [Что?] Форма выбора данных [Где?] на странице сопутствующих товаров не подгружает справочник товаров [Когда?] при нажатии на кнопку «Выбрать».

2. Краткость – сестра таланта

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

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

3. Сделал описание – еще раз перечитай

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

Конечно, старшие коллеги Вас поправят. Но все-таки желательно сразу делать качественное описание. А для этого есть простой рецепт: как только закончили баг-репорт – еще раз прочитайте его от начала до конца. Это помогает «вычистить» досадные опечатки и путанные формулировки.

4. Соблюдайте терминологию

Важно называть вещи своими именами (как принято в тестировании). Кроме того, у Вас в команде проекта, возможно, будет своя дополнительная терминология для объектов тестирования – используйте ее.

И еще: эмоций в описании багов быть не должно, они только вредят. Описывайте сухо, объективно, по фактам.

5. Подписывайте скриншоты

Скриншотов может накопиться несколько, и в них можно запутаться. Сложно понять, чем «Скриншот1» отличается от «Скриншот3». А вот если озаглавить «Ошибка 500 при загрузке страницы авторизации», то это экономит время всем читателям.

То же касается и других прикладываемых документов.

6. Тренируйте навык описания багов

Описывать дефекты – это вполне тренируемый навык. Чем больше Вы будете работать с этим, тем лучше у Вас будет получаться. Поэтому перед получением своей первой работы тестировщиком полезно практиковаться в описании багов в специальных инструментах QA.

Резюме

Описание багов – важное умение для тестировщика. Чем короче и понятнее описание – тем эффективнее работает QA. Наши рекомендации помогут Вам улучшить этот навык.