В одной продуктовой компании (назовём её “Startupicorn”) хотели как лучше. Запустили лендинг с формой регистрации, начали гнать трафик с рекламы, включили автотесты, всё красиво, всё работает. Только вот спустя неделю стало ясно: конверсия из заходов в регистрации просела на 30%.
🧠 "Ну, это, наверное, маркетинг накосячил?" — подумали сначала. Но дальше — больше. День, два, три, деньги на рекламу сгорают, регистрации нет.
Что случилось? Читайте — и не наступайте на эти же грабли.
Исходные данные
- Одностраничник с формой регистрации: имя, email, телефон
- Большая часть трафика — с мобильных устройств
- Рекламный бюджет: более 1 млн ₽ на запуск
- Все поля валидировались: вручную и через HTML5
Баг, который никто не ждал
Валидация email делалась через кастомную функцию на фронте, с помощью RegExp:
На первый взгляд — всё норм. Но вот нюанс: она не принимала email с "плюсиком".
А знаешь, кто использует email+что-то@domain.com?
Правильно: маркетологи, технари и часть обычных пользователей, у которых есть привычка делать фильтрацию почты.
Всё это привело к тому, что:
- Пользователь вводит email ivan+shop@gmail.com
- Жмёт "Зарегистрироваться"
- Получает ошибку: "Неверный формат email"
- Пытается ещё раз → снова ошибка
- Уходит навсегда, злой, с чувством "ваш сайт не работает"
И как это стало видно?
На проде всё “работало”.
Автотесты — ✅
Юнит-тесты на validateEmail() — ✅
Сценарий "ввод обычного email" — ✅
Но никто не подумал проверить: а что будет, если ввести email с плюсом, дефисом, точкой и другими допустимыми символами?
Только после анализа логов и жалоб в поддержку стало понятно:
~27% неудачных попыток регистрации были связаны с ошибкой "Invalid Email"
Как баг убил конверсию
До бага:
- 1000 визитов → 120 регистраций (12%)
После бага:
- 1000 визитов → 84 регистрации (8,4%)
Потеря:
- ~30% регистраций
- ~40 000 ₽ за неделю — просто улетело в трубу
- Недоверие к продукту на старте
- Минус лояльность у первых пользователей
Почему никто не заметил?
Потому что:
- Юнит-тесты проверяли только базовые кейсы (test@example.com)
- Автотесты проходили: ошибка валидации → есть сообщение об ошибке → ✅
- Ручное тестирование проводилось на "счастливом пути"
- QA был подключён после релиза, не на этапе дизайна валидации
- Никто не подумал, что валидная почта может быть не такой уж и "обычной"
Что делать, чтобы так не было?
✅ 1. Проверяй валидные, но нестандартные входные данные
В любой форме:
- ivan+test@gmail.com
- user.name@domain.co.uk
- имя@почта.рф (да, это допустимо)
- user_name@domain.travel
Если это валидно по RFC — твоя форма не должна орать, что "нельзя".
✅ 2. Читай спецификации или используй готовые библиотеки
Зачем писать свои регулярки, если можно использовать проверенные решения:
- validator.js в JavaScript
- email-validator в Python
- Браузерную валидацию HTML5: <input type="email"> (но тоже не панацея)
✅ 3. Смотри не только на ошибки, но и на паттерн ошибок
Если в логах десятки тысяч ошибок одного типа — это сигнал.
✅ 4. Обсуждай валидации до разработки
- QA и разработчик вместе обсуждают: какие поля, какие ограничения, какие граничные значения
- Делается чек-лист: что точно проверяем
✅ 5. Добавь в чек-листы поля с "особенностями"
Каждый раз, когда есть форма:
- Проверить пустые поля
- Проверить слишком длинные значения
- Проверить допустимые спецсимволы
- Проверить "почти правильные" данные
Как бы это выглядело в хорошем тест-кейсе?
TC-103: Проверка валидного email с плюсом
1. Открыть форму регистрации
2. Ввести `qa+test@gmail.com`
3. Ожидаемый результат: форма принимает email без ошибки
📌 Итоги
- Даже "простая" валидация может скрывать глубокий баг
- Автотесты не спасут, если покрытие — только на хэппи-патч
- Конверсия — это не просто цифра. Это деньги. Это пользователь. Это лицо продукта.
- QA должен думать как пользователь и проверять как хакер
Если ты джун — не бойся спрашивать, что именно проверено.
Если ты мидл — не ленись расширять кейсы.
Если ты лид — включай тестирование в процесс с самого начала.
Любая форма — это поле боя. Побеждает тот, кто думает, как пользователь, но тестирует, как параноик.