SavePearlHarbor

Фантастическая стратегия тестирования и места, где она обитает

—

от автора

admin

Привет, дорогой читатель! Меня зовут Мария Вавилова, я начальник управления обеспечения качества в компании «ГНИВЦ» и занимаюсь созданием комфортных сервисов для взаимодействия с государством.

В этой статье хочу поговорить о must have в тестировании — об артефактах. В конце поделюсь небольшим подарком в виде шаблона одного из таких документов. Чтобы добавить чуть больше динамики, давайте ответим на несколько вопросов:

Знаете ли вы, что такое стратегия тестирования? Применяется ли она на ваших проектах?

Знаете ли вы, что такое план тестирования? Применяется ли он на ваших проектах?

Предположу, что многие ответили утвердительно, но вот к чему я веду…

Загадочный «сферический конь» или почему стратегия тестирования иногда ускользает

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

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

  2. Что такое план тестирования?

Ответы бывают самыми разными, даже внутри одного QA‑сообщества. В некоторых компаниях есть своя терминология (например, smoke зовётся «малым кругом», а инцидент — это service task). Всё это объясняется тем, что нет единого универсального стандарта, а система квалификаций в разных местах своя. В какой‑то момент я задалась вопросом: это я чего‑то не понимаю или мир действительно настолько разнообразен?

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

Что говорит теория

ISO/IEC/IEEE 29 119

На сегодня актуальным стандартом для тестовой документации является ISO/IEC/IEEE 29 119, который, по сути, заменил устаревший IEEE 829. Согласно документу ISO/IEC/IEEE 29 119–2:2013:

3.127 test strategy
part of the test plan (3.117) that describes the approach to testing (3.131) for a specific project, test level (3.108) or test type (3.130)

Иными словами, по этому стандарту стратегия тестирования считается частью плана. Также в ISO/IEC/IEEE 29 119 есть понятие «test policy» (3.118), в котором на уровне организации описываются общие цели, принципы и сфера применения тестирования.

ISTQB

В материалах ISTQB (Foundation, Advanced Level) встречаются упоминания и стратегии тестирования, и плана тестирования как отдельных понятий. Стратегию (или «подход к тестированию») можно рассматривать как «высокоуровневое описание», а тест‑план как документ, в котором отражаются ресурсы, сроки и детали. В некоторых организациях стратегия включается в план как отдельная глава, а в других существует сама по себе.

Старая практика: IEEE 829

Ранее широко упоминался стандарт IEEE 829, сейчас формально считающийся устаревшим. В нём план тестирования описывается детально, а вот «стратегия тестирования» напрямую не упоминается. В итоге в ряде компаний стратегия воспринималась либо как отдельный документ, либо как часть тест‑плана (по аналогии с современным ISO/IEC/IEEE 29 119).

Как у нас сейчас: есть и стратегия, и тест‑планы

После адаптации процесса у нас в компании используются оба артефакта:

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

Уровень: рассматривается на более высоком уровне и описывает общие подходы и методы тестирования.

Фокус: внимание уделяется методологии, управлению рисками и оценке процесса тестирования, критериям качества.

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

2. Тест‑план

Уровень: детализирован и специфичен для конкретного цикла или фазы тестирования.

Фокус: включает конкретные задачи, тест‑кейсы, ресурсы, ответственных и детали по конкретному продукту в определённый период.

Применение: разрабатывается под каждую стадию или спринт (например, регресс, проверка новой User‑story и т.д.).

Мы выбрали именно такой подход, потому что:

  1. Разный уровень детализации. Стратегия отражает общую идеологию и базовые принципы тестирования (риски, методологии, метрики качества), а тест‑планы «приземляют» всё это к конкретному проекту или спринту, где учитываются сроки, ресурсы и приоритеты.

  2. Гибкость и универсальность. Единая стратегия обеспечивает единообразие подхода в масштабах всей организации, даёт базовые инструменты и методики, которыми могут воспользоваться разные команды. При этом каждая команда создаёт свой тест‑план в зависимости от уникальных целей и бизнес‑требований.

  3. Прозрачность и контроль. Благодаря стратегии можно быстро объяснить, почему мы тестируем так, а не иначе. Тест‑планы же помогают формировать конкретные метрики, отслеживать прогресс, закрывать задачи и предоставлять отчётность в конце цикла.

  4. Удобное масштабирование. Если проект вырастает, появляются новые требования или модули, мы можем оперативно расширить тест‑планы, не переписывая при этом всю стратегию с нуля. Стратегия остаётся каркасом, а тест‑планы постоянно меняются под конкретные условия.

При желании мы могли бы сделать как в ISO/IEC/IEEE 29 119 и оформить стратегию как часть каждого тест‑плана. Но в текущем корпоративном процессе нам удобнее иметь общую стратегию (по сути, командный артефакт) и конкретные планы, которые на неё ссылаются. По итогам выполнения планов формируются отчёты и метрики.

Что бывает, если стратегии нет

