Как стать автором
Обновить
164.84
Рейтинг
AGIMA
Крупнейший интегратор digital-решений

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

Блог компании AGIMA Тестирование веб-сервисов *

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

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

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

Теги:
Хабы:
Всего голосов 4: ↑4 и ↓0 +4
Просмотры 4.6K
Комментарии 8
Комментарии Комментарии 8

Публикации

Информация

Сайт
www.agima.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
Кристина Ляпцева