Все в разной степени должны нести ответственность за свое дело. Это касается любых сфер деятельности человека, в том числе IT. Если думается, что работать программистом – это быть творческим человеком, к которому необходимо проявлять снисхождение – это неверно. Не случайно многие компании практикуют оформление баг репорта. Документ составляется для фиксации промахов специалистов, выявления виновных, направлен на исправление сбоев.
Почему так сложно? Чтобы увеличить уровень ответственности сотрудников, быть уверенным, что выявленный дефект не увидит своего исполнителя, зависнет в воздухе, всеми забытый.
Что означает баг-репорт
Для специалиста-тестировщика баг репорт – профессиональный термин, обозначающий составленный отчет о найденных дефектах, который оформляется в bug-трекинговой системе.
Различные компаний имеют свой подход к bug-report. Одни считают это очередной бюрократией, предпочитают простецкое общение тестировщика с разработчиком через мессенджер. Другие ориентированы на систематическое выстраивание процесса, особенно это актуально для получения метрик, необходимых для понимания общей картины. Какие показатели могут быть полезны:
- Оценка эффективности работы команды, зависящая от количества допущенных погрешностей в определенные периоды времени;
- Какие модули более всего подвержены «болезням»;
- Кто из исполнителей больше «косячит».
Серьезность и приоритет – атрибуты баг репорта, которые помогают после проведенного анализа решать задачи, ориентируясь на степень важности.
Откуда появляются баги
Багами называется некорректное функционирование программного обеспечения. Причина кроется в погрешности в коде, допущенной разработчиком. Казусы могут иметь место, если:
- Работа делалась впопыхах из желания уложиться в короткие сроки;
- Программист не смог сконцентрироваться (устал, болел, находился в стрессовой ситуации);
- Нарушена коммуникация среди участников команды;
- Непонятное ТЗ;
- Недостаток знаний, навыков;
- Скудность сведений, документации.
Разновидности багов
Первое, что делает тестировщик, обнаружив сбой – определяет, в какой области программы он нашел свой приют. При разработке приложений могут встречаться следующие ошибки:
- Видимые, относящиеся к интерфейсу (например, одна из кнопок действий оказалась вне видимости, где-то за экраном);
- Функциональные сбои. Могут характеризоваться неактивностью кнопок, повторное выполнение команд;
- «Просадка» при увеличении нагрузки. Если при искусственно созданном скачке трафика ресурс не справляется, зависает, перестает загружаться, то мы имеем дело с багом нагрузки;
- Нарушение в работоспособности. Производительность падает из-за объема приложения, потребляя много памяти, энергии;
- Логические ошибки – появляются, если айтишники что-то не учли, забыли. В результате программа может работать, но не удовлетворять требования пользователя.
Оценка серьезности и приоритета в баг-репортах
Для оформления баг-репортов важны эти оценочные понятия. Первый атрибут указывает, насколько сбой может повлиять на работу в приложении. Градация включает пять уровней, самый серьезный – наличие блокирующего бага (S1), при котором продукт не запускается вообще или выдает ошибки. Самый безобидный уровень (S5)– тривиальный, не влияющий на качество работы (например, несущественная опечатка).
Приоритет – своеобразная иерархия по скорости исправления дефектов, с учетом его опасности. Подразделяется на критерии:
- Высокий, требующий первостепенного внимания, исправления;
- Средний, подлежит исправлению, когда решили проблемы с первой позицией;
- Низкий – может подождать своей очереди.
В проектах атрибуты часто объединяют или предпочитают приоритет.
Чтобы правильно выстроить иерархию, некоторые команды содержат документ, указывающий какой, когда именно приоритет применять. В ином случае поможет опыт, согласованность в работе специалистов, так как важно понимание, что существеннее для данного продукта.
Шаблон баг-репорта
Отчеты могут иметь некоторые отличия, зависящие от компании, проекта, но позиции, которые должны быть обязательно:
| Наименование поля | Содержание |
|---|---|
| Описание (или Заголовок) | Емкая обрисовка проблемы |
| Путь воспроизведения | Перечисление действий, приводящих к местонахождению ошибки |
| Результат по факту | Картина после воспроизведения |
| Ожидания | Что ожидалось, как было запланировано в ТЗ |
| Место локализации | Где находилась ошибка |
| Дополнительные вложения | Скрины, png-файлы, логи |
| Доп. сведения | Это могут быть пояснения тестировщика |
| Исполнитель |
Правила форматирования баг-репорта
Создание полезного, понятного отчета требует опыта. Для начинающих рекомендуем заострить внимание на следующем:
- Создание заголовка. Он должен быть информативный, чтобы сразу высвечивал суть, не длинным, но понятным.
- Локализация. Важно убедиться, что найдет именно дефект, разобраться в чем заключается, чтобы не доставлять лишней работы разработчикам, если погрешность не имеет к ним отношения.
- Путь воспроизведения. Необходимо описывать те действия, которые непосредственно относятся к выявлению уязвимости, делать это понятно.
- Взгляд на ситуацию с точки зрения владельца, бизнеса. Например, кнопка сместилась в зону недоступную взгляду, как это отразиться на продажах. Это найдет свое отражение в оценке сбоя.
- Эффективное заполнение полей фактического, ожидаемого результатов. Если заполнение было неполным, некорректным, то это отнимет время, породит много уточняющих вопросов.
Частые ошибки в баг-репорте
Хотелось бы заострить внимание на проблемах, чаще всего встречающихся при оформлении баг-репорта:
- Непонятный, не четко сформулированный заголовок, из-за этого критичность проблемы может быть оценена неправильно.
- Не указаны цепочка действий для воспроизведения. Не исключено, что все вернется все назад.
- Претензия приписана не тому разработчику или находится в статусе «не назначен».
- Недостаточный объем предоставленных сведений.
- Отсутствие указаний на ожидаемый результат, сведений на полученную картину.
Рекомендации по заполнению баг-репорта
Желательно, чтобы специалисты придерживались общепринятых в среде правил:
- Необходимо делать максимально скрупулезное описание. Для этого будет мало одного предложения, требуется четкое указание последовательности предпринятых шагов, приводящих к выявлению промахов.
- Придерживаться принятого, понятного в окружении шаблона, не выдумывать свой вариант, так как специалисты привыкают к определенному формату. Если назрела необходимость ввода новых полей, стоит обсудить эту тему с руководством, ведущими специалистами.
- Перед тем, как давать описание, несколько раз воспроизведите баг, отметьте возможные условия появления, последовательность действий.
- Предоставляйте дополнительные сведения. Разработчикам помогут предоставленные скриншоты, если дефект виден без дополнительных действий, для погрешностей, выявленных в ходе работы, помогут скринкасты и т.д. Специалист, ознакомившись с ними, сможет быстрее разобраться в ситуации.
Выводы
Правильно оформленный баг-репорт увеличивает шансы на исправление его в ближайшее время. Устранение изъянов напрямую зависит от степени качественности информации, которая предоставляется разработчику. Если тестировщик не озаботится корректностью составления отчета, программист может отклонить дефект с пометкой «не воспроизводится».
