Баг на продакшене — не всегда вина QA

Если вы давно в цехе, то знаете: продакшен-баг — это не «конец света», но всегда лишние часы разбирательств, горячие переписки и вечный вопрос «кто виноват». Чаще всего пальцем показывают на тестирование. Но качество не рождается в отчёте о тестах — оно закладывается с первых строк требований и кода. Да, QA всегда является стороной, несущей явную ответственность за итоговое качество. Но в действительности вся команда в той или иной степени отвечает за то, в каком виде конечный пользователь увидит продукт.

Качество начинается не на этапе тестирования, а на этапе замысла и архитектуры. Бизнес-аналитик формирует, что именно мы делаем и зачем. Разработчик превращает это в код. QA проверяет соответствие ожиданиям и защищает пользовательскую ценность. DevOps обеспечивает предсказуемую и безопасную доставку на прод.
Любой сбой в этой цепочке — размытые требования, спешка, недоговорённости, конфигурационный хаос — и дефект легко долетает до пользователей, даже если QA сделал максимум. Поэтому смотреть на качество нужно как на совместный процесс, а не «последнюю линию обороны».

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

В качестве примера приведём кейс:
Пожелание заказчика было сформулировано примерно как «Импорт CSV должен быть “как в прошлой системе”». В старой системе пустая строка означала обнуление поля. Заказчик же ожидал, что пустое поле будет проигнорировано. В итоге, из-за недостатка его экспертизы в том, как работал legacy код, из-за того, что команда не согласовала детали этого сценария, и из-за отсутствия качественной аналитики заказчик стёр данные в тысячах записей. Разумеется, обвинив при этом недостаток тестирования.
Кроме того, мало выполнить лишь бизнес-анализ, который поставит цели реализации продукта, сформулирует правила и сценарии. Без системного анализа у команды не будет детализированного представления о том, как именно продукт складывается в систему, по каким правилам в нём работают интеграции. Без анализа архитектурного не будут учтены топологии, ограничения и компромиссы железа.
Как же действовать команде в отсутствии качественных требований или аналитика (кроме как обвинять во всём тестирование)?

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

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

Нехватка времени на разработку и тестирование.

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

5 практик, которые помогают точнее оценивать ресурсы:

1. Тестирование участвует в обсуждении требований.

Следуя shift-left модели, проекты с развитым тестированием подключают QA ещё на этапе анализа и уточнения требований. Взгляд тестировщиков позволяет прояснять неточности, выявлять потенциальные риски и иные дефекты и недостатки требований, в каком бы виде таковые ни были представлены. Кроме того, ранее привлечение тестирования - это решение проблемы онбординга, когда QA процедуры "пробуксовывают" из-за недостатка экспертности в проекте.

2. Тестовая стратегия формулируется до выполнения тестов.

Объём тестирования описывается заранее. Крупные задачи разбиваются на конкретные и измеримые тестовые активности, что упрощает планирование времени и ресурсов, а также контроль за их выполнением. Заранее фиксируются типы тестов и виды тестирования, которые будут актуальны для данного проекта на определённых этапах его реализации. Заранее определяются необходимые окружения, тестовые данные, критерии входа и выхода. В совокупности, благодаря заранее описанной тестовой стратегии с разбиением на атомарные активности, мы не только достигаем большей точности в оценке, но и добиваемся прозрачности тестирования.

3. Использование нескольких подходов в оценке одновременно.

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

• Декомпозиция на атомарные активности. Чем большей атомарности нам удалось достичь при формулировании задач, тем более точной получится оценка. При декомпозиции рекомендуется применять как метод разбиения тестируемого функционала на модули, так и Work Breakdown Structure, с помощью которой мы составим подробный чек-лист выполняемых активностей.

• Три точки (O/M/P) с учётом смещения оценки в сторону наиболее вероятной также помогут вывести более точное число. В этом случае мы не просто даём некоторое число требуемых часов, но учитываем оптимистичный, пессимистичный и вероятный исходы по формуле:

  (оптимистичная оценка + 4*наиболее вероятная оценка + пессимистичная оценка) / 6.

• Planning Poker, красная команда или три амиго - это методы коллективной оценки, когда вместо мнения единственного члена команды мы учитываем мнения нескольких.

4. Реалистичная оценка ресурсов.

Следует сразу трезво оценивать возможности команды и доступные инструменты:

• Сколько QA-инженеров нужно и какие у них компетенции, а также смогут ли они в действительности выполнить необходимый пул работ в запланированное время;
• Есть ли подходящие тестовые окружения, инструменты, лицензии и доступы;
• Сколько времени потребуется на подготовку тестовых данных, особенно нестандартных или «проблемных».

5. Учёт рисков.

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

Плохая коммуникация между членами команд.

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

Что помогает выстроить коммуникации:

• Общие каналы коммуникаций. Разумеется, переход из "личек" в общий чат не гарантирует того, что абсолютно вся информация будет присутствовать в публичном пространстве, однако это станет первым шагом к выстраиванию культуры knowledge sharing.
• Собственно, культура корпоративных коммуникаций. Информация о том, что были внесены те или иные изменения, протестирована та или иная задача или найден дефект, должна быть опубликована - при том в нескольких источниках, одним из которых должен стать упомянутый чат.
• Регулярные митинги. Дейли тоже являются стандартной практикой большинства команд, работающих в agile методологии, однако, помимо самого факта наличия этих встреч, важен и их регламент. Нужно понимать, что час времени каждого из членов команды образует общую стоимость дейли и, чтобы эти встречи имели максимальную эффективность, скоуп поднимаемых на них тем и вопросов обязан быть строго регламентирован, а кто-то из членов команды обязан взять на себя функции скрам-мастера и модерировать эти встречи, отсекая те вопросы, которые не касаются всей присутствующей команды.
• Документирование изменений. Бюрократию крупных проектов, разумеется, мало кто любит, но причины наличия таковой именно в осознанной необходимости детализированного описания продуктов и процессов и согласовании таковых с заинтересованными сторонами.
• Ретро. Даже на первый взгляд идеально выстроенные процессы не застрахованы от ошибок, и разбор причин возникновения багов на проде является одним из важнейших вопросов, который может быть поднят на ретро. Не для того, чтобы устроить показательную порку тестировщику, но для того, чтобы разобраться в реальных причинах, отыскать проблемы в процессах и отрегулировать их.

Баги, вызванные специфическими данными.

Некоторые ошибки проявляются только на продакшене из-за специфических данных: повреждённых файлов, неожиданных значений, невалидных форматов или большого объема данных, влияющего на производительность и стабильность. В личной практике наиболее распространенными дефектами этой категории видел ситуации, когда из-за несогласованности временных отметок в данных, в БД не попадали новые записи или же, попадая, имели отличные от ожидаемых таймстэмпы. Например, американский формат дат - это мес/ден/год, в то время, как европейский - ден/мес/год. Как система прочитает дату 02/03/04?

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

Как минимизировать риски дефектов из-за специфических данных?

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

Также поможет формирование чек-листа для датасетов, согласованный с системным аналитиком:

• Кодировки, локали, нормализация Unicode;
• Часовые пояса и DST;
• Ограничения на поля (максимальные и минимальные длины, формат, допустимые множества);
• Границы объёмов (batch-размеры, лимиты API);
• Идемпотентность операций и повторная доставка (вебхуки, очереди).

Ошибки DevOps.

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

Какие практики спасают от этой категории ошибок?

1. Неизменность билдов, когда один и тот же артефакт идёт от стейджа до прода.
2. Единая матрица конфигов, которая проверяется вручную или автоматическими тестами и с привлечением аналитика.
3. Пост-деплой проверки. Тесты на проде в рамках смоука по заранее запланированному тест-плану.
4. Поэтапная раскатка. Сперва новый релиз раскатывается на 1-5% аудитории и лишь по итогу успешных проверок на малой группе пользователей осуществляется полная раскатка.
5. Заранее сформированный и проверенный план отката. Возможность отключить фичефлаг, вернуться к стабильной версии, проверить даунгрейд скриптов, а также прописанная цепочка ответственных позволят вовремя среагировать на инцидент.

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