Секреты Тестирования Регистрации

И третий вариант — Здравый смысл.
Здесь мое личное представление о правильном адресе электронной почты,
ни в коем случае никому его не навязываю.
Правила должны быть одинаковыми и для доменной части и для локальной.
Я во многом склоняюсь к строгому варианту популярных почтовиков.
Чтобы никаких IP, комментариев, цитирования, скобок и спецсимволов в емаиле быть не должно.
Только точка, нижнее подчеркивание и дефис.
Но не вначале и не в конце локальной и доменной части.
И это не значит что нужно считать за баг то, что поле пропускает почту с yandex доменом начинающуюся с цифры. Тут все проще и обобщеннее.

Хороший адрес электронной почты тот, который можно ввести с обычной клавиатуры.

Проверять спецсимволы советую по отдельности.
Так можно выявить спецсимвол который не отфильтровывается.
Если просто вводить одним тестом !»№;%:?*()+=#$^&{}[]/\|
То тест не пройдет если хотя бы один символ отфильтровывается.
Спецсимволов не так много, поэтому посимвольная проверка оправдывает себя.
Точка — разрешенный символ, но есть один минус.
С помощью него можно запутать пользователя и сойти за другой емаил.
Например представим что есть известный емаил

email@gmail.com

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

Например admin.email@gmail.com

Хотя это разные адреса, для пользователя они могут показаться от одного источника.
Но то уже задачка на внимательность.
Так как мы не можем проверить существует ли емаил на самом деле мы должны помочь отфильтровать ошибки которые пользователь может сделать в спешке.
К сожалению для поля емаил не делается предупреждений.
Только либо правильный, либо неправильный.
А повторить ввод емаила просят очень редко
(что могло бы уменьшить шанс ошибки как с паролем).
Поэтому я считаю что отсутствие точки в доменной части следует считать за ошибку.
— Кириллица разрешена. Есть сайты на кириллице.
— Локальная часть из одного символа (буквы или цифры)
— Локальная часть максимум из 64 символов
— Весь адрес максимум 254 символа
— Домен не может состоять из цифр
— Домен должен содержать минимум одну точку
— Домен минимум из 2 символов
— Поддомен минимум из 2 символов
— Поддомен или домен максимум из 63 символов
Некоторые личности путаются и вводят почту начиная с www.
Ошибка тут только в том случае, если настоящий твой адрес не содержит www. вначале.
Однако это вполне валидный емаил и его можно зарегистрировать в популярных почтовиках.
например www.login@mail.ru
Проверка на опечатки популярных почтовых доменов
Например meil вместо mail
mall, mal, mai, mial, mali
gmall, gmeil, gmali
ysndex, yadex, yndex, yandeks, yandx
Валидный ли по твоему этот емаил?
aaa@bbb.cc
Как думаешь?
Похоже будто кто то просто ввел первые три буквы ради теста.
Такого емаила не существует на самом деле.
Но.
Он вполне валидный. Он правильный и подходит по правилам.
Существует домен .сс
А значит можно создать сайт bbb.cc и к нему свою почту,
в том числе и aaa@bbb.cc.
Это возможно. Значит мы не должны это отсеивать.
Расскажу еще одну фишку.
Собачку, она же @, называют at.
И иногда на сайтах можно увидеть написание почты в таком виде:
test at 9m . com
Что равносильно test@9m.com
Делается так для того чтобы спам-роботы не идентифицировали
адрес почты и не использовали в своих списках по рассылке спама.

И наконец поля «пароль» и «повторите пароль»

Данные в поле «пароль» должны отображаться звездочками

Желательно два поля для пароля:
Пароль и
Подтвердите пароль
Это делается для того чтобы отсеять ошибки со стороны пользователя.
Поле «пароль» не должно позволять скопировать данные чтобы вставить их в поле «подтвердите пароль»
Если поля «пароль» и «подтвердите пароль» не совпадают
и нажата кнопка «отправить» — то эти поля должны обнулиться.
Если неправильно заполнено какое либо другое поле и нажата
кнопка «отправить» — поля «пароль» и «подтвердите пароль» должно обнулиться.
Один возможный баг.
Сначала заполни поле «пароль».
Потом заполни теми же данными поле «повторите пароль»
Ждешь когда поля окрашиваются в зеленый — значит пароли совпадают.
Затем возвращаешься в поле «пароль» и стираешь последний символ.
Есть вероятность что поля останутся в зеленых рамках.
Такое может происходить если проверка пароля происходит один раз.
Это конечно не значит что не вылетит ошибка когда ты нажмешь кнопку «отправить».

P.S.
Некоторые тестировщики могут посчитать глупостью то, что я написал тесты для новичков, а не дал им самим их придумать. Мне плевать если вы так думаете. Я считаю что для наглядности и понимания так будет лучше.
Я не пытался написать всевозможные тесты. Если захотеть — можно придумать еще.

P.P.S.
Я подумал сделать такую рубрику «как это тестировать», что то подобное и для других часто встречающихся модулей. Если тебе это интересно — напиши что бы ты хотел узнать или добавить в эту рубрику.

Если ты нашел ошибку или вдруг что то изменилось — напиши мне об этом.

RFC 5321
RFC 2821
RFC 821

Обновление:
Над двойными кавычками («) я не властен. Как код их интерпретирует — развернуть налево или развернуть направо — я не знаю, поэтому повлиять не могу.

20 комментариев

  1. Очень полезный материал! Больше пиши подобного. Именно по таким статьям можно научиться. Да, многие будут спорить, что не прав и сделал работу за новичков и лишил их возможности думать. Но, а как же тогда можно научится чему-то не разобрав пару десятков подробных примеров??
    Также хочу почитать про секреты тестирования поиска на сайте и корзины.

  2. Привет, Артем. Опечатка на второй странице в секретах тестирования регистрации.
    — Локальная часть из одной цифры (4@maeshrut-testirovshika.ru)

  3. Очень полезная статья, спасибо. Всегда интересно посмотреть — так а как же оно на практике делается)
    Так получается если по документации поддерживается протокол RFC 6530, со всякими китайскими и др языками, то достаточно проверить условно:
    — можно test@xn--hxajbheg2az3al.xn—jxalpdlp
    — можно xn--test@iana.org
    и они все попадут в этот перечень?

  4. Очень полезно для начинающих. Я сама заканчивала курсы тестировщиков. Могу сказать из опыта, что нас гоняли в основном по методологии (где-то 1,5 месяца из 3,5 ушло на это). А вот именно такие вещи нам не объясняли. Додумывали сами. И очень жаль.

  5. Спасибо! Пока только вливаюсь в сферу тестирования ПО и статьи написанные без всяких примудростей очень помогают. Интересно было бы почитать о тестировании веб приложений)

  6. Толковая статья, но на проектах зачастую нет времени протестировать полностью форму регистрации да и нет смысла, т.к. пользователь это вам не тестировщик)), а то что вылезет баг у пользователя не значит, что вы его найдете).(вспомнился закон Парето)
    Но относительно aaa@bbb.cc, буду иметь ввиду(я над этим как то и не задумывался)
    Спасибо за статью.

  7. Спасибо большое за статью!! Для начинающих тестировщиков это просто сокровище!! Я читала разную информацию, как проверять email адрес, но не удавалось все это, так хорошо проанализировать и разложить по полочкам. Столкнулась с тем, что некоторые требования, из разных источников, противоречат друг другу и у разных почтовиков свои требования. Тяжело все это собрать в одну кучу и понять, как тестировать!! Спасибо за Ваш труд!!

  8. Спасибо огромное за данную статью… Я начинающий тестировщик,на курсах сплошная теория… все очень поверхностно и как слепой котенок пытаюсь что-то глубже понять… Прочла вашу статью и восприятие данного материала … просто информация открыла глаза на реальность.. Спасибо!!!

  9. Артём спасибо! Я тоже начинающий тестировщик, но доже и не подозревала, что может быть столько проверок! Теперь твоя статья будет, как руководство пользователя. Спасибо тебе, за твою работу и за то, что делишься своим опытом!

  10. Локальная часть может начинаться и заканчиваться нижним подчеркиванием (b_@marshrut-testirovshika.ru)
    а в примере только заканчивается, перечитывал на досуге и увидел))

Добавить комментарий