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

Еще пару лет назад я и мой предыдущий руководитель (Ваня, привет!) остро ощутили необходимость анализа дефектов с прода. В команду тестирования входило много junior‑специалистов, им было необходимо понимать, что важно и на что смотрит пользователь в первую очередь. Это положило начало новому процессу, который состоял в перепроверке инцидентов с прода. Я взял эту практику за основу, добавил своего, внедрил и допилил напильником)

Цели анализа инцидентов с продакшена

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

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

• Анализ корневых причин (Root Cause Analysis): глубокое изучение причин возникновения инцидентов с целью разработки мер по предотвращению их повторения в будущем.

• Повышение удовлетворенности пользователей: быстрое выявление и исправление ошибок обеспечивает стабильную работу приложения и положительный опыт для пользователей.

• Сохранение репутации компании: своевременное (ну по крайней мере, мы стараемся как можно быстрее) устранение багов предотвращает негативные отзывы и поддерживает доверие к продукту.

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

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

• Улучшение процесса приоритизации: разработка более точной и объективной системы приоритизации инцидентов, учитывающей не только серьезность проблемы, но и ее влияние на пользователей и бизнес.

Как мы анализируем инциденты с продакшена

Локализация дефекта

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

Создание кейса

QA‑специалист, который анализирует тикет, создает соответствующий тест‑кейс в TMS. Кейс помещается в секцию «Кейсы проверки инцидентов» => «Номер версии продукта» с названием, включающим ID и наименование тикета в проекте техподдержки. В кейсе также указывается версия приложения, в которой был обнаружен баг.

У кейса может быть два статуса:

• «Не готов»: кейс создан, но еще не полностью готов к использованию в регрессионном тестировании.

• «Готов»: кейс понятен, стабильно воспроизводится и готов к включению в регрессионный набор.

Ссылка на созданный кейс добавляется в комментарий к тикету в багтрекинговой системе. Это обеспечивает прозрачность и облегчает коммуникацию между QA и разработчиками.

Исправление бага

После исправления бага разработчиком QA‑специалист проверяет кейс и обновляет его статус в TMS:

• «Готов»: кейс добавляется в папку с названием версии, в которой был обнаружен и исправлен баг. Это позволяет нам отслеживать, какие баги были исправлены в каждой версии и проводить регрессионное тестирование для соответствующих версий приложения.

• «Не готов»: кейс дорабатывается, если он нестабилен или непонятен.

Верификация перед регрессионным тестированием

За день до начала регрессионного тестирования мы проводим дополнительную верификацию списка исправленных дефектов с прода на выпускаемой версии. Это позволяет:

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

• Обработать возможные упущения: если кейс не был создан, QA-специалист оперативно его создает и добавляет в регрессионный набор.

Регрессионное тестирование

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

В регрессионный набор включаются кейсы, отвечающие следующим критериям:

• Статус «Готов»: кейс полностью готов к использованию.

• Дата последнего изменения кейса:

  • Менее двух месяцев: кейсы, измененные недавно, обязательно включаются в регрессионный набор.

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

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

Анализ «старых» кейсов

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

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

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

Заключение

Анализ багов с прода — хорошая практика, и наш подход, основанный на стандартизации, прозрачности, оптимизации, структурности и дополнительной верификации, позволяет постоянно совершенствовать процесс тестирования. Мы работаем над тем, чтобы улучшить анализ багов с прода, поскольку это повышает качество нашего продуктов и удовлетворенность пользователей. Ввиду ограниченности ресурсов — количество кейсов непрерывно растет, видов проверок тоже становится больше — мы придерживаемся метода Ганбару (усердие и настойчивость), практики Кайдзен (непрерывное совершенствование), а также принципов Blameless PostMortems (разбора инцидента без поиска виновных), стараемся акцентировать внимание на скорейшем исправлении дефектов насколько это возможно.

Преимущества нашего подхода:

• Структурированность: сортировка багов по версиям приложения позволяет нам отслеживать историю исправлений, плюс удобно ориентироваться.

• Стандартизация: четкие правила и процессы обеспечивают согласованность и эффективность анализа багов.

• Прозрачность: использование багтрекинговой системы и TMS обеспечивает доступность информации для всех участников процесса.

• Двойная проверка: верификация перед регрессом позволяет избежать упущений и гарантирует улучшение регрессионного набора.

• Итерационный подход: разделение этапов анализа и интеграции в процесс тестирования позволяет совершенствовать проверки практически без напряжения и выделения дополнительных ресурсов.

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

Планы по улучшению процесса:

• Добавление тегов для кейсов по «вернувшимся ошибкам» и «проанализированным»: нужно внедрить теги для кейсов, которые неудовлетворительно прошли регрессионные тесты после исправления, и для кейсов, успешно преодолевших анализ. Эту практику я придумал во время написания данной статьи)

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

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

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

• Использование технологий искусственного интеллекта (AI): ну и как же без него) применение AI для автоматизации некоторых аспектов анализа инцидентов, например, классификации багов, определения приоритета и предложения возможных решений, аналитической работы по улучшению кейсов и покрытия и прочего сбора статистики.

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