Как повысить качество покрытия релизов тестами. Инструкция Lamoda Tech

103 7 min

Столкнувшись с парадоксом пестицида, компания Lamoda Tech выработала и применила собственную стратегию для более качественного покрытия релизов тестами. 

В предыдущей статье тимлид команды разработки Наталья Филиппова поделилась практикой сочетания разных видов тестовой документации и написания автотестов по предварительно составленным тест-кейсам. Но остался вопрос о том, как эффективно покрывать релизы тестами. Делимся опытом и инструкцией Lamoda Tech.

Как повысить качество покрытия релизов тестами

Принцип кластеризации дефектов и закон Парето

Один из принципов, на который стоит опираться, чтобы сделать тестирование более эффективным, это кластеризация дефектов. Его определение, сформулированное ISTQB, звучит так: 

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

Простыми словами, мы можем предположить, что малое количество модулей содержит наибольшее количество багов. 

Многие также опираются на закон Парето, который предполагает, что 20% модулей содержат 80% багов. Поэтому фокусирование на тестировании ключевых 20% компонентов предположительно приведет к обнаружению большинства критических ошибок.

Как мы оцениваем приоритет багов

Мы решили пойти дальше и выработать систему, которая поможет точно определить наиболее и наименее забагованные модули. Для этого мы проанализировали наши баги и выставили им баллы. Проще говоря, определили их приоритет и перевели его в цифры.

0.5 Minor
1 Major
2 Critical

Полбалла получают баги, которые не требуют фикса здесь и сейчас. Их мы отправляем в бэклог. 

Один балл — если баг необходимо пофиксить в ближайшем релизе. Такая проблема не подразумевает финансовых потерь.

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

По этой схеме нам удалось за четыре часа оценить около 150 багов, накопившихся за полтора года. После этого можно составлять таблицу плотности дефектов. 

Как составить таблицу плотности дефектов

Таблица плотности дефектов

В строках таблицы прописаны в основном таски, в некоторых случаях — названия багов. 

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

К таким багам относятся наиболее важные для бизнеса: например, если на странице оформления заказа случается сбой. Поэтому баги, отмеченные названием, автоматически получают два балла по приоритету.  

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

Анализ плотности дефектов

Составив таблицу и выставив баллы каждому багу, мы смогли проанализировать процент забагованности каждого компонента. Как оказалось, результат приблизился к выводам закона Парето: в нашем случае около 30% компонентов имели около 70% багов. 

Анализ плотности дефектов

Наиболее забагованным компонентом оказался ПП — страница продукта. Она содержит множество модулей: рекомендации, отзывы, вопросы и много чего еще, поэтому результат нас не удивил. Зато удивило то, что самым стабильным компонентом оказался Поиск: за полтора года в этом компоненте был выявлен всего один баг. 

Порядок тестирования модулей

После того, как был проведен анализ плотности дефектов, стало понятно, в каком порядке проводить тестирование: от ПП к Главной. 

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

Для каждого второго-третьего модуля мы уменьшаем количество проверок, потому что всё протестировать невозможно — это еще один принцип тестирования. Этот подход помогает сэкономить время на прохождение всего цикла релиза.  

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

Как покрывать релиз тестами. Краткая инструкция

Шаг 1. Составляем таблицу плотности дефектов. Вы можете применить наш подход к поиску приоритетных багов с помощью балльной оценки. 

Шаг 2. Проводим анализ дефектов. Это поможет определить самые забагованные модули — с них и следует начинать тестирование.

Шаг 3. Обновляем существующую документацию. Как это сделать, описано в предыдущей статье

Шаг 4. Расширяем покрытие тестирования. Самые забагованные модули покрываем тестами максимально плотно, постепенно снижаем количество проверок. 

Шаг 5. Проводим повторное тестирование. Для лучшего результата — несколько раз. 

Напоследок поделюсь опытом Lamoda Tech: тестирование релиза одной платформы у нас занимает восемь часов, а гибридных тестов 70. Выработанная в нашей компании система помогает не только повысить качество тестирования, но и уменьшить время на релиз.

Была ли статья полезной?