Тестовая стратегия (Testing Strategy)

Краткое определение - виды тестирования и их применение по отношению к тестируемому объекту.

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

Стратегия отвечает на вопросы:

• Как, каким образом тестирование даст ответ, что данный функционал работает?

• Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?

• Когда определённый функционал будет тестироваться и соответственно когда ожидать получения результатов?

Нужно ли составлять тест-план?

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

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

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

Простой пример: Вам поставлен таск «протестировать функциональность сортировки». Как может выглядеть ваш тест-план – см. приаттаченный «test-plan_пол-листика.doc».

Время, затраченное на него – 20 минут. Время, сэкономленное на «что бы ешё потестить» и «а пробовал ли я такое» - 4 часа. Нервы, сэкономленные на выяснении с руководителем «что ты тестил», «почему это пропущено» - бесценно.

Кто должен составлять тест-план?

Если было принято решение оформлять тест-план по всем правилам, то встает вопрос, кто это должен делать?

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

• Ведущий тестировщик

• Тест менеджер (менеджер по качеству)

• Руководитель разработки

• Менеджер Проекта

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

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

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