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