До внедрения полноценной стратегии в нашей компании возникали проблемы:

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

  2. Критические баги «всплывали» после релиза. Из‑за отсутствия общего видения ключевые аспекты качества порой не проверялись.

  3. Хаотичное использование ресурсов. Время и силы команды уходили не всегда туда, куда нужно.

  4. Отсутствие критериев завершения тестирования. Либо зависали в бесконечном цикле тестов, либо останавливались слишком рано.

  5. Непрозрачность ролей и зоны ответственности. Многие участники процесса не понимали, что именно от них ждут.

  6. Дублирование усилий. QA, аналитики и разработчики повторяли работу друг друга.

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

Состав стратегии тестирования (по нашему шаблону)

Чтобы вы могли представить, как это выглядит, перечислю ключевые разделы нашего шаблона:

  1. Цели тестирования: что именно хотим достичь (улучшить производительность, повысить стабильность и т.п.).

  2. Подходы и методы: какие виды тестирования применяем (функциональное, нагрузочное, безопасность, интеграционное и т.д.).

  3. Инструменты: какие системы используем для автоматизации и ручных проверок.

  4. Критерии качества и завершения: когда продукт можно считать готовым к релизу.

  5. Риски и способы их минимизации: какие потенциальные проблемы могут возникнуть и как их предотвратить.

  6. Работа с командой тестирования: роли, компетенции и зоны ответственности каждого участника.

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

Проверяем, что наша стратегия закрывает важные цели

Прежде чем приступить к детальной разработке стратегии, полезно задать себе несколько вопросов (или проверить уже получившийся документ), чтобы удостовериться, что стратегия действительно нужна и решает основные задачи:

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

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

  3. Оптимизирует ли ресурсы? Если цели и сроки ясны, команда не станет тратить время на второстепенные проверки, а сосредоточится на ключевых аспектах качества.

Если видите, что стратегия обеспечивает эти (и другие важные для вас) пункты, значит, вы движетесь в правильном направлении.

Как начать писать стратегию, если её нет

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

Шаг 0. Определить цели тестирования и стейкхолдеров

  1. Соберите стейкхолдеров (тех, кто влияет или заинтересован в продукте/процессе).

  2. Выясните их критерии качества.

  3. Зафиксируйте историю проекта (какие были проблемы, на чём «обжигались»).

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

Шаг 1. Связать тестирование с бизнес‑метриками

  1. Для каждого критерия качества определите конкретные показатели.

  2. Обсудите приоритет функциональности: что является критически важным.

  3. Оцените риски и способы их минимизации.

Пример: заказчик хочет, чтобы релизы выходили чаще. Текущий цикл — 3 недели, желаемый — 2. Фиксируем эту цель. Смотрим, какие типы тестов нужно усилить (например, добавить контрактное тестирование, чтобы не ломать работу смежных модулей).

Шаг 2. Определить подходы и методы тестирования

  1. Исходя из архитектуры и технологического стека, а также потребностей заказчика, решите, какие виды тестирования применять: функциональное, интеграционное, нагрузочное, автоматизация UI/API и т. д.

  2. Ответьте на вопросы: что, где, когда, кто, как, чем тестирует? Какие есть зависимости? Какие инструменты?

Шаг 3. Уточнить командные роли и компетенции

В новой версии нашего шаблона есть отдельный блок «Работа с командой тестирования». Мы фиксируем:

  1. Роли и ответственность (кто тест‑менеджер, кто автоматизатор, кто собирает отчётность).

  2. Компетенции (кто умеет работать с конкретным стеком или инструментом).

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

Шаг 4. Согласовать стратегию с командой разработки

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

  1. Проведите презентацию или воркшоп, где расскажете, почему именно такой подход к тестированию необходим.

  2. Уточните точки интеграции: как тестирование будет взаимодействовать с CI/CD, как и когда передавать сборки, где хранить отчёты о дефектах и т.д.

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

Общие рекомендации по внедрению

  1. Начинайте с базовой версии: не стремитесь сразу сделать шедевр.

  2. Инвестируйте время на старте: хорошо проработанная стратегия сэкономит вам уйму сил в дальнейшем.

  3. Делайте стратегию «живой»: пересматривайте и корректируйте её по мере изменений в продукте или процессах.

Мой подарок

Ссылка на полный шаблон
(Этот шаблон можно адаптировать под ваш проект или продукт.)

Итоги

Стратегия тестирования — это мощный инструмент, который помогает:

  • Выстроить общие принципы тестирования в компании.

  • Скоординировать работу команд.

  • Избежать множества проблем, связанных с непониманием целей и рисков.

Если вы всё ещё сомневаетесь, нужен ли вам этот «сферический конь», попробуйте взглянуть на собственные процессы и ответить на вопросы: все ли понимают, как и что мы тестируем? Как измеряем прогресс? Какие риски учтены заранее? Если ответы неочевидны — значит, стратегия тестирования вам точно пригодится.

Желаю удачи в экспериментах и до встречи в следующих статьях!


ссылка на оригинал статьи https://habr.com/ru/articles/898362/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *