В данной статье предлагаю рассмотреть, кто является стэйкхолдерами и потребителями сервиса тестирования. Для этого необходимо ответить на следующие вопросы:

• Каким образом, на каком этапе и с кем взаимодействует команда тестирования в процессе разработки ПО?
• Что различные участники процесса разработки ожидают от команды QA и как этого достичь?
  

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

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

• Качество – это очень субъективная характеристика. У каждого будет свое определение качества, свое описание для качественного продукта.
• Каждый человек может считать тот или иной предмет, продукт, сервис качественным или некачественным исходя из своих потребностей, ценностей и приоритетов. Одна и та же вещь одновременно может быть качественной для одного и некачественной для другого.
  

Если все обобщить, то получится такое определение: качество – это в первую очередь соответствие ожиданиям. Иными словами, это субъективная оценка, и зависит от того, кто ее дает.

Какой из этого можно сделать вывод? Чтобы добиться высоких оценок качества, необходимо понимать, кто и на основании чего эти оценки делает. Следовательно, если мы хотим получить качественный программный продукт, то нам нужно понимать ожидания всех, кто участвует в разработке и эксплуатации ПО. Необходимо уметь работать со всеми участниками и на всех этапах процесса разработки.

Какими бывают ожидания от качества ПО?
Понимание качества ПО отличается у разных участников процесса разработки. То же самое касается ожиданий от команды тестирования процесса QA в целом. Рассмотрим все предъявляемые требования в виде таблицы.



На каких этапах разработки подключаются тестировщики?
Короткий ответ – на всех. Как мы выяснили, команда тестирования взаимодействует со всеми участниками процесса разработки ПО. Если в рамках процесса выделены отдельные этапы и фазы, то тестировщики подключаются в рамках каждой из них.


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



Данные виды активностей будут присутствовать и в каскадной, и в итеративной разработке:

• в Waterfall это будут отдельные этапы/фазы разработки;
• в Agile это могут быть различные типы деятельности в рамках одной итерации.
  

Как QA взаимодействует с участниками разработки ПО?
На каждом этапе при работе с каждым типом задач важно использовать свои методы взаимодействия с участниками процесса разработки. Эффективным будет чередование и/или сочетание различных подходов и практик. Это позволит реализовать ожидания стейкхолдеров от качества ПО и от работы команды тестирования.
Рассмотрим по порядку, как может быть построено взаимодействие команды тестирования с остальными участниками процесса.

1. QA в рамках анализа и проработки требований:
• Заказчики и бизнес-аналитики:
– Обсуждение end-to-end-проверок и бизнес-процессов.
• Аналитики и разработчики:
– Ревью чек-листов, подготовленных тестировщиками;
– Разработка тестовой модели и стратегии тестирования;
– Совместная оценка и планирование задач.
• Внешние ИТ-команды:
– Выяснение интеграционных зависимостей между системами;
– Планирование совместного использования среды тестирования.
• Команда поддержки тестовых сред (среды разработки и тестирования ПО):
– Обсуждение требований к средам тестирования: конфигурация, данные, производительность;
– Планирование работ с тестовой средой: сроки, права доступа.

2. QA в процессе разработки и отладки ПО:
• Заказчики и бизне-аналитики:
– Демонстрация новой функциональности;
– Уточнение актуальности приоритетов по ходу разработки.
• Аналитики и разработчики:
– Обсуждение и формирование вариантов данных для тестирования;
– Ревью/тестирование документации: тех. задания, пользовательские инструкции, help и т.д;
– Анализ ошибок, найденных в процессе отладки ПО.
• Внешние ИТ-команды:
– Получение данных и условий для проверки точек интеграции;
– Настройка и тестирование интеграции с использованием «заглушек».
• Команда поддержки тестовых/продуктивных сред:
– Установка ПО в среде тестирования и настройка интеграции с внешними системами;
– Разработка и проверка инструкций по установке для тестовой среды;
– Планирование подготовки превью среды (доступы, роли, данные) для интеграции и приемки.

3. QA во время проверки интеграции и UAT:
• Заказчики и пользователи:
– Организация приемочного тестирования UAT (User Acceptance Testing);
– Воспроизведение и анализ ошибок, найденных во время UAT;
– Сбор обратной связи по итогам приемочного тестирования.
• Аналитики и разработчики:
– Подготовка данных для end-to-end-тестирования;
– Анализ и устранение ошибок интеграции.
• Внешние ИТ-команды:
– Выполнение совместного end-to-end-тестирования.
• Команда поддержки тестовых/продуктивных сред:
– Установки ПО в превью среде;
– Разработка и проверка инструкций по установке для продуктивной среды;
– Настройка интеграции со связанными системами;
– Проверка быстродействия ПО / функционала в превью среде.

4. QA на этапе подготовки и выпуска релиза:
• Заказчики и пользователи:
– Участие в пилоте (при необходимости).
• Аналитики и разработчики:
– Подготовка инструкций по установке в продуктивную среду.
• Внешние ИТ-команды:
– Участие в end-to-end-тестировании при DryRun.
• Команда поддержки продуктивных сред:
– Проведение DryRun и контрольного Smoke-тестирования в превью среде;
– Поддержка процесса установки во время DryRun и основного релиза.

5. QA в рамках поддержки ПО в продуктивной среде:
• Заказчики и пользователи:
– Получение и анализ фидбэка по итогам релиза и эксплуатации ПО;
– Корректировка пользовательских инструкций.
• Аналитики и разработчики:
– Воспроизведение, анализ и исправление ошибок в рамках выпущенной функциональности;
– Анализ и исправление «технических» инцидентов от поддержки;
– Ретроспектива команды по итогам релиза: внутренняя и внешняя.
• Внешние ИТ-команды:
– Анализ и исправление интеграционных инцидентов;
– Пополнение базы знаний новой информацией по поводу интеграционного взаимодействия систем.
• Поддержка:
– Работа над ошибками, выполнение анализа: процесса установки, производительности после релиза, архитектуры ПО;
– Доработка инструкций по установке для продуктивной среды.

Кто тестирует кроме тестировщиков?
Как известно, тестированием в рамках процесса разработки ПО занимаются не только тестировщики. Описание различных этапов, а также явных и неявных участников процесса тестирования можно посмотреть тут. На схеме показано, кто еще принимает участие в тестировании помимо непосредственно команды QA.