# Стратегия тестирования ### Содержание: * [Описание](#definition) * [Из чего состоит тестовая стратегия](#components) * [Чем тестовая стратегия отличается от тест-плана](#strategy-vs-plan) * [Типы стратегий](#types) * [Выбор нужной стратегии](#choice) ### Описание Стратегия тестирования (или тестовая стратегия) — высокоуровневый документ, описывающий техники тестирования, используемые в STLC-цикле, и подтверждает виды и уровни тестирования в данном проекте. Стратегия тестирования в сущности неизменяемый документ, после того как создана, согласована и утверждена проджект-менеджером. Тестовая стратегия содержит ответы на следующие вопросы: * Какие техники тестирования будут применяться? * Какие модули будут протестированы? * Какие критерии входа и выхода? * Какая область тестирования? То есть это «стратегический» высокоуровневый документ, объясняющий и направляющий процессы тестирования, учитывающий также следующие вопросы: * Степень автоматизации процессов * Какие человеческие и другие ресурсы будут задействованы Стратегия создается на основе документация по дизайну проекта: * Документация дизайна системы в целом — главным образом используется она. * *Второстепенная документация по дизайну приложения — как вспомогательная и для будущих версий.* * *Документация на концептуальном уровне — редко используется.* ### Из чего состоит тестовая стратегия Описания области тестирования (*test scope*), распределения сил и средств, тестовых окружений, инструментов тестирования, используемые для проверки и утверждения набора функций, описаны в стратегии тестирования, и многое другое. Также включаются графики занятости сотрудников, прикрепленные задачи и подобные рабочие моменты, чтобы QA-команда была максимально структурированной и эффективной. Стратегия тестирования не представляет собой «расширенную версию плана тестирования» — тест-план является документом нижнего уровня; в то время как Стратегия это «общий, целеполагающий» документ. Оба документа являются важными артефактами в QA, направленными на расширение тестового покрытия и повышение качества продукта. Составляющие тестовой стратегии: 1. Обзор и область тестирования 2. Применяемые методологии 3. Спецификации тестовых окружений 4. Инструменты тестирования 5. Данные, относящиеся к релизу 6. Анализ рисков 7. Данные о проверке и утверждении #### 1. Summary (общий обзор) и описание сферы тестирования Первая секция, включающая данные о сотруднике, который отвечает за согласование, проверку, утверждение, и использование Стратегии. Также краткое перечисление этапов тестирования и мероприятий. * Обзор («Summary») проекта с указанием ответственных лиц. * Также указание причастных к оценке, согласованию и утверждению Стратегии. * Расписание этапов и тестовых активностях на этих этапах, с рабочими графиками, и также сроки этапов. #### 2. Методология Методология тестирования — следующая секция Стратегии. Подробное описание уровней тестирования, активностей, ролей и прикрепленных обязанностей членов QA-команды и других причастных. Описание управления процессами, например запросы на какие-то изменения, шаблоны которые будут использованы, действия по управлению запросами; это моменты уточняются, чтобы гарантировать контролируемость процессов, не допустить ошибок и хаоса. Итак, в этой секции указывается следующее: * Процессы тестирования, уровни тестирования, роли и обязанности в команде. * Подробнее описывается применение типов тестирования в этом проекте (юнит-, интеграционное, системное, регрессионное, юзабельности, нагрузочное, безопасности).Также время начала и завершения этих операций, ответственные за эти операции, их обязанности, особые подходы и методики. Также описывается подход к автоматизации, ее масштаб, и применяемые инструменты и фреймворки. #### 3. Описание тестовых окружений Следующая секция Стратегии тестирования. Тестовое окружение и тестовые данные — важные вещи в QA. Поэтому описание тестового окружения (иначе говоря, среды тестирования) в этом документе включает в себя указания по созданию тестовых данных и манипуляциям с ними. В частности, количество тестовых окружений и их параметры. Также может описываться резервное копирование и восстановление окружений. Итак, секция содержит следующее: * Информация о количестве окружений и их конфигурациях. * Отдельно окружения по предназначению (например, функциональное тестирование может иметь одни тестовые окружения, для приемочного другие). * Количество пользователей в каждом окружении и уровни доступа, а также программные и аппаратные характеристики окружений (ОС, память, место на диске). * Объем тестовых данных. * Способ получения тестовых данных (при помощи генераторов, или данные реальных пользователей из проекта, с маскированием информации). * Порядок резервного копирования и восстановления тестовых данных. * Какие базы данных используются. * Указывается, кто и когда должен делать резервные копии, что должно быть включено, порядок восстановления, и контроль доступа при восстановлении. #### 4. Инструменты тестирования Важная секция, содержащая данные об инструментах автоматизации тестирования, управления им, и обслуживания тестовых процессов. Инструменты тестирования безопасности и производительности; платные или open-source. * Во первых, инструменты управления тестированием (инструменты тест-менеджмента) * Инструменты автоматизации, которые будут использованы для подготовки и выполнения тестов. * Подходы к тестированию производительности и безопасности и применяемые в этой сфере инструменты * Указание платности/бесплатности инструментов, количества пользователей, которое инструмент поддерживает. #### 5. Управление релизами Следующая секция Стратегии, используется для контроля того, что управление релизами производится упорядоченным образом. В секции приводится следующее: * Версии продукта для тестового/приемочного окружения, возникающие в результате незапланированных релизов. * Контроль тестирования изменений в таких релизах; управление версиями. * Управление билдами; где и когда будет доступен новый билд; где он будет развернут; продакшен-билд; кто контролирует релизы (например дает «go-signal» к запуску релиза) и так далее. #### 6. Анализ рисков В следующей секции по возможности кратко описываются все потенциальные риски в проекте, могущие вызвать проблемы в процессе тестирования. Также описываются способы устранения/смягчения этих рисков. Нужно также иметь «План Б» на случай непредвиденных ситуаций (не предусмотренных обычным анализом рисков). Итак, составляется список всех потенциальных опасностей и план контроля этих рисков, а также «план отхода» — резервный план, если проект столкнется с большими рисками. #### 7. Данные о согласовании и утверждении Согласование и утверждение, последняя секция Стратегии. После подготовки Стратегии она проверяется, согласовывается, и утверждается причастными менеджерами: * Менеджмент ИТ-компании. * Команда управления проектом. * Команда разработчиков. * Бизнес-команда. Указывается дата утверждения, ФИО утвердителей, их комментарии, и краткое описание утвержденных изменений, если таковые случатся; в процессе тестирования в Стратегию могут вноситься обновления и корректировки. ### Чем тестовая стратегия отличается от тест-плана | Тест-план |

