Пока мы чинили биллинг, в проде новые клиенты получали права CEO компании.

Утро началось с ручного регресса. Я создавал тестовые учетки в проде, проверял вход через госуслуги, Google, Яндекс и почту. На одном из аккаунтов заметил админские кнопки, которые должен видеть только руководитель. Первая мысль: фронт глючит. Открыл DevTools, посмотрел тело ответа API, и внутри оказался массив permissions с полным доступом уровня CEO. Не read-only админка, не менеджер телефонии, а роль владельца бизнеса на всю нашу компанию.

Я поднял Apache Superset, написал SQL-запрос и убедился в результатах корреляции: баг воспроизводился для всех новых регистраций. Не выборочно, не по таймингу, а стабильно. Причина нашлась быстро: небольшой рефакторинг логики прав, который менеджеры посчитали несерьезным патчем. Видимо, слово "небольшой" отключило у всех инстинкт самосохранения, и патч улетел в прод без тестирования выдачи ролей.

Дальше было почти комично. Я поднялся на второй этаж к проджект-менеджеру, рассказал устно. Он не поверил: "Ну вы, QA, можете надумать всякого". Я сел за ПК разработчика и показал все шаги кейса от регистрации до ответа API с чужими правами. Он сглотнул и спросил: "Надеюсь, ты нашему CEO об этом пока не доложил". Не доложил. Шефу рассказали уже после исправления бага.

Самое паршивое, что автотесты у нас были. Они проверяли создание пользователя, логин, покупку услуг. Но валидация выданных прав не входила ни в один тест-кейс. Этот инцидент добавил в наш чек-лист железное правило: рефакторинг авторизационной логики не бывает несерьезным, а права доступа нужно проверять в автотестах всегда, даже если патч называется "поправил опечатку в импорте".

Что из "несерьезных" изменений у вас улетало в прод и аукалось самым неожиданным способом?

#qa #regressiontesting #apitesting #permissions #rolebasedaccess #productionbug #devtools #autotests #softwaretesting #qualityassurance #sql #superset #backendtesting #authorization #refactoring