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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3. Test Plan

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

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

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

— Расписание проведения тестирования. Здесь определены временные рамки тестирования, включая начало и окончание каждого его цикла, а также ключевые даты, к которым должны быть достигнуты конкретные цели. Это помогает координировать усилия команды и обеспечивать соблюдение сроков.

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

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

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

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

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

Тест-план — основополагающий элемент процесса тестирования, поскольку он обеспечивает всеобъемлющую основу для тестирования на всех этапах разработки продукта. Оформлением документа обычно занимается QA Lead, Head of QA или наиболее опытный QA инженер.

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

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

Нежелание использовать тест-план в некоторых командах связано, во — первых, с тем, что текущий тренд в разработке программного обеспечения — это создавать небольшие обновления, которые проще тестировать. К тому же нередко команды разработки довольно маленькие: в них состоят 1–3 QA инженера. Из — за небольшого масштаба опытный QA вполне может держать этот план в голове и следовать ему.

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

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