Optimize testing

«Низкое качество означает высокие затраты»

— Эдвардс Демин

Согласны? Узнали? Мне кажется это одним из важнейших факторов создания проектов и продуктов, их бюджетирования и сроков. Меня зовут Андрей Непряхин, я руковожу отделом QA в компании AGIMA и расскажу, как мы подошли к процессу тестирования, чтобы сделать его более прозрачным, отлаженным и менее дорогостоящим. Но главная цель — повысить качество продукта. Это влияет на несколько очевидных метрик: лояльность наших клиентов, которые используют сайт, сервис или мобильное приложение, и выстраивание теплых и долгих отношений с нашим заказчиком, если мы говорим о разработке на аутсорсе.

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

Изучаем ситуацию

Прежде чем приступить к созданию плана и выстраиванию стратегии важно понять, где мы находимся сейчас. Для этого воспользуемся Test Maturity Model. Она поможет определить уровень «‎зрелости» наших процессов, чтобы открыть глаза на слабые стороны и масштабность предстоящей оптимизации. Модель включает в себя пять уровней с конкретными характеристиками каждого.

Уровень первый: начальный

• Нет четкой последовательности действий — процесс хаотичен.
• Нет стандарта качества.
• Результаты малопредсказуемы.
• Недостаточная квалификация специалистов.

Уровень второй: управляемый

• Есть стратегия и общая концепция тестирования.
• Есть план тестирования.
• Есть отслеживание и контроль качества.
• Разрабатываются и проводятся тесты.
• Есть среда тестирования.

Уровень третий: определяемый

• Тестирование полностью интегрировано в процесс разработки.
• План тестирования составляется на самом раннем этапе.
• Организованное тестирование.
• Оно имеет специальную программу подготовки.
• Вводится нефункциональное тестирование.
• Применяется оценка работы коллегами.

Уровень четвертый: измеряемый

• Вводятся метрики качества тестирования.
• Метрики качества продукта.
• Проверка работы коллегами вводится на начальные этапы и становится полноценной частью оценки качества.

Уровень пятый: оптимизированный

• Интегрирован процесс предотвращения ошибок.
• Для контроля процесса тестирования применяются статистические методы.
• Оптимизация тестирования становится стандартной практикой рабочего процесса.

Что ж, первый шаг — это изучить эти модели и проанализировать, на каком этапе находитесь вы сейчас. 4 года назад и с нами такое было: мы провели ретро и поняли, что находимся на первом уровне — четко угадывались проблемы, которые присущи этому левелу: хромала коммуникация между разработчиками и тестировщиками, имели дело с непрозрачным процессом тестирования, не было единого способа оформления тест-кейсов (если этого нет, то об их автоматизации можно и не мечтать), отсутствовал контроль за тестировщиками, а это значит, что встречалась халтура и некачественная работа. Мы начали исправлять ситуацию. И я расскажу, как мы прошли все уровни, и что нужно делать на каждом из них.

Используем готовый подход

PDCA (Plan-Do-Check-Act) — очень удобный фреймворк. Это общий гайд для улучшения процессов, который состоит из четырёх подробно описанных шагов внедрения чего-либо. Всё, как мы любим. По-другому этот подход называют циклом Шухарта-Деминга. Его придумали как раз для управления качеством.

Давайте посмотрим на процесс:

1. Планируем — описываем цели и действия для их достижения. Предполагаем ресурсозатраты, их выделение и распределение.


2. Выполняем — делаем то, что планировали.


3. Проверяем — собираем всю необходимую информацию о проделанной работе. Анализируем процесс, находим ошибки, отклонения и их причины.


4. Действуем — если всё прошло согласно изначальному плану, то внедряем его в наш цикл работы. Если нет, то вносим корректировки и возвращаемся к первому шагу. И теперь так всегда.

А вот, что мы делали по PDCA

1. На этапе планирования


• Собрались с командой и обсудили текущие проблемы, которые хотели исправить.
• Определили цели. Делали это по концепции SMART. Получили ясные и измеряемые пункты с чётко определенными временными границами.
• Описали действия и приоритизировали их.


2. На этапе выполнения


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


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


3. На этапе проверки


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

Что получили?

• Повышенное качество продукта.

Исправленные и отмененные дефекты за один месяц на ecommerce-проекте
Серьезность дефектов

Результаты тестирования версии и регресс

• Открытый и измеряемый процесс тестирования, который теперь в разы проще контролировать и улучшать и в дальнейшем переходить к следующему левелу.
• Ускоренный онбординг новых сотрудников. Благодаря регламентам, им будет проще подключаться к работе.
• Доверие заказчика. Благодаря ретро-встречам он может оценить результаты нашей работы и в любой момент узнать реальное качество продукта.
• Экономию. Сократили количество человеко-часов на регресс с 20 до 10.
• Время на актуализацию регрессионной модели и подготовку к автоматизации тестирования.
• Переход на второй уровень Test Maturity Model — управляемый. О том, как мы проходили этот уровень, я расскажу в следующей статье.

Почему всё это нужно делать

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

Автор иллюстраций — Наталья Шарова, дизайнер AGIMA.

Комментарии и обсуждения статьи в нашем блоге на Хабр.