Приведи пример серьезной ошибки на опыте

Пример серьёзной ошибки: «Тихий» сбой функционала критического отчёта

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

Суть проблемы и контекст

Функционал отчёта был старым, с монолитной архитектурой. Команда разработки провела рефакторинг и декомпозировал один огромный метод, разбив его на несколько сервисов. Логически всё работало идентично, юнит-тесты разработчиков проходили успешно. Основная проверка в QA фокусировалась на новых flashy-фичах релиза, а тестирование отчёта свелось к санитарной проверке (smoke test): "Отчёт открывается? Данные за последний день отображаются? Сумма сходится с примером? Готово".

Ошибка была коварной: новый код корректно обрабатывал платежи в статусах SUCCESS и FAILED, но из-за ошибки в условии фильтрации в одном из новых сервисов полностью игнорировал платежи в статусе PENDING, которые были проведены банком после определённого времени отсечки. В обычные дни их объем был менее 0.5% от общего числа, и на общую сумму за день это почти не влияло. Поэтому наш сценарный тест с несколькими тестовыми платежами разницу не выявил.

Момент обнаружения и масштаб

Ошибка была обнаружена спустя три недели после релиза самим клиентом — крупным ритейлером. В конце месяца при сверке у них образовалась огромная расходимость. Проблема была не в итоговой сумме за месяц (pending-платежи со временем переходили в success и попадали в отчёты следующих дней), а в юридической и аудиторской значимости данных на конкретную дату. Клиент требовал восстановить корректные отчёты за каждый из прошедших 21 дня.

Коренные причины (Root Cause Analysis)

На ретроспективе мы выявили несколько ключевых провалов:

• Неадекватный объем тестирования legacy-функционала: Критический бизнес-процесс был проверен только с помощью смоук-теста, не было регрессионного и глубинного (deep dive) тестирования.
• Отсутствие тестов на граничных и нестандартных данных: Все тестовые сценарии использовали "идеальные" данные. Не было проверки на всех возможных статусах операций.
• Плохая наблюдаемость (Observability): В логах нового сервиса не было информации об объёме обработанных/отфильтрованных записей. Мы не могли увидеть, что 0.5% данных "испарились".
• Слабая связь с бизнес-аналитиком (BA): QA и разработчики не до конца понимали, как именно клиенты используют этот отчёт для ежедневной сверки, и почему важен снимок данных на конец дня (EOD snapshot).

Исправления и внедрённые практики

1. Немедленно: Разработчики исправили условие фильтрации. Мы совместно с BA и поддержкой клиента разработали скрипт для пересчёта и восстановления исторических отчётов.

   # Пример логики исправления (упрощённо)
   # Было: if payment.status in ['SUCCESS', 'FAILED']
   # Стало: if payment.status in ['SUCCESS', 'FAILED', 'PENDING']
   
   def filter_payments_for_report(payments):
       """Фильтрует платежи для включения в ежедневный отчёт."""
       # КРИТИЧЕСКИЙ БИЗНЕС-ТРЕБОВАНИЕ: все платежи, созданные до EOD.
       relevant_statuses = {'SUCCESS', 'FAILED', 'PENDING'}
       return [p for p in payments if p.status in relevant_statuses and p.created_at < EOD_CUTOFF]
   

2. Стратегически:

    *   **Введён «Хит-лист критического функционала» (Critical Feature Checklist):** Для любого изменения в коде, затрагивающего пункты из этого списка, стал обязательным **полный регрессионный тест-кейс** с утверждением BA.
    *   **Усилено тестирование на основе данных (Data-Driven Testing):** Для ключевых отчётов мы начали готовить тестовые наборы, которые покрывали все возможные комбинации статусов, валют, периодов.
    *   **Внедрены канареечные данные (Canary Data) в тестовых средах:** В БД тестового стенда предзагружается большой набор "реалистичных" данных, включая пограничные случаи.
    *   **Улучшено логирование:** Критические сервисы начали логировать не только ошибки, но и метрики: "обработано N записей, проигнорировано M записей по причине X".
    *   **Обязательные сессии «Триады» (Dev + QA + BA)** для любого рефакторинга бизнес-критичного модуля.

Вывод

Эта ошибка стала для меня болезненным, но бесценным уроком. Она показала, что главная опасность часто исходит не от нового кода, а от старого, который "тихо" сломался. Ответственность QA — быть защитником целостности системы в целом, особенно на стыках и в областях, которые все считают стабильными. Тестирование должно быть сфокусировано на рисках, а не на объёме, и глубокое понимание бизнес-процесса клиента так же важно, как и техническое понимание системы.