Автор: Арун Вишванатан (Arun Vishwanathan)
Оригинал статьи
Перевод: Ольга Алифанова

Проблема: отладка билдов в быстро меняющемся мире

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

Представим, что команда обнаружила баг в недавней версии продукта. Где-то по пути что-то пошло не так. Но как понять, когда именно всё начало ломаться?

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

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

Почему отладка в масштабе сложна

Вот в чём сложность, если простыми словами:

• Слишком много версий: между последней стабильной версией и той, где проявился баг, может быть 50 или 100 версий.
• Полные прогоны тестов занимают много времени: выполнение полного набора тестов может быть долгим.
• Ограниченные ресурсы: в распоряжении может быть всего несколько машин или устройств для запуска тестов.
• Давление быстро исправить баги: инженерам нужны быстрые ответы, чтобы оставаться продуктивными и не срывать сроки релизов.

Традиционно тестировщики медленно проходили каждую версию по очереди, чтобы найти момент появления бага. Команде понадобился более быстрый подход.

Реальная потребность

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

«Можете сказать, в какой версии эта проблема появилась впервые?»

Определить это сложнее, чем кажется. Я попытался решить эту задачу эффективнее с помощью техники, которую я называю 5-точечным параллельным поиском, особенно с учётом доступа к нескольким ресурсам.

Более быстрый подход: 5-точечный параллельный поиск

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

Если на последних фотографиях человека уже нет, а на более ранних он ещё есть, диапазон уже начинает сужаться. Дальше остаётся работать с меньшим количеством вариантов на каждом шаге. В этом и состоит идея подхода.

Пошагово

1. 1. Найдите начальные точки

• Выберите два билда:
  • C: последняя стабильная версия, где всё работало
  • Y: версия, в которой баг был впервые замечен

1. 2. Выберите пять билдов между ними:

• Эти билды должны быть равномерно распределены по времени между последним стабильным билдом и текущим, как метки на временной шкале.
• Назовём их X1, X2, X3, X4 и X5.

1. 3. Запустите тесты на всех пяти билдах одновременно:

• Используйте столько устройств, сколько вам доступно.
• Кэшируйте или сохраняйте результаты, чтобы не повторять тесты.

1. 4. Ждите и наблюдайте:

• По мере поступления результатов определите:
  • Самый ранний падающий билд (EFB): первая версия, в которой появляется баг
  • Самый поздний проходящий билд (LPB): последняя версия, где всё ещё работает.

1. 5. Сузьте область поиска:

• Если версия падает — смотрите более ранние.
• Если проходит — переходите к более поздним.
• Повторяйте процесс в новом, более узком диапазоне.

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

Почему 5-точечный параллельный поиск быстрее

Этот метод сокращает количество необходимых тестов:

• Старый способ: может потребовать 50+ тестов, по одному за раз.
• Новый способ: обычно находит проблему за 3–5 итераций благодаря параллельному тестированию и более умному поиску.

Реальные результаты

Что удалось получить на практике:

• Сокращение времени отладки на 70–80 процентов.
• Разработчики и тестировщики могут быстрее обмениваться информацией и оперативно действовать.
• Баг-репорты становятся более понятными и привязаны к конкретным изменениям в коде.

Что важно учитывать

Этот метод работает лучше всего, когда:

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

Ограничения эффективности

• Некоторые тесты стартуют позже из-за времени на подготовку.
• Если устройств мало, преимущества параллельного тестирования снижаются.
• Метод работает как увеличительное стекло: он наиболее полезен, когда известен диапазон, в котором появился сбой.

Заключение: быстрее ответы — довольнее команда

Метод 5-точечного параллельного поиска повышает эффективность отладки за счёт:

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

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

В следующий раз, когда кто-то спросит «Когда появился этот баг?», ответ может быть готов за часы, а не за дни.

Дополнительная информация

• Are You Seeing RED? Restoring Reliability To Test Results, Jose Carrera
• Revisited: The Tester’s Survival Guide to Joining a Continuous Delivery Project, Amy Phillips
• Agile Test Management within Continuous Integration, Angie Jones