QA Engineer - Михаил Семынин

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

— Release Test Plan (тест-план релиза) — план, который применяют ко всему большому релизу приложения. Он как раз похож на описанный выше и будет включать большинство пунктов с подробным описанием. Такой документ особенно полезен, когда необходимо синхронизировать работу множества отдельных команд, выпускающих единый релиз. Этот документ не описывает подробности того, как будет тестироваться каждая отдельная фича, а только указывать их список.

— Feature Test Plan (тест-план фичи) — план, который применяют для любой доработки приложения. Этот документ структурно похож на тест-план релиза, но он концентрируется и подстраивается только под конкретные потребности доработки, его размер сокращен только до самого важного.

Пример простого тест-плана релиза:

5.4. Test Report

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

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

Тест-репорт состоит из таких разделов:

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

— Цели тестирования — краткое описание целей, которые были поставлены перед командой тестирования.

— Объект тестирования — описание функций, модулей или компонентов продукта, которые проходили тестирование.

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

— Обзор тестирования — краткое изложение подходов и методик, применяемых в тестировании.

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

— Результаты тестирования — количество выполненных, пройденных и непройденных тест — кейсов.

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

— Анализ результатов — оценка результатов тестирования, включая соответствие продукта требованиям и ожиданиям.

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

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

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

Пример тест-репорта

5.5. Requirements Traceability Matrix

Requirements Traceability Matrix (матрица трассировки требований) — это документ, который используют для отслеживания и подтверждения выполнения всех требований к продукту на протяжении всего жизненного цикла разработки. Матрица трассировки требований помогает убедиться, что каждое требование к программному обеспечению было протестировано, и что все тесты проведены корректно. Этот вид документации является всесторонне полезным инструментом, особенно для больших проектов.

Задачи матрицы трассировки требований:

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

— Помогает идентифицировать любые требования, для которых тесты еще не разработаны.

— Позволяет отслеживать изменения в требованиях и оценивать их влияние на уже разработанные тестовые случаи и результаты тестирования.

— Упрощает предоставление заинтересованным сторонам информации о статусе выполнения требований и результатах тестирования.

Пример простой матрицы трассировки требований

5.6. Test Strategy

Test Strategy (стратегия тестирования) является ключевым документом в процессе обеспечения качества программного обеспечения, определяющим общий подход и план действий по тестированию продукта. Этот документ описывает методологии, стандарты, цели, приоритеты, критерии успеха, ресурсы и график тестирования на самом высоком уровне. Разработанная стратегия тестирования служит основой для более детализированных тест-планов и задает общий ритм процесса.

Цели стратегии тестирования:

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

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

— Определение необходимых ресурсов, включая персонал, инструменты и оборудование.

— Определение потенциальных рисков и разработка стратегий их минимизации.

Стратегия тестирования играет важную роль в обеспечении качества программного продукта, так как она:

— Гарантирует единое понимание целей тестирования и подходов к нему всеми участниками проекта.

— Помогает оптимизировать процесс тестирования за счет эффективного распределения ресурсов и четкого планирования.

— Содействует выявлению и управлению рисками на ранних этапах проекта.

— Улучшает коммуникацию и координацию действий между командами разработки и тестирования.

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

Основные компоненты стратегии тестирования:

— Введение — общее описание проекта, его целей, области действия стратегии тестирования.

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

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

— Типы тестирования — перечень типов тестирования (функциональное, нефункциональное, регрессионное и т. д.), которые будут применять в проекте.

— Роли и ответственности — распределение задач и ответственности между участниками процесса тестирования.

— Оценка рисков и управление ими — анализ потенциальных рисков для проекта и меры по их предотвращению или минимизации.

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

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

— Процедуры отчетности — система отчетности о ходе и результатах тестирования.

Пример простой стратегии тестирования

6. ПРОЦЕССЫ

6.1. Процессы на уровне компании