QA Engineer

Также это влияет на модифицируемость документа в случае обновлений функционала. Объемные тест-кейсы сложны для чтения и понимания сути их действий и проверок. Иногда необходимо удерживать в голове тонкости нескольких таких больших тест-кейсов, чтобы они оставались согласованными после обновления.

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

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

5.2. Bug Report

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

Баг-репорт тоже является одним из наиболее часто встречающихся видов документации. Обычно его составляет QA инженер в ходе проведения проверок. Тем не менее баг-репорт может также завести любой другой участник проекта: руководитель, разработчики, аналитики, поддержка. Также баг-репорт могут предоставлять пользователи. В случае Альфа или Бета — тестирования баг-репорт может быть приближен к тому, который составляет QA инженер. В некоторых ситуациях его генерирует система автоматически — тогда он скорее всего имеет описание не в такой “человеческой” форме.

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

Атрибуты качества баг-репорта:

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

— Полнота — описание должно содержать все условия, при которых возникает ошибка, а также объяснять ее последствия.

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

— Приоритезированность — баг-репорт содержит оценку серьезности дефекта и его приоритета для исправления.

— Краткость — в нём не должно быть информации, не относящейся к описанному дефекту.

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

Структура баг-репорта:

— Идентификатор (ID) — уникальный номер дефекта, который обычно выставляется автоматически.

— Название — краткое описание проблемы.

— Статус — указывает на текущее состояние обнаруженного дефекта, например, открыт, в работе, исправлен, отменен. QA инженер чаще всего открывает и закрывает баг — репорты.

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

— Критичность — оценка влияния дефекта на работоспособность системы.

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

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

— Вложения — дополнительная информация, способная помочь быстрее исправить дефект, например скриншоты, видео, логи ошибок.

— Дата и время создания дефекта.

— Автор — тот, кто создал баг-репорт.

Пример баг-репорта

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

5.3. Test Plan

Test Plan (тест-план) — это документ, в котором описан весь объем работ по тестированию. Он состоит из следующих частей:

— Описание объекта тестирования. Этот раздел дает общее представление о продукте или компоненте, которому предстоит пройти тестирование. Здесь указываются функции, модули или аспекты системы, подлежащие тестированию, а также любые версии или конфигурации, которые необходимо учесть.