Как правильно сообщать о багах в ПО?

Перевод статьи «The Art of Bug Reporting: How to Market and Get Your Bugs Fixed?».

Первое, что приходит мне на ум, когда я начинаю писать эту статью, это слова Сэма Канера: “Лучший тестировщик – это не тот, кто находит больше всего ошибок. Лучший тестировщик – тот, кто исправляет больше всего багов”.

Итак – в чем разница между нахождением наибольшего количества ошибок и их исправлением?

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

Приоритет ошибки, на мой взгляд, во многом зависит от того, как тестировщик представит проблему команде разработчиков и руководству.

Думайте об этом как о рекламе или маркетинге проблемы – это включает в себя 2 шага:

БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"

• Правильно написать или сообщить об ошибке.
• Знать все об ошибке, чтобы можно было лучше объяснить любые дополнительные детали.

Содержание:

• Искусство составления баг-репорта
• Эффективное участие в совещаниях
• Последствия неправильной презентации бага
• Заключение

Искусство составления баг-репорта

Да, составление баг-репорта – это искусство. То, как он написан, показывает технические навыки, опыт в области тестирования и коммуникативные способности QA-инженера.

Как правило, сообщение об ошибке должно содержать следующую информацию:

• Краткое описание ошибки
• Шаги для воспроизведения
• Приложения (снимки, файлы журналов и т.д.).
• Воспроизводимость ошибки
• Степень серьезности ошибки
• Версия программного обеспечения, информация о среде
• Другая информация в соответствии с требованиями организации.

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

1. Учетные данные не подтверждены.
2. Проблемы с network timeout.
3. Система не учитывает разницу между заглавными (CAPS) и строчными (не-CAPS) буквами.

Теперь давайте рассмотрим каждый пункт баг-репорта и обсудим важные аспекты каждого из них:

1. Краткое описание ошибки

Краткое описание ошибки должно давать четкое понимание того, в чем именно заключается проблема. Оно должно быть точным и понятным.

Пример:

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

“Новый пользователь не может войти в систему”

“Вход в систему не работает так, как ожидалось”

“Пользователь не может войти в систему с правильным паролем”.

Можете ли вы выбрать из приведенных выше примеров одно утверждение, которое действительно описывает проблему? Я так не думаю. Описание всегда должно давать полную информацию о проблеме.

Рассмотрим следующее утверждение:

“Новый пользователь не может войти в систему с паролем, предоставленным по электронной почте или SMS”.

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

Поэтому постарайтесь найти правильные слова для описания проблемы, которые бы прямо и понятно передавали информацию. Следует избегать общих утверждений типа “не работает должным образом”, “работает не так, как ожидалось” и т.д.

2. Шаги по воспроизведению проблемы

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

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

Рассмотрим ту же проблему, о которой говорилось в предыдущем пункте:

1. Создайте нового пользователя, используя опцию Sign Up на главной странице. (Пример имени пользователя: HelloUser).
2. Вы получите электронное письмо и SMS с паролем по умолчанию. Электронная почта и номер мобильного телефона для SMS указываются при создании аккаунта в Шаге #1. (пример e-mail: HelloUser@hello.com, пример номера мобильного телефона: 444-222-1123)
3. Выберите опцию Login на главной странице.
4. В текстовом поле имени пользователя введите имя пользователя, указанное в шаге №1.
5. В поле с паролем введите пароль по умолчанию, полученный по электронной почте или SMS.
6. Нажмите на кнопку Войти.
7. Ожидаемый результат: Пользователь должен иметь возможность войти в систему с указанным именем пользователя и паролем и перейти на страницу своей учетной записи.
8. Фактический результат: Отображается сообщение “Неверное имя пользователя / пароль”.

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

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

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

3. Воспроизводимость ошибок

Независимо от того, проблема маленькая или большая, ее приоритет будет зависеть от воспроизводимости. Это означает, что проблема может проявляться всегда, иногда, редко или только один раз. Проблема, которая воспроизводится “всегда”, будет приоритетнее остальных.

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

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

4. Серьезность ошибки

Серьезность ошибки, несомненно, является одним из самых больших факторов, влияющих на определение приоритетности ошибки.

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

1. Show Stopper – для ошибок, которые являются катастрофическими, без их устранения пользователь не сможет продолжать использовать программное обеспечение, и нет никакого возможного обходного пути.
2. High – для ошибок, аналогичных Show Stopper, но есть обходной путь.
3. Medium
4. Low
5. Trivial

Теперь давайте сравним две похожие проблемы:

В цифровых приставках лишь немногие поставщики услуг предоставляют информацию о частоте текущего канала. Предположим, что частота отображается как 100 МГц вместо 100,20 МГц. Это может не повлиять на просмотр канала пользователем, но может повлиять на диагностику приставки. Следовательно, это проблема уровня Medium.

Предположим аналогичную проблему в банковской сфере: Если баланс вашего счета отображается как $100, а не $100.20, представьте себе последствия этой проблемы. Это будет проблема уровня 1 -Show Stopper. Как вы видите, в обоих случаях проблема очень похожа – пользовательский интерфейс не отображает цифры после запятой. Но последствия различаются в зависимости от конкретной сферы, в которой это происходит.

Эффективное участие в совещаниях

Обычно каждая организация имеет свой собственный процесс исследования и определения приоритетов ошибок. Как правило, через определенные промежутки времени в ходе проекта проводится собрание для обсуждения ошибок и определения их приоритетности.

Процесс проведения таких совещаний выглядит следующим образом:

1. Запросить список багов из системы отслеживания ошибок в соответствии со степенью их серьезности.
2. Просмотреть описание бага и обсудить его влияние на user experience.
3. На основании оценки рисков установить приоритет бага и поручить исправление ошибки соответствующему разработчику.

Рассмотрим вышеприведенный пример с проблемой отсутствия отображения цифр после запятой в банковской сфере. Разработчику эта проблема может показаться менее серьезной. Он может возразить, что вместо объявления переменной как integer, он объявит ее как float, что решит проблему и, следовательно, сделает ее менее серьезной.

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

Последствия неправильной презентации бага

Если неправильно преподнести найденную ошибку в приложении, то могут возникнуть такие проблемы, как:

• Неправильный приоритет дефектов
• Задержка в исправлении важных проблем
• Выпуск продукта с серьезными дефектами
• Негативные отзывы клиентов

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

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

Заключение

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

Давайте действовать и исправлять ошибки прямо сейчас!