Локализация ошибки этап

Дефект (или баг)  — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы. Например: невозможно сохранить данные после заполнения анкеты.

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

Отказ (failure)  — отклонение компонента или системы от ожидаемого результата, выполнения, эксплуатации. Например: при переходе на следующую страницу анкеты данные предыдущей страницы затираются.

Классификация багов

• Функциональные дефекты  — в этом случае приложение функционально работает не так, как задумано. Например:

— не сохраняются изменения данных в профиле; 
— не работает добавление комментария; 
— не работает удаление товара из корзины; 
— не работает поиск. 

• Визуальные дефекты  — в этом случае  приложение выглядит не так, как задумано.

— текст вылезает за границы поля; 
— элемент управления сайтом наслаивается на нижестоящий элемент; 
— не отображается картинка. 

• Логические дефекты  — в этом случае приложение работает неправильно с точки зрения логики. 

— можно поставить дату рождения «из будущего», а также несуществующие даты — 31 февраля, 32 декабря и т.п.; 
— можно сделать заказ, не указав адрес доставки; 
— логика поиска работает неправильно. 

• Дефекты контента

— орфографические и пунктуационные ошибки; 
— картинка товара не соответствует карточке товара; 
— конвертация валют идет по неправильному курсу (калькулятор считает правильно, но при программировании указан неверный курс). 

• Дефекты удобства использования — в этом случае приложение неудобно в использовании. 

— отсутствие подсветки или уведомления об ошибке при некорректно заполненных полях формы;
— сброс всех данных при ошибке заполнения регистрационной формы; 
— перегруженный интерфейс. 

• Дефекты безопасности  — в этом случае могут быть затронуты пользовательские данные, есть риск падения системы и т.п. 

— можно получить логин, пароль в результате использования SQL-инъекций; 
— неограниченное время жизни сессии после авторизации.

Итак, мы рассмотрели типы и виды дефектов. Теперь расскажем о том, как их документировать.  

Документирование ошибок

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

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

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

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

Перепроверка дефекта

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

Локализация дефекта

Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:

• Выявить причины возникновения дефекта

Например, не проходит восстановление пароля. Необходимо выявить, откуда приходит запрос на сервер в неверном формате  — от backend либо frontend. 

• Проанализировать возможность влияния найденного дефекта на другие области

Например, в одной из форм, которую редко используют, возникает ошибка при нажатии на кнопку «Редактировать». Если в качестве временного варианта решения проблемы скрыть кнопку, это может повлиять на аналогичную форму в другом окне/вкладке, к которой пользователи обращаются чаще. Для качественного анализа необходимо знать, как работает приложение и какие зависимости могут быть между его частями. 

• Отклонение от ожидаемого результата

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

• Исследовать окружение

Необходимо воспроизвести баг в разных операционных системах (iOS, Android, Windows и т.д.) и браузерах (Google Chrome, Mozilla, Internet Explorer и др.). При этом нужно проверить требования к продукту, чтобы выяснить, какие системы должны поддерживаться. Некоторые приложения работают только в определенных ОС или браузерах, поэтому проверять другие варианты не нужно. 

• Проверить на разных устройствах

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

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

• Проверить в разных версиях ПО

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

• Проанализировать ресурсы системы

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

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

Фиксирование доказательств

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

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

Live-логирование – это снятие системных логов в режиме реального времени. Для этого можно использовать следующие программы: Fiddler, Visual Studio для Windows, iTools, Xcode для iOS, Android Debug Monitor, Android Studio для Android и др. 

• Скрин (снимок) экрана. При ошибках  в интерфейсе снимок помогает быстрее разобраться в проблеме. Программ для снятия скриншотов очень много, каждый QA-специалист может использовать те, которые ему наиболее удобны: Jing, ShareX, Lightshot и др. 
• Скринкаст (англ. screen – экран, broadcasting – трансляция) – это запись видеоизображения с экрана компьютера или другого цифрового устройства. Это один из самых эффективных способов поделиться тем, что происходит на экране монитора. Таким способом QA-специалисту легко наглядно показать ошибки в работе любого программного продукта. Сделать запись с экрана помогут незаменимые инструменты любого QA-специалиста: Snagit, Monosnap, Movavi Screen Capture, Jing, Reflector, ADB Shell Screenrecord, AZ Screen Recorder и др. 
• Рекордер действий. Программные средства дают возможность  воспроизвести все записанные движения мышки и действия, производимые на клавиатуре компьютера. Примеры программ – Advanced Key and Mouse Recorder для desktop-платформ.

Оформление баг-репорта

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

Дефект, который не задокументирован – не найден! 

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

Атрибуты баг-репорта:

1. Название

Баг должен быть описан кратко и ёмко, иметь понятное название. Это поможет разработчику разобраться в сути ошибки и в том, может ли он взять этот случай в работу, если занимается соответствующим разделом системы. Также это позволяет упростить подключение новых специалистов на проект, особенно если разработка ведется много лет подряд, а запоминать баги и отслеживать их в таск-трекере становится все сложнее. Название проекта можно составлять по принципу «Где? Что? Когда?» или «Что? Где? Когда?», в зависимости от внутренних правил команды. 

Например:

Где происходит?  — В карточке клиента (в каком разделе системы).

Что именно происходит?  — Не сохраняются данные.

Когда происходит?  — При сохранении изменений.

2. Проект (название проекта)

3. Компонент приложения

В какой части функциональности тестируемого продукта найден баг.

4. Номер версии

Версия продукта, ветка разработки, в которой воспроизводится ошибка.

5. Критичность

Этот атрибут показывает влияние дефекта на функциональность системы, например:

· Blocker  — дефект, блокирующий использование системы.

· Critical  — ошибка, которая нарушает основную бизнес-логику работы системы.

· Major  — ошибка, которая нарушает работу определенной функции, но не всей системы.

· Minor  —  незначительная ошибка, не нарушающая бизнес-логику приложения, например, ошибка пользовательского интерфейса.

· Trivial  — малозаметная, неочевидная ошибка. Это может быть опечатка, неправильная иконка и т.п.

6. Приоритет

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

High  — ошибка должна быть исправлена как можно скорее, является критичной для проекта.
Medium  — ошибка должна быть исправлена, но её наличие не является критичным для проекта.
Low  — ошибка должна быть исправлена, но не требует срочного решения.

7. Статус

Статус указывает стадию жизненного цикла бага, взят он в работу или уже решен. Примеры: to do, in progress, in testing (on QA), done. В зависимости от особенностей проекта возможны дополнительные статусы (например, аналитика).

8. Автор баг-репорта

9. На кого назначен

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

10. Окружение

Где найден баг: операционная система, наименование и версия браузера. 

11. Предусловие (если необходимо)

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

12. Шаги воспроизведения

Один из самых важных атрибутов  — описание шагов, которые привели к нахождению бага. Оптимально использовать 5-7 понятных и кратких шагов для описания бага, например:
1. Открыть (…)
2. Кликнуть (…)
3. Ввести в поле А значение N1
4. Ввести в поле B значение N2
5. Кликнуть кнопку «Calculate»

13. Фактический результат

Что произошло после воспроизведения указанных выше шагов.

14. Ожидаемый результат

Что должно произойти после воспроизведения шагов тестирования, согласно требованиям.

15. Прикрепленный файл

Логи, скриншоты, видеозапись экрана  — всё, что поможет разработчику понять суть ошибки и исправить ее.

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

Локализация и оформление багов  — необходимые составляющие работы QA-специалиста с программным продуктом. Приглашаем подробнее ознакомиться с услугами тестирования и обеспечения качества в SimbirSoft.