Тестовая стратегия

| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Создается на основе требований к продукту (SRS) |

Создается на основе бизнес-требований (BRS)

| | Готовит QA-лид или другой ответственный менеджер |

Готовит проджект-менеджер или бизнес-аналитик

| | ID тест-плана, тестируемые функции, применяемые техники тестирования, задачи в процессе, критерии приемки, тестовые артефакты, тестировщики прикрепленные к функциям и расписание их задач, и подобные низкоуровневые вещи |

Цели, области и масштаб тестирования, применяемые методики, процессы, структура команды, форматы документации, подходы к коммуникации с клиентами и подобные высокоуровневые вещи

| | План пишется после принятия требований к продукту и на их основе |

Стратегия является первичным документом и создается в начале работы над продуктом

| | Тест-план должен быть простым документом |

Стратегия служит общим целеуказателем в проекте

| ### Типы тестовых стратегий Далее приведены типы стратегий «под задачу»: 1. **Аналитическая стратегия.** К примеру, тестирование на основе рисков и тестирование на основе требований — два отдельных типа тестирования, нужны разные подходы. После изучения условий тестирования, таких как риски и требования, QA-команда уточняет обстоятельства тестирования. В случае *тестирования на основе требований* для определения обстоятельств изучаются требования. Затем создаются и выполняются тесты, направленные на проверку выполнения требований. В аналитической стратегии отслеживаются результаты проверки требований, и те, которые были проверены и прошли, и те, которые не прошли, и те, которые не были полностью протестированы. 2. **Стратегия, основанная на модели** Команда тестирования оценивает фактические и ожидаемые обстоятельства и строит модель, учитывая входы, выходы, действия и возможное поведение продукта. Модели будущего продукта также могут создаваться на основе какого-то существующего продукта, или технологии, или с учетом рассчитываемой скорости передачи данных, особой инфраструктуры, и других факторов. Например, при тестировании производительности мобильного приложения можно создать модель, имитирующую исходящий и входящий трафик мобильной сети, количество активных/неактивных пользователей, прогнозируемый рост и другие факторы; и соответственно создать Стратегию, исходя из этой модели. 3. **Методическая стратегия** В этом случае строго соблюдается некий формализованный стандарт качества (например, стандарт ISO25000); применяют чеклисты и/или другие формальные подходы. В некоторых видах тестирования (например, безопасности) и типах приложений (например мобильные) существуют общепринятые/стандартизированные чеклисты проверок. Например, для maintenance-тестирования обслуживания чаще всего достаточно чеклиста, описывающего соответствующие функции, их свойства и т.д. 4. **Стратегия, ориентированная на стандарты или процессы** Например, при тестировании медицинских ИТ-систем, которые обязаны соответствовать регуляторным стандартам государства. ИТ-компания в некоторых случаях должна соблюдать методы и/или рекомендации, установленные комитетами по стандартам/группами специалистов, и иногда это касается условий тестирования,тест-кейсов, и даже состава QA-команды. В случае не столь четких и строгих требований, а просто по принятой методике, например при разработке по неформальному но распространенному стандарту (Agile и пр.), могут создавать стратегию тестирования для каждой пользовательской истории, описывая критерии тестирования, тест-кейсы и сценарии, репорты и так далее. 5. **Реактивная стратегия** Тесты создаются и выполняются только после релиза продукта. Тестирование концентрируется на дефектах, обнаруженных уже в работающей системе. Например следующая ситуация: проводится *исследовательское тестирование* работающего продукта; тест-кейсы создаются по уже имплементированным функциям; по результатам этих тестов происходит обновление тестов и подходов. Нередко по реактивной стратегии действуют в Agile-разработке. 6. **Консультативная стратегия** Как и в примере выше с Agile, может быть подход к тестовой стратегии, основанный на фидбеке от пользователей и стейкхолдеров. Например, имеем сценарий тестирования кроссбраузерной совместимости веб-приложения. Владелец продукта предоставляет список браузеров и их версий; также может указать нужные операционные системы и другие требования. 7. **Стратегия антирегрессионного тестирования** Для случаев, когда процедуры тестирования в проекте сконцентрированы на снижении риска регрессии функциональных и нефункциональных аспектов продукта. Например, если веб-приложение необходимо протестировать на регрессию, QA-команда может автоматизировать как позитивные, так и негативные use-кейсы, и выполнять тесты всякий раз при обновлении приложения. Все типы тестовых стратегий, описанные выше, применяются в зависимости от особенностей продукта, или могут сочетаться. О выборе подходящей Стратегии — далее. ### Выбор нужной стратегии Влияют следующие факторы: * Нужная Стратегия тестирования зависит от особенностей продукта. * А также от требований, например, приложения, ориентированные на безопасность, требуют более строгих подходов. * Выбор стратегии тестирования также зависит от модели разработки продукта. * «Большие продукты» требуют долгосрочной стратегии * Тип и размер компании. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://qabook.gitbook.io/start/teoriya-testirovaniya/testovaya-dokumentaciya/strategiya-testirovaniya.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.