Составление документации по результатам проведения тестов 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) и другие.
Что является обязательным в отчете о дефекте?
Правильно заполненные атрибуты багрепорта – это важнейшая часть процесса устранения ошибок. Целесообразно заполнять все поля формы и это является важным навыком тестировщика. Преподаватели учебного центра QA Academy помогут вам разобраться во всех нюансах. Что особенно важно в современных условиях – обучение проходит в дистанционном формате на Курсах по тестированию программного обеспечения.