Консалтинг-кейсы

Работа с ускорением тестирования

Тестирование — одно из самых частых мест, где возникают проблемы, которые тормозят разработку и увеличивают вероятность появления багов.
В рамках одного из проектов я сосредотачивался именно на скорости поставки и акцентировал внимание на стадии QA (Quality Assurance).
Следуя системному подходу, я расписал общий процесс поставки. Он выглядит следующим образом:
Тестирование — достаточно поздний этап общего процесса. Проблемы в этом этапе приводят к необходимости возвращаться на шаги ранее. Каждый такой шаг занимает время, а также требует повторного прохождения последующих шагов.
Основные проблемы здесь:
  1. Некорректная передача задачи в тестирование;
  2. Тестирование — "бутылочное горлышко".

Некорректная передача задачи в тестирование

После анализа выявились следующие проблемы:
  • Разработчики передавали в тестирование «голую» задачу: без требований, описания решения и пояснений к тестированию. Тестировщикам приходилось тратить время на выяснение деталей и поиск требований;
  • Иногда разработчики просто не проверяли задачи: в них было множество багов, что заставляло отправлять их обратно в разработку несколько раз.

Тестирование — "бутылочное горлышко"

Задачи скапливались на этапе тестирования, ожидая, пока кто-то из тестировщиков их возьмет.
После анализа были выявлены следующие корневые причины:
  • Некорректная передача задач (см. выше), что увеличивало требуемое время QA-инженера на одну задачу;
  • Каждая задача тестировалась на одном тестовом стенде: периодически здесь возникала очередь.

Метрики

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

Для каждой метрики было выбрано одно число: 95-ая и 75-ая перцентиль для всех задач.
Цифры были следующие:

Количество возвратов:
  • 95-ая перцентиль — 13 возвратов. Это означает, что у 95 процентов задач количество возвратов составляло 13 или менее;
  • 75-ая перцентиль — 9 возвратов. Это показывает, что у 75 процентов задач количество возвратов было 9 или менее.

Время в тестировании:
  • 95-ая перцентиль — 15 дней. Это означает, что у 95 процентов задач время в тестировании составляло 15 дней или меньше;
  • 75-ая перцентиль — 10 дней. Это показывает, что у 75 процентов задач время в тестировании было 10 дней или меньше.

Решение

Для решения проблемы мы предприняли несколько мер.

  1. Рассказали разработчикам, как правильно передавать задачи в тестирование.
  2. Оформили совместно с лидерами команды несколько тикетов в качестве референсов и периодически проверяли процесс их выполнения.
  3. Запланировали регулярную проверку процесса каждые 2 недели на протяжении ближайших двух месяцев, а затем — раз в месяц.

В дополнение к этому:
  1. Добавили обязательные поля в тикетах Jira с пояснением для тестировщика. Без их заполнения нельзя было передвинуть тикет в стадию QA. Такой шаг можно считать защитным рубежом, предотвращающим ошибки.
  2. Реализовали техническое улучшение: доработали автосборку в CI/CD системе и дополнили документацию. Это позволило тестировщикам в большинстве случаев проверять фичи локально, без необходимости использовать тестовый стенд. В результате снизилась нагрузка на загруженный тестовый стенд.

Проблемы, с которыми столкнулись

Самая основная проблема здесь — это сопротивление изменениям, особенно если ранее все было "как обычно" в течение долгого времени.

В частности, я столкнулся с нежеланием разработчиков принять новый формат передачи тикетов.

Чтобы решить эту проблему, мы использовали метод "продажи" изменений — вместе с лидерами команды рассказали разработчикам о преимуществах нового формата: если все необходимые данные будут указаны сразу в задаче, то они будут меньше отвлекаться и реже получать напоминания.

Сначала была проведена общая презентация, а затем еще два индивидуальных собеседования с особенно упорными инженерами: их возражения были обсуждены и разобраны, в результате чего новый формат был принят.

Результаты

К концу первого квартала мы заметили значительное снижение целевых метрик: количество возвратов из тестирования снизилось до 10 (95-ая перцентиль) и 5 (75-ая перцентиль), а время в тестировании — до 11 дней (95-ая перцентиль) и 5,5 дней (75-ая перцентиль). Данные изменения являются достаточно существенными. Это не удивительно, так как это было "низко висящим плодом", который удалось достать без больших затрат времени.

В течение следующего квартала, вместе с командой, мы достигли дополнительного снижения времени тестирования на 35%, что позволило сократить количество возвратов до 4 (95-ая перцентиль).

Итого

  • Используя системный подход и теорию ограничений (см. Цель: Процесс непрерывного совершенствования), был проанализирован процесс поставки, найдены причины, в частности замедление на стадии тестирования;
  • Для замеров использовались метрики количества возвратов и время пребывания в стадии QA;
  • Основными решениями стали изменение процесса передачи задач от разработчика к тестировщику, а также снижение нагрузки на тестовый стенд;
  • Все проблемы и препятствия были успешно решены;
  • В результате получено ускорение более чем на 50% на стадии тестирования.