Что такое стратегия тестирования?

Описание

Стратегия тестирования (или тестовая стратегия) — высокоуровневый документ, описывающий техники тестирования, используемые в STLC-цикле, и подтверждает виды и уровни тестирования в данном проекте. 

Стратегия тестирования в сущности неизменяемый документ, после того как создана, согласована и утверждена проджект-менеджером.

Тестовая стратегия содержит ответы на следующие вопросы:

  • Какие техники тестирования будут применяться?
  • Какие модули будут протестированы?
  • Какие критерии входа и выхода?
  • Какая область тестирования?

То есть это «стратегический» высокоуровневый документ, объясняющий и направляющий процессы тестирования, учитывающий также следующие вопросы:

  • Степень автоматизации процессов
  • Какие человеческие и другие ресурсы будут задействованы

Стратегия создается на основе документация по дизайну проекта:

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

Из чего состоит тестовая стратегия

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

Стратегия тестирования не представляет собой «расширенную версию плана тестирования» — тест-план является документом нижнего уровня; в то время как Стратегия это «общий, целеполагающий» документ. Оба документа являются важными артефактами в QA, направленными на расширение тестового покрытия и повышение качества продукта.

Составляющие тестовой стратегии:

  1. Обзор и область тестирования
  2. Применяемые методологии
  3. Спецификации тестовых окружений
  4. Инструменты тестирования
  5. Данные, относящиеся к релизу
  6. Анализ рисков
  7. Данные о проверке и утверждении

1. Саммари (общий обзор) и описание сферы тестирования

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

  • Обзор («Summary») проекта с указанием ответственных лиц.
  • Также указание причастных к оценке, согласованию и утверждению Стратегии.
  • Расписание этапов и тестовых активностях на этих этапах, с рабочими графиками, и также сроки этапов.

2. Методология

Методология тестирования — следующая секция Стратегии. Подробное описание уровней тестирования, активностей, ролей и прикрепленных обязанностей членов QA-команды и других причастных. 

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

Итак, в этой секции указывается следующее:

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

3. Описание тестовых окружений

Следующая секция Стратегии тестирования. Тестовое окружение и тестовые данные — важные вещи в QA. Поэтому описание тестового окружения (иначе говоря, среды тестирования) в этом документе включает в себя указания по созданию тестовых данных и манипуляциям с ними. В частности, количество тестовых окружений и их параметры. Также может описываться резервное копирование и восстановление окружений. Итак, секция содержит следующее:

  • Информация о количестве окружений и их конфигурациях.
  • Отдельно окружения по предназначению (например, функциональное тестирование может иметь одни тестовые окружения, для приемочного другие).
  • Количество пользователей в каждом окружении и уровни доступа, а также программные и аппаратные характеристики окружений (ОС, память, место на диске).
  • Объем тестовых данных.
  • Способ получения тестовых данных (при помощи генераторов, или данные реальных пользователей из проекта, с маскированием информации).
  • Порядок резервного копирования и восстановления тестовых данных.
  • Какие базы данных используются.
  • Указывается, кто и когда должен делать резервные копии, что должно быть включено, порядок восстановления, и контроль доступа при восстановлении.

4. Инструменты тестирования

Важная секция, содержащая данные об инструментах автоматизации тестирования, управления им, и обслуживания тестовых процессов. Инструменты тестирования безопасности и производительности; платные или open-source.

  • Во первых, инструменты управления тестированием (инструменты тест-менеджмента) 
  • Инструменты автоматизации, которые будут использованы для подготовки и выполнения тестов.
  • Подходы к тестированию производительности и безопасности и применяемые в этой сфере инструменты
  • Указание платности/бесплатности инструментов, количества пользователей, которое инструмент поддерживает.

5. Управление релизами

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

  • Версии продукта для тестового/приемочного окружения, возникающие в результате незапланированных релизов.
  • Контроль тестирования изменений в таких релизах; управление версиями.
  • Управление билдами; где и когда будет доступен новый билд; где он будет развернут; продакшен-билд; кто контролирует релизы (например дает «go-signal» к запуску релиза) и так далее.

6. Анализ рисков

В следующей секции по возможности кратко описываются все потенциальные риски в проекте, могущие вызвать проблемы в процессе тестирования. Также описываются способы устранения/смягчения этих рисков. Нужно также иметь «План Б» на случай непредвиденных ситуаций (не предусмотренных обычным анализом рисков). 

Итак, составляется список всех потенциальных опасностей и план контроля этих рисков, а также «план отхода» — резервный план, если проект столкнется с большими рисками.

7. Данные о согласовании и утверждении

Согласование и утверждение, последняя секция Стратегии. После подготовки Стратегии она проверяется, согласовывается, и утверждается причастными менеджерами:

  • Менеджмент ИТ-компании.
  • Команда управления проектом.
  • Команда разработчиков.
  • Бизнес-команда.

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

Чем тестовая стратегия отличается от тест-плана

Тест-планТестовая стратегия
Создается на основе требований к продукту (SRS) Создается на основе бизнес-требований (BRS)
Готовит QA-лид или другой ответственный менеджерГотовит проджект-менеджер или бизнес-аналитик
ID тест-плана, тестируемые функции, применяемые техники тестирования, задачи в процессе, критерии приемки, тестовые артефакты, тестировщики прикрепленные к функциям и расписание их задач, и подобные низкоуровневые вещиЦели, области и масштаб тестирования, применяемые методики, процессы, структура команды, форматы документации, подходы к коммуникации с клиентами и подобные высокоуровневые вещи
План пишется после принятия требований к продукту и на их основеСтратегия является первичным документом и создается в начале работы над продуктом
Тест-план должен быть простым документомСтратегия служит общим целеуказателем в проекте

Типы тестовых стратегий

Далее приведены типы стратегий «под задачу»:

  1. Аналитическая стратегия. 

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

  1. Стратегия, основанная на модели

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

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

  1. Методическая стратегия

В этом случае строго соблюдается некий формализованный стандарт качества (например, стандарт ISO25000); применяют чеклисты и/или другие формальные подходы. В некоторых видах тестирования (например, безопасности) и типах приложений (например мобильные) существуют общепринятые/стандартизированные чеклисты проверок. Например, для maintenance-тестирования обслуживания чаще всего достаточно чеклиста, описывающего соответствующие функции, их свойства и т.д.

  1. Стратегия, ориентированная на стандарты или процессы

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

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

  1. Реактивная стратегия

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

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

  1. Консультативная стратегия

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

  1. Стратегия антирегрессионного тестирования

Для случаев, когда процедуры тестирования в проекте сконцентрированы на снижении риска регрессии функциональных и нефункциональных аспектов продукта. 

Например, если веб-приложение необходимо протестировать на регрессию, QA-команда может автоматизировать как позитивные, так и негативные use-кейсы, и выполнять тесты всякий раз при обновлении приложения. 

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

Выбор нужной стратегии

Влияют следующие факторы:

  • Нужная Стратегия тестирования зависит от особенностей продукта.
  • А также от требований, например, приложения, ориентированные на безопасность, требуют более строгих подходов.
  • Выбор стратегии тестирования также зависит от модели разработки продукта.
  • «Большие продукты» требуют долгосрочной стратегии
  • Тип и размер компании.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас