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

57
#Аналитика 31 августа 2021
  • Андрей Непряхин

    Руководитель отдела качества

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

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


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

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

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


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


Test Maturity Model

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


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

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


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

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


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

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


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

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


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

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

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


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

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

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

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

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

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


PDCA

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


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

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

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

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

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

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

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

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


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

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


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


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

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

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


  • Андрей Непряхин

    Руководитель отдела качества

Блог

# Аналитика 24 сентября 2020

Как правильно тестировать гипотезы для цифрового продукта, чтобы внедрять новые фичи

Олег Рудаков
0 / 0
+7 495 981-01-85 + Стать клиентом
Услуги Кейсы