Чтобы сделать продукт качественнее, нужно каждое утро натощак… Кликбейта не будет: оптимизируем тестирование

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

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

Согласны? Узнали? Мне кажется это одним из важнейших факторов создания проектов и продуктов, их бюджетирования и сроков. Меня зовут Андрей Непряхин, я руковожу отделом 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.