Test Strategy (стратегия тестирования) является ключевым документом в процессе обеспечения качества программного обеспечения, определяющим общий подход и план действий по тестированию продукта. Этот документ описывает методологии, стандарты, цели, приоритеты, критерии успеха, ресурсы и график тестирования на самом высоком уровне. Разработанная стратегия тестирования служит основой для более детализированных тест-планов и задает общий ритм процесса.
Requirements Traceability Matrix (матрица трассировки требований) — это документ, который используют для отслеживания и подтверждения выполнения всех требований к продукту на протяжении всего жизненного цикла разработки.
Test Report (тест-репорт, отчет о тестировании) — это документ, в котором подводят итоги тестирования после его завершения. Он предоставляет собой всесторонний обзор проведенных тестов, их результатов и выводов по качеству тестируемого продукта.
Тест-план — основополагающий элемент процесса тестирования, поскольку он обеспечивает всеобъемлющую основу для тестирования на всех этапах разработки продукта. Оформлением документа обычно занимается QA Lead, Head of QA или наиболее опытный QA инженер.
Test Plan (тест-план) — это документ, в котором описан весь объем работ по тестированию. Он состоит из следующих частей:
— Дата и время создания дефекта.
— Автор — тот, кто создал баг-репорт
Структура баг-репорта:
— Идентификатор (ID) — уникальный номер дефекта, который обычно выставляется автоматически.
— Название — краткое описание проблемы.
— Статус — указывает на текущее состояние обнаруженного дефекта, например, открыт, в работе, исправлен, отменен. QA инженер чаще всего открывает и закрывает баг–репорты.
— Приоритет — обозначает срочность взятия дефекта в работу для исправления. Его может указать QA инженер или любой другой участник команды, отвечающий за приоритезацию работы над дефектами.
— Критичность — оценка влияния дефекта на работоспособность системы.
— Окружение — описание окружения, в котором был обнаружен дефект, например операционная система, браузер, версия тестируемого программного обеспечения.
— Описание — полное описание проблемы, включает точные шаги для воспроизведения, ожидаемый и фактический результаты поведения системы.
— Вложения — дополнительная информация, способная помочь быстрее исправить дефект, например скриншоты, видео, логи ошибок.
Хорошим тоном будет приложить к баг-репорту все логи работы приложения, которые только можно. Также полезно указать баг-репорты, ошибки в которых кажутся похожими или связанными с дефектом, который вы обнаружили.
Test Case (тест-кейс) — это документ, направленный на проверку конкретного функционала или требования к системе с высоким уровнем подробностей.
Применение техник тест-дизайна порождает несколько наборов тестовых данных, которые можно описать одним или группой тест-кейсов. Каждый из них имеет определенные атрибуты:
— Название — оно должно быть коротким, но отражающим цель описанных в тест-кейсе проверок.
— Предварительные условия (могут быть пустыми) — описывают состояние всего приложения или его частей, а также необходимость выполнить предварительные шаги перед началом тестирования.
— Шаги — набор последовательных действий для получения ожидаемого отклика системы.
— Ожидаемый результат — состояние системы, которое должно получиться после выполнения шагов, обычно напрямую связано с конкретным требованием к приложению.
Checklist (чек-лист) — это список задач или пунктов, которые необходимо проверить, но без детального описания того, как это сделать. Его можно использовать на высоком уровне. В этом случае задача чек-листа — не упустить главные пункты проверок.
