Как повысить качество покрытия релизов тестами. Инструкция Lamoda Tech
Столкнувшись с парадоксом пестицида, компания 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. Выработанная в нашей компании система помогает не только повысить качество тестирования, но и уменьшить время на релиз.
