Составление документации по результатам проведения тестов QA-инженером, является существенной долей его работы. Один из них – отчёт о дефекте, иначе называемый отчёт об ошибке или баг-репорт. Такой отчёт предусмотрен для любого продукта в процессе его тестирования: сайт интернет-магазина, ПО банковского учреждения, компьютерная игра и прочее. С точки зрения специалистов, существует следующая классификация дефектов: неверное кодирование, ошибки в проектировании, несоответствие техзаданию, необходимость доработки аппаратной части ПК, предложения по усовершенствованию.
Можно найти несколько систем для выявления дефектов в тестировании. Самые популярные из них:
- Jira – это самый популярный ресурс, дающий возможность следить за жизненным циклом и фиксировать ошибки, для ее использования в работе необходимо внимательно изучить ее функционал и пройти практику под руководством опытного наставника;
- Redmine – интернет-приложение с широким функционалом, в том числе позволяет отслеживать ошибки;
- Mantis – система контроля ошибок в ПО с гибкими настройками, даёт возможность разработчикам отслеживать процесс работы и после завершения этапа тестирования, распространяется свободно, не требует установки, работает через интернет-браузер.
Различные специалисты отдают предпочтение различным подходам к баг-тестированию. Файл отчетаотестировании может содержать достаточно большой объем технической информации, но есть определенный перечень обязательных данных.
Что содержит отчёт о тестировании?
В общем виде отчет о дефекте даёт возможность тестировщику разобраться:
- что именно пошло не так;
- в каких процессах проявляются ошибки;
- в какой момент ошибка происходит.
На основании такой информации разработчики будут исправлять программный код для того, чтобы в дальнейшем ошибка не возникала. Здесь нужен необходимый минимум информации, изложенной просто и понятно, с максимумом подробностей.
Источниками информации для баг-репорта будут не только результаты тестирования, но и сообщения заказчика и других пользователей. Оптимально, если все ошибки будут найдены до запуска в эксплуатацию, но чаще всего приходится учитывать опыт взаимодействия с программой уже в процессе тестирования на стороне клиента.
Для наиболее полного и понятного отражения недостатков, следует придерживаться следующих правил:
- одна ошибка – один отчёт, это позволит оперативно отслеживать и исправлять недочёты;
- отчёт об ошибке пользователь должен писать коротко, но понятно, чтобы разработчик понял, в чем проблема;
- необходимо включить максимум полезной информации;
- убедитесь, что ошибка повторяется, запомните точный алгоритм действий, который ее вызывает;
- убедитесь, что ранее не направлялся отчёт о подобном дефекте.
Только в этом случае описание будет правильно понято специалистом и приведет к желаемому результату. Как составить безупречный баг-репорт? Рассмотрим этот вопрос в следующем разделе.
Атрибуты баг-репорта
Количество полей отчёта может отличаться в каждой из систем отслеживания. В любом случае, основными атрибутами отчета о дефекте будут следующие (отдельные поля могут иметь ограничения по количеству символов):
- заголовок (summary) – краткое изложение сути обнаруженного дефекта (это ответы на вопросы: что, где и когда произошло в одном предложении);
- описание (description) – описание алгоритма возникновения ошибки, в отдельных системах, в частности в вышеупомянутом Mantis, есть возможность дать развернутые пояснения (кроме описания последовательности действий добавить условия появления дефекта и прочее);
- ожидаемый и фактический результат (expected and actual result) – необходимо описать, что конкретно хотел получить пользователь и что он получил на выходе;
- вложения (аttachments) – это может быть любой файл, позволяющий наглядно показать, в чем проблема: скриншот сообщения об ошибке, фотография экрана любым имеющимся под рукой гаджетом, видеозапись или любой другой документ;
- приоритет (priority) – срочность поставленной задачи, чем он выше, тем важнее сделать задачу в максимально короткие сроки: high/высокий, medium/средний или low/низкий (высокий ставят тем задачам, которые критически сказываются на работе ПО, а низкий – когда ошибки не оказывают существенного влияние на выполнение основных функций);
- серьёзность (severity) – уровень влияния на работоспособность всего программного комплекса: blocker — полностью останавливают работу приложения, critical — серьезная ошибка, не приводящая к блокировке, major – важный дефект, не препятствующий выполнению поставленных перед ПО задач, но ведущий к ошибкам в данных или выполняемых функциях, minor — несущественные ошибки, сказывающиеся на визуальном отображении результата или в тексте;
- статус (status) – этап тестирования: new – новая ошибка, feedback – необходима обратная связь, acknowledged –документ принят в работу, accepted – ошибка подтверждена, assigned – ведется работа по исправлению, resolved – исправления внесены, closed – ошибка более не возникает.
Это основные поля отчета об ошибках. Но в разных системах для тестирования могут встречаться и другие: ОС или платформа (environment/platform), версия ПО (fix version), классификация ошибки (lable) и другие.
Что является обязательным в отчёте о дефекте?
Правильно заполненные атрибуты багрепорта – это важнейшая часть процесса устранения ошибок. Целесообразно заполнять все поля формы и это является важным навыком тестировщика. Преподаватели учебного центра «Планета тестирования» помогут вам разобраться во всех нюансах. Что особенно важно в современных условиях – обучение проходит в дистанционном формате на курсах по тестированию программного обеспечения.
С одной стороны его задача — быть простым и понятным, а с другой стороны — быть эффективным.
Важно, чтобы программист при изучении данного отчета мог с легкостью воспроизвести описанный баг и понять ход мыслей тестировщика.
Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
1. Заголовок ошибки
2. Описание ошибки
3. Начальные условия
4. Шаги воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. Вложения
В зависимости от ситуации или компании, в которой вы работаете, шаблон может изменяться и отклоняться в разные стороны. Например, в некоторых случаях «Начальные условия» не пишут. Если дефект связан с графикой, то рекомендуется добавить скриншот. Также вводятся дополнительные атрибуты для указания Платформы или Барузера и т.д.
Теперь рассмотрим структуру шаблона подробно на конкретном примере. Допустим, мы тестируем сайт. На сайт есть раздел Контакты. В этом разделе находится Форма обратной связи.
После заполнения всех полей мы нажимаем на кнопку «Отправить сообщение» и ничего не происходит.
Данный баг мы и будем описывать по шаблону.
Заголовок ошибки (Title)
По сути это краткое описание найденной ошибки. Его задача — в понятной и простой форме передать смысл найденной ошибки.
Наиболее эффективным описанием считается описание, которое отвечает на три вопроса:
— Что произошло?
— Где появилась ошибка?
— Когда или при каких условиях найден дефект?
Также важно, чтобы заголовок был именно кратким, т.е. он должен содержать максимально полную и, в то же время, краткую информацию об ошибке.
Заголовок ошибки — это первое, что видит разработчик, получая отчет. В некоторых случаях, при правильном оформлении, этого бывает достаточно, чтобы понять в чем заключается дефект и как его исправить.
Пример плохого заголовка: Ошибка, когда нажимаю «Отправить сообщение».
Пример хорошего заголовка: При нажатии на кнопку «Отправить сообщение» в форме обратной связи сообщение не отправляется.
Описание ошибки (Summary)
Попробуйте в паре предложений описать суть дефекта, а также когда он появляется и в чем выражен.
Правильное и качественное описание также позволяет сразу понять проблему и приступить к ее исправлению.
Пример плохого описания: Жму «Отправить сообщение», а в ответ тишина.
Пример хорошего описания: При нажатии на кнопку «Отправить сообщение» в заполненной форме обратной связи ничего не происходит. Аналогичное поведение, если форма не заполнена.
Начальные условия (Precondition)
В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:
1. Быть авторизованным в системе.
2. Находиться на главной странице.
Пример плохих начальных условий: Находиться на сайте.
Пример хороших начальных условий:
1. Страница «Контакты»,
2. Платформа и устройство не имеют значения.
Шаги воспроизведения (Steps To Reproduce)
Шаги, при которых повторяется найденная ошибка. Например:
1. Нажать на кнопку “Войти”
2. Ввести “Имя пользователя” и “Пароль”
3. Нажать на кнопку “Ок”
Убедитесь, что у вас нет лишних или ненужных шагов воспроизведения, которые будут отвлекать и тратить время команды.
Пример плохих шагов: 1. Зайти на сайт, 2. Зайти на страницу обратной связи, 3. Поставить курсор в поле Имя, 4. Ввести имя, 5. Поставить курсор в поле e-mail, 6. Ввести действующий e-mail, 7. Навести курсор на Отправить сообщение, 8. Щелкнуть по Отправить сообщение.
Пример хороших шагов:
1. Заполнить поля формы обратной связи,
2. Нажать на копку «Отправить сообщение»
Ожидаемый результат (Expected Result)
Результат, который должен быть при выполнении шагов. В идеале, его можно найти в ТЗ (техническом задании). На практике, ТЗ бывает не всегда и ожидаемый результат определяется либо здравым смыслом, либо по аналогии.
Пример плохого ожидаемого результата: Что-то должно произойти.
Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.
Фактический результат (Actual Result)
Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.
Пример плохого фактического результата: Ничего нет.
Пример хорошего фактического результата: Сообщение не отправляется, не появляется ошибка об отправке. После нажатия на кнопку ничего не происходит.
Вложения (Attachments)
При необходимости тестировщики прикладывают скриншоты или видео воспроизведения ошибки. Также могут прикладывать логи выполнения программы.
________________________________
При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.
________________________________
В следующей статье мы разберем такие атрибуты баг-репорта, как Приоритет и Серьезность дефекта.
Что такое отчет баг-репорт (отчет о дефекте). Пример.
Один из основных документов тестировщика – это отчет о дефекте (баг-репорт). Это инструмент, чтобы зафиксировать найденные ошибки ПО. С помощью отчета о дефекте разработчикам передается информация о найденных багах.
Тестировщик в своей работе использует разные инструменты и документы. Среди них стратегия тестирования, тест-план, чек-лист, тест-кейс, отчеты о тестировании и другие. В этой статье мы рассмотрим баг-репорт (отчет о дефекте).
Для чего служит отчет о дефекте (баг-репорт)
Отчет о дефекте (defect report, bug report) – это документ, содержащий отчет о любом недостатке в программном обеспечении, системе или ее компоненте. При этом такой недостаток может привести программу к невозможности выполнить требуемую функцию.
Баг-репорт выполняет несколько функций.
- В нем записывается очень ценная информация для тестирования – найденные дефекты программного обеспечения.
- Его используют разработчики для исправления найденных ошибок.
- Совокупность таких отчетов – исходные данные для отчета о тестировании.
- На основе баг-репорта можно создавать тест-кейсы, чтобы потом проверить устранение ошибок в ПО и его дальнейшее корректное функционирование при обновлении версий.
- Отчеты о дефектах можно использовать в разных видах тестирования для совершенствования продукта.
Главные потребители отчета о дефекте – программисты. Баг-репорт дает им важные данные для дальнейшей работы.
Пример отчета о дефекте
| ID дефекта: | 001 |
Заголовок: |
Вход на сайт при авторизации с некорректным е-мейлом в качестве логина. |
| Предусловия: | Нет. |
| Шаги для воспроизведения: |
|
Фактический результат: |
На экране – страница меню для выбора выгружаемых данных. |
Ожидаемый результат: |
На экране – сообщение «Ошибка авторизации. Введите корректный е-мейл». |
| Приложения: | Скриншот захода на страницу меню для выбора выгружаемых данных без авторизации. |
Атрибуты отчета о дефекте
Выделяют следующие основные атрибуты (поля) тест-кейсов:
- ID (уникальный идентификатор) — номер найденного бага.
- Заголовок (краткое описание) — лаконичное и однозначно понятное описание дефекта.
- Предусловие (входные данные): То, в какое состояние нужно привести ПО, чтобы воспроизвести баг (например, закрыть открыть определенные модули или зайти в специальный раздел сайта).
- Шаги для воспроизведения — какие действия нужно произвести, чтобы данный баг появился.
- Фактический результат — что тестировщик увидел на экране после завершения шагов.
- Ожидаемый результат — что тестировщик должен был получить на экране после завершения шагов согласно требованиям к ПО.
- Приложения – скриншоты и другие файлы, которые могут помочь разработчикам в устранении бага
Также могут быть и другие атрибуты (в зависимости от специфики проекта), например:
- Тестовое окружение — на каком устройстве, под какой операционной системой и в какой версии программы/браузера баг был обнаружен.
- Ссылка на требование к ПО – какое именно требование нарушается багом.
- Серьезность бага – насколько серьезно дефект «ломает» ПО.
- Приоритет бага – насколько срочно надо устранить дефект.
- Назначенный исполнитель – кому поручили исправить дефект.
- Статус – в каком состоянии находится работа по исправлению дефекта (например, «дефект выявлен», «в работе», «готово для проверки», «дефект устранен»).
Как составит отчет о дефекте
Чтобы составить баг-репорт, надо заполнить все его необходимые атрибуты. Важно следовать следующим принципам:
- Перед созданием – убедиться, что дефект воспроизводится (вызвать его еще раз)
- Проверить, что ранее такого дефекта не выявили
- Один дефект – один баг-репорт
- Аккуратное и точное написание – понятен каждому члену команды
- Заголовок лучше писать по схеме «Что? Где? Когда?»
- Вся нужная информация о баге прилагается
Часто задаваемые вопросы про баг-репорт
Да, это один из основных QA-инструментов. Вы можете записаться в любую понравившуюся онлайн-школу тестировщиков и попрактиковаться в этом и других инструментах.
Баг-репорт — это отчет об ошибке. Его делают при нахождении ошибки.
Тест-кейс – это пошаговое описание действий, которые нужно произвести для проверки какой-либо функции ПО. Если в ходе выполнения тест-кейса найдена ошибка, то ее описывают в баг-репорте. И обратно, на основе баг-репорта можно сделать тест-кейс для другого тестирования.
Чек-лист — это упрощенный список того, что нужно проверить. Если при его выполнении выявлен баг, то его как раз описывают в отчете о дефекте.
Автор Михаил Кулешов
Михаил, профессиональный партнерский маркетолог, является основателем компании South Media OÜ, которая была создана в 2018 году и базируется в Таллинне. С 2016 года Михаил уехал из Финляндии и жил как настоящий «цифровой кочевник» в IT-индустрии, путешествуя по миру только с ноутбуком. Михаил работает и пишет статьи, связанные с IT-индустрией.
Сфера тестирования приложений и различных продуктов довольно многогранная и сложная. Ведь главной задачей тестировщика является всестороннее изучение продукта, особенностей его работы на разных операционных системах, смартфонах, ПК, планшетах, лэптопах, а также составление отчетной документации, в рамках которой специалисту необходимо отметить все выявленные проблемы и баги системы. И одним из таких частей отчетности является баг репорт.
Баг репорт, или отчет об ошибке играет важную роль в процессе тестирования программного обеспечения. Это документ, который позволяет тестировщикам записать и передать информацию о обнаруженных дефектах разработчикам, чтобы те могли их исправить. В данной статье мы рассмотрим, что такое баг репорт и тест кейс, как его оформлять, а также приведем пример баг репорта и шаблоны для удобства тестирования.
Что мы рассмотрим:
Баг репорт — что это. Определение понятия
Баг репорт — это специализированный шаблонный документ, в котором тестировщик фиксирует все детали об ошибке или дефекте, обнаруженном в программном продукте во время тестирования. Баг репорт охватывает все стороны исследуемого ПО и может включать в себя информацию о проблемах с функциональностью, интерфейсом, производительностью или другими аспектами новой программы или софта. Качественно оформленные баг репорты является ключевым элементом для эффективной коммуникации между тестировщиками и разработчиками.
В свою очередь, баг репорты могут разделятся на различные виды, а также иметь специализированные атрибуты, которые мы рассмотрим далее.
Оформление баг репорта и самые распространенные виды багов
Правильное оформление баг репорта позволяет детально описать все виды багов, которые могут возникать в процессе тестирования. К основным типам багов относятся: функциональные, визуальные, баги нагрузки, баги производительности, безопасности, логические баги и прочие виды ошибок, которые могут выдавать сайты и приложения.
Оформление баг репорта включает четкие заголовки и структурированный текст для легкости чтения. Применение списков и выделение ключевых моментов помогает сделать отчет более понятным и информативным. Важно также прикрепить скриншоты, видео или другие дополнительные материалы, которые могут помочь разработчикам быстрее понять и исправить проблему.
Важно учесть, что видов баг репортов, как и самих багов, может быть довольно много. Они позволяют специалистам команды обмениваться между собой информацией без ущерба во времени или потери качества передаваемой информации. Если компания привлекает тестировщика “со стороны”, то, как правило, отдел разработки предоставляет ему уже готовый баг репорт-шаблон.
Атрибуты баг репорта
Каждый выявленный баг специалист должен классифицировать по двум параметрам (атрибутам): серьезности и приоритетности. Давайте определим главные атрибуты баг репорта, которые необходимо отмечать в документе:
1.Серьезность бага — показывает уровень опасности ошибки для системы. Серьезность багов также имеет свою классификацию, где показатель S0 (Trivial) означает лишь небольшую ошибку, которая устраняется быстро, а S4 (Blocker) подразумевает под собой серьезный баг, который полностью блокирует систему софта, не давая ему работать.
Также выделяют уровни S1 (Minor), S2 (Major), S3 (Critical). Каждый из них так или иначе накладывает отпечаток на уровне и качестве функционирования продукта.
2. Приоритетность решения (устранения) бага. Данный показатель разделяется на три уровня приоритетности: High, Medium, Low.
Шаблон баг репорта
При правильно настроенной системе тестирования в компании специалист-тестировщик имеет стандартный баг репорт-шаблон, который заполняется по примеру прошлых тестирований. Если же готового шаблона нет, мы предлагает ознакомиться с таким вариантом баг репорт-шаблона, который должен включать в себя следующие пункты:
- Название: Краткое и понятное описание проблемы;
- Описание: Подробное описание обнаруженной ошибки;
- Ожидаемое поведение: Что ожидается увидеть в результате;
- Фактическое поведение: Что фактически наблюдается в программе;
- Шаги воспроизведения: Здесь важно прописать шаги для обнаружения бага разработчиком;
- Приоритет и серьезность: Уровень важности проблемы.
- Окружение: Операционная система, браузер (или другие среды), на которых обнаружена ошибка.
Давайте теперь рассмотрим краткий пример баг репорта.
Пример баг репорта от тестировщика
Перед тем, как представить пример баг репорта, отметим, что шаблонов, как и способов их заполнения, существует довольно много. Поэтому тестировщику важно отталкиваться от своих личных предпочтений и удобства их использования.
Пример заполнения баг репорта
1. Название: Некорректное отображение имени пользователя в профиле.
2. Описание:
- Зайти в аккаунт пользователя;
- Перейти на страницу профиля;
- Обратить внимание на поле «Имя пользователя»;
- Отметить, что вместо имени отображаются случайные символы (см. скриншот во вложении).
3.Ожидаемое поведение: Поле «Имя пользователя» должно содержать имя пользователя, введенное при регистрации.
4. Фактическое поведение: Поле «Имя пользователя» отображает непонятные символы (см. скриншот).
5. Шаги воспроизведения: 100%.
6. Приоритет: Высокий.
7. Серьезность: Средняя.
8. Окружение:
- ОС: Windows 10
- Браузер: Google Chrome версии 91.0.4472.124 (64-бит)
- Аккаунт: тестовый пользователь
Баг репорт и тест кейс: их важность в работе тестировщика
Профессиональное тестирование может включать в себя множество этапов и видов, среди которых главными являются баг репорт и тест кейс. Тест кейс необходим для детализации всех этапов проведения проверки, а баг репорт затрагивает конкретные выявленные проблемы, включает в себя атрибуты баг репорта и различные рекомендации относительно разрешения возникшей неполадки.
Баг репорт и Тест кейс — два важных инструмента для работы тестировщика. В Тест кейсах описываются шаги для проверки функциональности, тогда как баг репорт выделяет неполадки и ошибки. Обе этих составляющих дополняют друг друга, обеспечивая высокое качество и эффективность процесса тестирования.
Баг репорт — пример высокой квалификации специалиста
Баг репорты являются важным инструментом в тестировании программного обеспечения. Правильное оформление баг репорта показывает уровень квалификации специалиста, а также позволяет тестировщикам передавать информацию о дефектах разработчикам и обеспечивает более быструю и качественную работу над исправлением проблем. Отчеты по выявлению багов должны быть структурированы и содержать достаточно информации для понимания проблемы и ее воспроизведения.
Пройдя обучающий курс в школе Test Pro, Вы также сможете легко и быстро составлять баг репорты, классифицировать их, присваивая уровень приоритетности и серьезности, а также стать более эффективным и продуктивным сотрудником любой команды разработчиков или тестировщиков.
Часто задаваемые вопросы
Наш баг репорт-пример является универсальным. Однако следует учесть, что в зависимости от типа продукта Вам может понадобиться внесение новых пунктов в список.
Все зависит от уровня квалификации самого специалиста. В среднем на оформление баг репорта уходит не более 30 минут.
Конечно. Мы уделяем отдельное внимание оформлению всей технической документации и отчетности тестировщиками.
1. Лекция 7 Поиск и документирование дефектов
Каленик Кристина Геннадьевна
кафедра ПОСТ, ауд. 121
2. Определения бага
1. «Быстрое тестирование» (Роберт Калбертсон, Крис Браун,
Гэри Кобб): «Программная ошибка – ни что иное, как изъян
в разработке программного продукта, который вызывает
несоответствие ожидаемых результатов выполнения
программного продукта и фактически полученных
результатов.»
2. «Тестирование Дот Ком, или Пособие по жестокому
обращению с багами в интернет-стартапах» (Роман Савин):
«Итак, баг (bug) – это отклонение фактического результата
(actual result) от ожидаемого результата (expected result). В
соответствии с законом исключённого третьего у нас есть баг
при наличии любого фактического результата, отличного от
ожидаемого.»
3. Определения бага
3. Википедия. «В целом, разработчики различают дефекты
программного обеспечения и сбои. В случае сбоя
программа ведёт себя не так, как ожидает пользователь.
Дефект – это ошибка/неточность, которая может быть (а
может и не быть) следствием сбоя.»
4. Сергей Мартыненко (блог «255 ступеней»). «Дефект –
поведение программы, затрудняющее или делающее
невозможным достижение целей пользователя или
удовлетворение интересов участников. Подразумевает
возможность исправления. При невозможности
исправления переходит в разряд ограничения
технологии.»
4. Определения бага
Дефект – это несоответствие требованиям или
функциональным спецификациям.
К багам относится любое некорректное поведение
программы, не соответствующее оправданным ожиданиям
пользователя, даже в том случае, если это поведение не
документировано в требованиях и спецификациях.
Баги могут встречаться в любой документации, в
архитектуре и дизайне, в коде программы и т.д.
Иногда баг на самом деле является не ошибкой в программе,
а результатом неверного конфигурирования программы
и/или окружения.
5. Документирование багов
Кто может задокументировать баг?
Тестировщики и специалисты по обеспечению
качества
Разработчики
Представители службы технической поддержки
Продавцы и специалисты по маркетингу
Представители заказчика
Конечные пользователи
6. Отчёт об ошибке
Технический документ, написанный с целью:
предоставить информацию о проблеме, ей свойствах и
последствиях;
приоритизировать проблему по важности и скорости
устранения;
помочь программистам обнаружить и и устранить источник
проблемы.
Отчёт об ошибке («баг-репорт», «bug report») – один из
основных результатов работы тестировщиков, который видят
коллеги (другие тестировщики и люди, не входящие в команду
тестировщиков).
7. Основная цель написания отчёта об ошибке – устранение ошибки.
Основная цель написания отчёта об
ошибке – устранение ошибки.
Хороший тестировщик – тот, по чьим отчётам (вне
зависимости от их количества) было исправлено
большое количество ошибок.
Вы ставите чайник на плиту, включаете над ней
подсветку, но света нет. Как сообщить ему о
проблеме?
«Поменяй лампочку на кухне»?
«Там эта штука не светит»?
8. Формула совершенного баг-репорта
состоит из трёх простых пунктов:
Что мы сделали (steps required to reproduce the
problem).
Что мы получили (actual results).
Что мы ожидали получить (expected results).
Кроме того, нужно сообщить, где именно произошла
проблема, при каких условиях, а также дать ошибке
название.
9.
10. Жизненный цикл дефекта
Обнаружен (submitted). Итак, тестировщик
находит дефект и представляет его на рассмотрение в
систему управления дефектами. С этого момента баг
начинает свою официальную жизнь и о его
существовании знают необходимые люди.
Назначен (assigned). Далее ведущий разработчик
рассматривает дефект и назначает его исправление
кому-то из команды разработчиков.
Исправлен (fixed). Разработчик, которому было
назначено исправление дефекта, исправляет его и
сообщает о том, что задание выполнено.
11. Жизненный цикл дефекта
Проверен (verified). Тестировщик, который обнаружил
ошибку проверяет на новом билде (в котором исправление
данной ошибки заявлено), исправлен ли дефект на самом деле.
И только в том случае, если ошибка не проявится на новом
билде, тестировщик меняет статус бага на Verified.
Открыт заново (reopened). Если баг проявляется на новом
билде, тестировщик снова открывает этот дефект. Баг
приобретает статус Reopened.
Отклонён (declined). Баг может быть отклонён. Во-первых,
потому, что для заказчика какие-то ошибки перестают быть
актуальными. Во-вторых, это может случится по вине
тестировщика из-за плохого знания продукта, требований
(дефекта на самом деле нет).
12. Жизненный цикл дефекта
Отложен (deferred). Если исправление конкретного
бага сейчас не очень важно или заказчик пока думает,
или мы ждём какую-то информацию, от которой зависит
исправление бага, тогда баг приобретает статус Deferred.
Закрытые (closed) баги. Закрытым считается баг в
состояниях Проверен (verified) и Отклонён (declined).
Открытые (open) баги. Открытыми являются баги в
состояниях Обнаружен (submitted), Назначен (assigned),
Открыт заново (reopened). Иногда к открытым относят и
баги в состояниях Исправлен (fixed) и Отложен
(deferred).
13. Атрибуты отчета об ошибках
Основные атрибуты:
– Идентификатор (id)
– Краткое описание (summary)
– Подробное описание (description)
– Шаги воспроизведения (steps to reproduce, STR)
– Воспроизводимость (reproducible)
– Важность (severity)
– Срочность (priority)
– Симптом (symptom)
Дополнительные (необязательные) атрибуты:
– Возможность «обойти баг» (workaround)
– Дополнительная информация (additional information)
– Приложения («аттачи») (attachments)
14. Идентификатор (id)
У каждого отчёта об ошибке должен быть
уникальный идентификатор.
Как правило, системы управления ошибками (bug
tracking systems) позволяют формировать
идентификатор в виде некоторого шаблона,
например:
Аббревиатура проекта + дата + порядковый
15. Краткое описание (summary)
Краткое описание бага – это суть, главные смысл проблемы.
Хорошее краткое описание должно давать ответы на три вопроса:
Что? Где? При каких условиях?
Например:
«Отсутствует логотип на странице приветствия, если пользователь является
администратором».
«Невозможно открыть файл с именем длиннее 500 символов».
Не всегда ошибка такова, что для неё дать ответ на все три вопроса. Тогда ответ даётся на
те вопросы, на которые его можно дать.
Краткое описание иногда предваряется префиксом, указывающим область работы с
приложением, для которой актуален баг.
Например:
[EN] «Опечатка в сообщении о неверном логине/пароле на странице авторизации
пользователей» – баг актуален для английской версии ПО.
[Opera] «Ошибка JavaScript при просмотре личных сообщений в профиле пользователя»
– ошибка возникает только в браузере Opera.
16. Подробное описание (description)
Хорошее подробное описание содержит необходимую информацию
об ошибке, а также (обязательно!) описание ожидаемого результата,
актуального результата и ссылку на требование (если это возможно).
Например:
«Если в систему входит администратор, в окне приветствия
отсутствует логотип.
Ожидаемый результат: логотип присутствует в левом верхнем углу
страницы.
Фактический результат: логотип отсутствует. Требование: R245.3.23b»
Если баг возникает в каких-то специфических условиях, их также
следует здесь перечислить. Если баг является неочевидным, здесь
следует привести аргументы – почему вы считаете такое состояние
или поведение программы багом.
17. Шаги воспроизведения (steps to reproduce, STR)
Несколько рекомендаций:
Описывайте каждый шаг, пока не столкнётесь с дефектом.
Найдите точный путь, чтобы воспроизвести дефект.
Попытайтесь найти кратчайший путь.
Повторите все описанные шаги несколько раз и убедитесь, что всё верно.
Описывайте каждое действие, которой вы делаете, в отдельном шаге.
Последний шаг: «Возникает ошибка <предельно сжатое описание ошибки>».
Пример:
1. Перейти по ссылке: http://www.site.com/login/
2. Ввести в поле «Логин» значение «admin».
3. Ввести в поле «Пароль» значение «admpwd».
4. Кликнуть по кнопке «Войти».
5. Баг: в левом верхнем углу вместо логотипа – пустое место.
18. Воспроизводимость (reproducible)
Это поле показывает, воспроизводится ли баг всегда
(«always») или лишь иногда («sometimes»).
Рекомендация: пройдитесь по своим шагам
воспроизведения хотя бы 2-3 раза прежде, чем писать, что
баг воспроизводится всегда. Сразу же, как увидели баг,
делайте скриншот. Даже если вам самому больше не удастся
воспроизвести баг, возможно, программист по скриншоту
поймёт, в чём дело. Также помните, что если у
программиста баг не воспроизводится – задача
тестировщика состоит в том, чтобы воспроизвести баг в
присутствии программиста на его или своём компьютере.
19. Важность (severity)
Это поле показывает, насколько серьёзна найденная ошибка.
Крит ическая (critical). Это самые страшные ошибки, выражающиеся в
крахе приложения или операционной системы, серьёзных повреждениях
базы данных, падению веб-сервера или сервера приложений.
Высока (major). Серьёзные ошибки, такие как: потеря данных
пользователя, падение значительной части функциональности
приложения, падение браузера или иного клиента и т.п.
Средняя (medium). Ошибки, затрагивающие небольшой набор функций
приложения. Как правило, такие ошибки можно «обойти», т.е.
выполнить требуемое действие иным способом, не приводящим к
возникновению ошибки.
Низкая (minor). Ошибки, не мешающие непосредственно работе с
приложением. Как правило, сюда относятся всевозможные
косметические дефекты, опечатки и т.п.
20. Срочность (priority)
Это поле показывает, как быстро необходимо исправить ошибку.
Наивысшая (ASAP, as soon as possible). Присваивается
ошибкам, наличие которых делает невозможным дальнейшую
работу над проектом или передачу заказчику текущей версии
проекта.
Высокая (high). Присваивается ошибкам, которые нужно
исправить в самое ближайшее время.
Обычная (normal). Присваивается ошибкам, которые следует
исправлять в порядке общей очереди.
Низкая (low). Присваивается ошибкам, которыми отделу
разработки следует заниматься в последнюю очередь (когда и
если на них останется время).
21. Симптом (symptom)
Это поле показывает, к какой категории относится ошибка.
Косметический дефект (cosmetic flaw) – опечатки,
повреждённые картинки, не тот цвет, не тот размер, не там
расположено и т.п.
Повреждение/потеря данных (data corruption/loss) – в
результате ошибки данные повреждаются или теряются.
Проблема в документации (documentation issue) – такой
симптом присваивается ошибке, если она описывает
проблему не в приложении, а в документации.
Некорректная операция (incorrect operation) –
например: 2+2=5, или: хотим сохранить файл в c:/ , а он
сохраняется в d:/
22. Симптом (symptom)
Это поле показывает, к какой категории относится ошибка.
Проблема инсталляции (installation problem) – ошибки,
возникающие на стадии установки или удаления
приложения
Ошибка локализации (localisation issue) – что-то не
переведено или переведено неверно.
Нереализованная функциональность (missing feature) –
например: приложение сохраняет файлы только в формате
DOC, а должно ещё и в XML.
Низкая производительность (slow performance) –
некоторые действия и/или условия работы приводят к тому,
что приложение начинает «тормозить».
23. Симптом (symptom)
Это поле показывает, к какой категории относится ошибка.
Крах системы (system crash) – приложение или операционная
система или (веб-сервер / сервер приложений / СБД) виснет,
перезагружается, «вываливается» (закрывается)
Неожиданное поведение (unexpected behavior) – например:
комбинация клавиш Ctrl-O вызывает не открытие, а печать
файла; в полях формы появляются странные значения по
умолчанию.
Недружественное поведение (unfriendly behavior) –
например: на сайте есть голосование, пользователь выбирает
вариант, нажимает «Проголосовать» и… его просят
зарегистрироваться.
24. Симптом (symptom)
Это поле показывает, к какой категории относится
ошибка.
Расхождение с требованиям (variance from spec) –
под этот симптом попадает почти любая ошибка, но
рекомендуется писать его только тогда, когда к ошибке
не подходит ничего из вышеперечисленного.
Предложение по улучшению (enhancement) – строго
говоря, это – не баг, и во многих фирмах не принято его
писать в список багов; имеется в виду, что приложение
работает по требованиям, но можно улучшить его
работу, если внести предлагаемые изменения.
25. Дополнительно
Возможность «обойти баг» (workaround)
Это поле косвенно влияет на важность и срочность
устранения ошибка. Если некое действие можно
выполнить в обход сценария, приводящего к ошибке,
поле принимает значение «да» («yes»), в противном
случае – поле принимает значение «нет» («no»).
26. Дополнительно
Дополнительная информация (additional info)
В это поле можно писать всё то, что вы считаете
необходимым отметить, но что не подходит для
размещения в других полях. Рассуждения,
комментарии, мысли, анализ возможных причин
появления бага и путей его устранения – всё это
пишется здесь.
27. Дополнительно
Приложения («аттачи») (attachments)
Лучший способ указать на баг – приложить к багрепорту некую наглядную информацию: скриншоты,
видеоролики, логи (журналы событий).
28. Какой отчёт об ошибке является плохим?
Какой отчёт об ошибке является
плохим?
Отчёт, который не даёт достаточной информации
«Программа не работает», «Приложение виснет».
Отчёт об ошибках в той части функциональности,
которая не заявлена как реализованная в данном
билде.
Отчёт, дающий некорректную информацию (в любом
из полей).
Отчёт, написанный с грамматическими ошибками
и/или с использованием жаргонной, непонятной
большинству лексики.
Отчёт, критикующий работу программиста.
29. Хороший отчёт об ошибках помогает:
Хороший отчёт об ошибках помогает:
Сократить количество ошибок, «возвращаемых»
разработчиками (отклонённых или открытых
заново).
Ускорить устранение ошибки.
Сократить стоимость исправления ошибки.
Повысить репутацию тестировщика.
Улучшить взаимоотношения между командами
тестирования и разработки.
30. Рекомендации по написанию хороших отчётов об ошибках
Тщательно объясните, как воспроизвести ошибку.
Сообщите всю необходимую для этого
информацию, а также свои размышления о
возможных причинах возникновения ошибки.
Описывайте всё максимально подробно. Особенно
это относится к ожидаемому и фактическому
результатам, а также шагам воспроизведения.
Пишите отчёт понятно. Используйте
общеупотребимую лексику, точные названия
элементов ПС, аккуратно оформляйте написанное.
31. Рекомендации по написанию хороших отчётов об ошибках
Если это возможно, обязательно давайте ссылку на
соответствующее требование, к нарушению которого
приводит фактический результат выполнения ПО.
Если существует какая-либо информация, которая
может помочь быстро обнаружить и исправить
ошибку, – сообщите эту информацию.
Чётко указывайте окружение (ОС, браузер,
настройки и т.п.), под которым произошла ошибка.
Помните, что баг-репорт – это технический
документ, в котором нет места эмоциям.
32. Рекомендации по написанию хороших отчётов об ошибках
В одном отчёте описывайте ровно одну проблему. Если вы
видите две ошибки – пишите два отчёта.
Если вам хватает знаний, проведите начальный анализ
возможных причин возникновения ошибки и опишите его
результаты в разделе «Комментарии».
Пишите отчёт об ошибке сразу же, как только вы
обнаружили ошибку. Откладывание записи «на потом»
приводит к тому, что вы или вообще забудете об этой
ошибке, или забудете о каких-то важных деталях. Также
несвоевременное написание отчёта об ошибке не позволяет
проектной команде реагировать на её обнаружение в
реальном времени.
33. Рекомендации по написанию хороших отчётов об ошибках
Попытайтесь найти наиболее серьёзные
последствия ошибки. Возможно, то, что казалось
незначительны вначале, на самом деле может
привести к очень серьёзным неприятностям.
После написаний отчёта ещё раз внимательно его
перечитайте. Убедитесь, что все необходимые поля
заполнены, и всё написано верно.
Помните, что вам же самим потом придётся
верифицировать баг по своему же баг-репорту.
34. В каких случаях баг может остаться неисправленным?
Программист так и не смог воспроизвести у себя ошибку по той или иной
причине.
Ошибке выставлены неверная важность и/или приоритет.
Отсутствует описание некорректного поведения (актуального
результата).
Отсутствует описание ожидаемого результата или оно не обосновано(нет
ссылок на требования).
Отчёт написан безграмотно, расплывчато, непонятно
Отсутствуют необходимые для понимания ошибки скриншоты, логи и
т.д.
Для описания новой ошибки, похожей на старую, тестировщик сделал
«повторное открытие» уже исправленной ошибки.
Тестировщик не сумел убедить команду в важности проблемы.
У тестировщика плохая репутация.