🧱 Пришёл собирать автомейшн - а собираю список блокеров #qa #tools
Вышел на новый проект, и как обычно пошёл пилить автотесты. Но чем глубже копаю, тем больше понимаю: мало кто архитектурит учитывая интересы AQA. Делюсь списком того, на что реально натыкаюсь.
1️⃣ Авторизация без пароля. OTP на почту, magic link, SMS-коды, passkeys. Нет логина-пароля = нет тупой формы, которую можно задолбить. Надо либо ходить в почтовый ящик за ссылкой, либо дёргать внутренний апишник за кодом, либо договариваться с бэком о тестовом байпасе. Каждый вариант - это отдельная инфраструктура вокруг теста, а не сам тест.
Решение: попросить бэк сделать эндпоинт, который по юзер-айди отдаёт последний OTP/ссылку из тестового ящика. Закрыть его тестовым токеном и включать только на стейдже (максимально важно это подсветить).
2️⃣ 2FA и MFA. Даже если пароль есть, дальше тебя ждёт TOTP из аутентификатора, пуш на телефон или SMS. Для автоматизатора это значит либо генерить TOTP своим кодом, либо отключать MFA тестовым юзерам (и потом ловить пизды от безопасников), либо поднимать mailosaur для перехвата кодов. Жопа.
Решение: попросить выдать под тестовые аккаунты фиксированный TOTP-секрет, который лежит в сидбоксе. Генеришь код по секрету прямо в тесте - и не трогаешь флоу MFA.
3️⃣ Внешние интеграции без моков и песочниц. Платёжки, KYC-провайдеры, антифрод, смс-шлюзы, банки, биржи. У половины нет нормальной sandbox, у другой половины она есть, но нихуя не работает 90% времени. В итоге либо тестишь в проде с реальными деньгами (не надо), либо пилишь моки сам и молишься, что схема ответа не разъедется.
Решение: попросить техдира на каждую внешнюю интеграцию поднять прокси-мок на нашей стороне (wiremock/mockserver) с переключателем реальный/мок по env. И закрепить ответственного, кто держит схемы моков в актуальном состоянии по контракту. Или на себякоманду забрать полностью этот микросервис.
4️⃣ Тестовые данные и состояние юзера. Чтобы проверить "отмену заказа" нужен юзер с активным заказом. Чтобы проверить "второй платёж" нужен юзер с первым. И всё это надо генерить перед каждым прогоном, потому что нормального сидинга нет. Тест вместо 30 секунд идёт 5 минут и падает на этапе подготовки, а не на самой проверке.
Решение: попросить бэк сделать сидер - cli или эндпоинт, который по названию сценария создаёт нужное состояние (юзер + заказы + платежи + флаги). Запускать из before-хука теста, никакого UI для подготовки. Или самому навайбкодить - прямиком в базу чтоб срал.
5️⃣ Асинхронщина и eventual consistency. Юзер нажал кнопку - ответ 200, а реально изменение долетит через очередь секунд через 5-10. Тест проверяет сразу и красный. Начинаешь пихать sleep - тесты становятся медленными и флакающими. Особенно больно на e2e, где за один кейс таких точек три-четыре.
Решение: попросить бэк дать эндпоинт или метрику, по которой видно "задача X обработана" - статус в БД, запись в аудит-логе, health по очереди. Тест поллит этот признак вместо тупого sleep. Ну или кондишонал вейты пилить.
6️⃣ Долгие бизнес-процессы. Подписка продлевается через месяц, рассрочка - через 30 дней, триал кончается через 14. В тесте ты это не подождёшь. Либо лезешь в БД руками двигать даты (и ломаешь связанные записи), либо забиваешь и не тестишь вообще.
Решение: попросить бэк вынести "текущее время" в абстракцию (clock/time-provider) и сделать админский ручник "промотать время для юзера X на N дней". Тогда весь биллинг и триалы покрываются нормально, без плясок с БД.
Почти каждый пункт выше решается не героизмом автоматизатора, а нормальным разговором с техдиром и бэком: дайте ручки, дайте сидер, дайте моки. Без этого я ручками вот этими 👐 в юай буду нажимать фултайм за свой оклад лидаавтоматора.
А у вас что больше всего ломает автомейшн на текущем проекте? И если не ломает уже, сколько времени понадобилось всех заставить это сделать?
