Тестирование регистрации часто просто пропускают. В команде обычно есть один человек, который однажды довёл регистрацию до рабочего состояния, и после этого её больше никто не трогал — до того дня, когда кто-то сообщает, что письмо с подтверждением не пришло или что ссылка уже недействительна. Обе проблемы не выглядят сложными, но проявляются они поздно: письмо уже отправлено, учётная запись создана наполовину, а пользователь застрял посередине.
Здесь регистрация и подтверждение почты разложены на проверяемые пункты с точки зрения инженера по тестированию. Отдельно сказано, что действительно является тестом, а что уже выходит за границы вашей системы.
Что входит в тестирование регистрации?
Регистрация — это не одна форма, а цепочка шагов, и каждый шаг может отказать по своей причине. Форма принимает данные, затем создаётся учётная запись в промежуточном состоянии, затем отправляется письмо, затем пользователь открывает ссылку, и только после этого запись становится полноценной.
Если хотя бы один шаг не оставляет после себя проверяемого доказательства, отчёт о дефекте превращается в пересказ. Поэтому проверяемая единица в этом потоке — не «регистрация работает», а конкретный переход: что отправлено, что записано, что показано пользователю.
- Форма принимает корректный адрес и отклоняет заведомо некорректный.
- Учётная запись создаётся в состоянии «ожидает подтверждения», а не сразу активной.
- Письмо уходит на указанный адрес и содержит рабочую ссылку.
- Первое открытие ссылки переводит запись в активное состояние.
- Повторное открытие той же ссылки даёт понятный отказ, а не тихую ошибку.
Где проходит граница: своя система или чужой сервис
Если поток регистрации поддерживаете вы, это обычное функциональное тестирование, и все проверки ниже применимы напрямую. Ситуация меняется, когда нужно убедиться, как ведёт себя сторонний сервис, для начала работы с которым требуется подтвердить почту.
В этом случае вы можете проверить только свою сторону: доходит ли письмо на ящик, которым вы управляете, куда ведёт ссылка из письма и как сервис реагирует на её открытие. Не следует создавать учётные записи массово, чтобы обойти ограничения на количество, бесплатный лимит или антифрод. Это не является тестированием и обычно нарушает условия использования сервиса.
Допустимый сценарий узок: взять один ящик под своим контролем, полностью пройти регистрацию, убедиться, что письмо доходит, ссылка работает, а учётная запись пригодна для дальнейших шагов. И на этом всё. Перед началом работы убедитесь, что у вас есть явное разрешение на такое тестирование.
Что проверять в самом письме подтверждения
Доставка письма — это первый шаг и одновременно самый информативный. Получив письмо, зафиксируйте как минимум четыре вещи: имя и адрес отправителя, тему, полный адрес ссылки из тела письма и наличие текстовой версии без разметки.
На отправителя стоит смотреть внимательно. Ситуация, когда отображаемое имя не совпадает с фактическим адресом, встречается постоянно. Но если фактический адрес вообще не связан с официальным доменом, это может говорить как о проблемах в настройке отправки, так и о том, что письмо отправлено не сервисом. Второй случай — как раз то, что вы должны уметь распознать во время тестирования.
Адрес ссылки нужно скопировать и посмотреть глазами, а не просто нажать. Проверьте три вещи: принадлежит ли домен самому сервису, уникален ли токен внутри ссылки и нет ли лишних параметров отслеживания. Затем уберите параметры отслеживания и откройте ссылку снова — так вы поймёте, самодостаточен ли токен или зависит от дополнительного состояния.
Если сценарию нужно проходить этот поток многократно, стабильный входящий ящик выгоднее, чем создание новых учётных записей раз за разом. Инструмент временной почты этого сайта создаёт адрес прямо в браузере: ни получение писем, ни просмотр ссылок не требуют регистрации, поэтому он удобен как шаг ручной регрессии. Что именно представляет собой такой ящик и чем он ограничен, разобрано в отдельном материале про одноразовый почтовый ящик.
Одноразовость ссылки, срок жизни и повторная отправка
Ссылка подтверждения обычно имеет состояние: либо она перестаёт работать после первого использования, либо у неё есть срок действия. И то и другое нужно проверять явно, потому что отказы здесь проявляются незаметно.
Одноразовую ссылку проверяют двумя нажатиями. Первое должно пройти успешно, второе — завершиться ошибкой, и при этом сообщение об ошибке должно различать «уже использована» и «срок истёк». Если в обоих случаях выводится одна фраза «ссылка недействительна», у пользователя не останется подсказки, когда он столкнётся с настоящей проблемой.
Срок действия проверяют по границе, но не угадывают. Большинство сервисов прямо указывают срок в письме — от него и отталкивайтесь при построении сценария. Если срок не указан, отнесите вопрос «что произойдёт после истечения» в отчёт как открытый, а не подставляйте своё число.
Повторная отправка — место, где чаще всего остаётся мусор в состоянии. Запросите переотправку в три разных момента и отдельно нажмите старую и новую ссылки: старая до запроса, старая после запроса, новая. Типичных ошибок две: переотправка мгновенно гасит старую ссылку, либо после переотправки работают обе ссылки. Какой вариант правильный — решает продукт, но ситуация, когда не работает ни одна, однозначно является дефектом.
| Шаг проверки | Ожидаемое поведение | Что считается дефектом |
|---|---|---|
| Первое нажатие | Подтверждение проходит | Ссылка не работает сразу |
| Второе нажатие | Понятный отказ с причиной | Отказ без причины или успешное повторное подтверждение |
| Старая ссылка до переотправки | Работает | Не работает до запроса новой |
| Старая ссылка после переотправки | Зависит от решения продукта | Не работают ни старая, ни новая |
| Новая ссылка | Работает | Не работает новая ссылка |
Регистр адреса, алиасы с плюсом и повторная регистрация
Вопрос о том, различает ли сервис регистр в локальной части адреса, на уровне спецификации предполагает мягкую трактовку, однако реализации расходятся очень сильно. Для теста подготовьте минимум три варианта ввода: полностью в нижнем регистре, с заглавной первой буквой и с заглавными буквами внутри. Идеальный результат — все три указывают на один ящик; худший — система считает их тремя разными учётными записями. Во втором случае появляются дубликаты, а пользователь может не попасть в только что созданную учётную запись из-за другого регистра при вводе.
Алиасы с плюсом — отдельная история. Адрес вида [email protected] обычно доставляется в ящик по имени без метки, но приводит ли система учётных записей такой адрес к каноническому виду — самостоятельное проектное решение. Если не приводит, на один ящик можно зарегистрировать несколько учётных записей. Это не обязательно уязвимость, но продукт должен явно определить своё поведение, и в отчёте это следует записать как подтверждённое поведение, а не как предполагаемый дефект.
Здесь же находится точка наблюдения за перечислением учётных записей. Зарегистрируйтесь повторно на тот же адрес и посмотрите на подсказку: «этот адрес уже зарегистрирован» или «мы отправили письмо с подтверждением». Первый вариант раскрывает, есть ли адрес на платформе, второй — нет. Это поведение, связанное с безопасностью: в отчёте достаточно описать факт, выводы за продукт делать не нужно.
Как ведёт себя ссылка в приватном окне и на другом устройстве?
Ссылка подтверждения иногда зависит от cookie текущей сессии. Проверяйте в двух окружениях: нажатие в том же браузере и нажатие в свежем приватном окне.
Если ссылка работает только в том же браузере, она привязана к сессии. С точки зрения безопасности это не обязательно плохо, но означает, что пользователь, открывший письмо на другом устройстве, получит отказ, — это поведение нужно внести в список известных ограничений. И наоборот: если ссылка работает и в приватном окне, токен самодостаточен, и тогда стоит отдельно убедиться, что его срок жизни и одноразовость достаточно строгие.
Проверка на другом устройстве — это копирование ссылки в браузер телефона и повторное прохождение. Главное здесь — как переносится состояние входа и завершается ли подтверждение на узком экране.
Есть ещё исполнитель, которого легко не заметить: часть почтовых клиентов и защитных шлюзов заранее открывают ссылки из письма, проверяя их на фишинг. Это реальное открытие, и одноразовый токен расходуется ещё до того, как пользователь нажмёт на ссылку. Воспроизводится просто: откройте письмо в ящике, не нажимая на ссылку, подождите и попробуйте нажать. В отчёте о дефекте обязательно укажите, кто именно открыл ссылку первым, иначе разработчик не найдёт причину.
Стоит ли проходить регистрацию через временную почту?
Зависит от того, что написано в условиях целевого сервиса, и от того, что вы собираетесь делать. Получить одно письмо с подтверждением и убедиться, что поток работает, — обычно нормальное использование. А вот повторные регистрации ради обхода лимитов или бесплатной квоты почти всегда запрещены условиями.
Если сомневаетесь, сначала выясните, есть ли у вас разрешение на тестирование, а не запускайте проверку по принципу «а потом разберёмся». Отдельно стоит помнить, что некоторые сайты вообще отказываются принимать адреса из временных доменов: письмо не приходит не из-за ошибки в вашем коде, а из-за фильтра на стороне отправителя. Почему так происходит, разобрано в материале про блокировку одноразовых доменов.
Также полезно заранее понимать, как письмо вообще находит получателя и на каком шаге оно может потеряться, — это описано в статье о том, как работает временная почта.
Минимальный чек-лист
- после регистрации приходит письмо подтверждения, отправитель и тема соответствуют ожиданию;
- домен ссылки в письме принадлежит самому сервису и не содержит лишних перенаправлений;
- первое нажатие проходит, второе даёт понятную причину отказа;
- состояние старой ссылки после переотправки соответствует определению продукта, и не бывает так, что не работает ни одна;
- адрес в нижнем регистре и он же в смешанном ведут себя одинаково;
- поведение нормализации алиасов с плюсом имеет однозначный вывод;
- подсказка при повторной регистрации не раскрывает существование учётной записи;
- подтверждение пройдено по одному разу в приватном окне и на другом устройстве;
- при предварительной выборке письма одноразовый токен не расходуется заранее.
Сам список не так важен; важно, что каждый шаг оставляет воспроизводимое доказательство: время получения, исходный текст ссылки, ответы на два нажатия. Данные воспроизводимы — значит, проблему можно передать другому. Проверки самого потока подтверждения стоит сверять с общим чек-листом тестирования транзакционной почты, а сценарий без ручного участия человека строить по материалу о тестировании потока подтверждения почты.
Что делать дальше
Выберите один сценарий, где вы сейчас указываете свою настоящую почту, и пройдите его заново с временным адресом: сравните, сколько писем придёт на основной ящик после этого. Если вы отвечаете за тесты, заведите отдельный адрес на каждый сценарий и уберите ожидание по секундам в пользу опроса до появления письма.
Отдельно проверьте, какие данные при этом создаёт сам инструмент. Всё, что генерирует этот сайт, — синтетические данные: они повторяют формат настоящих документов, а в странах, где алгоритм реализован, значение согласовано с контрольной суммой. Но они не соответствуют ни одному реальному человеку, адресу или счёту и не выданы никаким ведомством. Проверить, какие страны поддержаны, можно в справочнике стран, а свою выборку — прогнать через инструмент проверки.