задача протестировать работу формы для регистрации нового пользователя
Тестирование Web формы
Здравствуйте, сразу уточню что это тестовое задание.
Мне нужно протестировать веб форму любого сайта(только поле регистрации и авторизации). Я уже этим занимаюсь 4 часа))). Опыта в подобных вещах у меня нет. Поэтому я был бы очень рад если бы вы глянули на то, что у меня получается. Особенно по поводу оформления, я очень сильно переживаю, как-то всё громоздко получается. Полная работа будет страниц на 12 где-то, не уверен, что это нормально). Вообщем буду очень рад если вы меня скорректируете. Если не трудно напишите, что хорошо, а что плохо.
1. Форма Регистрации
1.1) Ввести все предложенные данные корректно.
1.2) Ввести только обязательные поля
1.3) Заполнить все данные и обновить страницу
1.4) Не заполнять данные и выполнить регистрацию.
1.5) Ввести максимально допустимые значения в поля ввода.
1.6) Ввести минимально допустимые значения в поля ввода.
1.7) Поля Имя и Фамилия:
А) Ввести только одни пробелы;
Б) Ввести данные на английском языке;
Г) Ввести спецсимволы.
1.8)Ввод Пароля:
А)Аналогичный почте;
Б)Состоящий только из пробелов.
1.9)Почта
А) Ввести почту уже зарегистрированного пользователя;
Б) Использовать русские буквы в почте;
В) Не указывать символ “@”;
Г)Не указывать домен верхнего уровня.
1.9)Выбор даты рождения:
А)Выбрать ещё не наступившую дату
Б)Выбрать в качестве даты рождения текущее число
Г)Выбрать в качестве даты рождения не существующую дату
Д)Проверка «29 февраля»
2.1 Проверка формы авторизации:
2.1) Выполнить вход в аккаунт введя все данные корректно.
2.2) Не заполнять поля авторизации и попытаться осуществить вход.
2.4) Заполнить корректно только поле пароль.
2.5) Попытаться осуществить вход используя аккаунт, пароль которого состоит из пробелов.
2.6) Ввести корректный маил, но не корректный пароль.
2.7) Ввести не корректный маил, но корректный пароль.
Форма Регистрации
Т1.1) Ввести все предложенные данные корректно.
Ожидаемый результат: Появляется уведомление: «Учетная запись создана.
Фактический результат: Появляется уведомление: «Учетная запись создана.
Т 1.2) Ввести только обязательные поля
Ожидаемый результат: Появляется уведомление: «Учетная запись создана.
Фактический результат: Появляется уведомление: «Учетная запись создана.
T 1.3) Заполнить все данные и обновить страницу
Шаги: 1) На сайте https://tomas33.ru заполнить все данные для регистрации и обновить страницу.
Ожидаемый результат: Очистка введённой информации.
Шаги по воспроизведению:
1)На сайте https://tomas33.ru выбрать пункт регистрация.
Т1.4 Не заполнять данные и выполнить регистрацию.
Шаги: 1) На сайте https://tomas33.ru при регистрации оставить все поля пустыми и попытаться зарегистрироваться.
Ожидаемый результат: неудачная регистрация с указанием ошибок.
Фактический результат: неудачная регистрация с указанием ошибок. Данные предложения составлены грамматически неверно. С нарушением правил русского языка.
Т1.5) Ввести максимально допустимые значения в поля ввода.
Ожидаемый результат: Успешная регистрация
Фактический результат: Ошибка: 500 Server Error
БАГ1.5) Ввод максимально допустимых значений
Описание: При вводе максимально допустимых [сА1] значений при регистрации сайт отображает ошибку «500 Server Error».
Шаги по воспроизведению:
1) На сайте https://tomas33.ru выполнить регистрацию введя в поле email 128 символов.
Деффект: сервер выдаёт ошибку: «500 Server Error»
Т1.6) Ввести минимально допустимые значения в поля ввода.
Ожидаемый результат: Успешная регистрация.
Фактический результат: Успешная регистрация.
T1.7.А) В поля «Имя» и «Фамилия» ввести только одни пробелы;
Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия только пробелы.
Ожидаемый результат: Сообщение об ошибке.
Фактический результат: Успешная регистрация.
БАГ1.7.А) Возможность регистрация нового пользователя имя и фамилия которого состоит из пробелов.
Описание: Во время регистрации при вводе в поля «Имя» и «Фамилия» пробелов, система воспринимает их корректно и успешно регистрирует нового пользователя.
Шаги по воспроизведению:
1) На сайте https://tomas33.ru выполнить регистрацию введя в поля «Имя» и «Фамилия» только пробелы.
Деффект: Система корректно воспринимает регистрацию нового пользователя имя и фамилия которого состоит из пробелов.
T1.7.Б) Ввести данные на английском языке;
Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия слова на английском языке.
Ожидаемый результат: Успешная регистрация.
Фактический результат: Успешная регистрация.
T1.8.В) Ввести цифры
Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия цифры.
Ожидаемый результат: Сообщение об ошибке.
Фактический результат: Сообщение об ошибке.
T1.8.Г) Ввести спецсимволы.
Шаги: 1) На сайте https://tomas33.ru выполнить регистрацию введя в поля Имя, Фамилия спецсимволы.
Ожидаемый результат: Сообщение об ошибке.
Фактический результат: Сообщение об ошибке.
Разбор формы регистрации на сайте
Авторизация и аутентификация, в чем разница?
Для начала мы уменьшим количество заполняемых полей до минимума, то есть запросим только те данные, которые просто необходимы для минимальной персонализации пользователя. В итоге у нас получилось всего три поля: email адрес, пароль и имя пользователя. Да, всего три, email и пароль для идентификации пользователя, а имя пользователя для его персонализации среди других пользователей.
(Примеры форм регистрации/аутентификации)
Я пересмотрел десятки разных вариаций на данную тему и ни одно меня не устроило. Самые распространенные варианты были: две кнопки рядом, вход и регистрация, которые выводили две разные формы; одна большая кнопка регистрации на лендинге и маленькая кнопка входа где-то в верхнем правом углу; модальное окно с двумя переключателями/вкладками форм регистрации и входа. Больше всего мне не хотелось делать две формы, так как у такого подхода всегда будет один лишний шаг что-бы сменить одну форму на другую.
(Примеры формы регистрации/аутентификации)
Собираем готовую форму
Один мой знакомый подсказал, что у них на сервисе (в компании в которой он работает) регистрация/аутентификация реализована следующим способом: Есть одно поле для ввода email адреса. Мы вводим свою почту, нажимаем продолжить, если такой адрес найден в базе, то открывается форма входа, если адрес не найден, то открывается форма регистрации. Такой подход избавляет пользователя от промежуточного шага выбора нужной формы, но не избавляет общий процесс регистрации/входа от двух шагов, даже с автоматическим выбором формы, что ненамного облегчает задачу.
Основная мысль этой идеи мне понравилась, но я решил более автоматизировать и упростить задачу. Страшное название «регистрация» я заменил на более приветливую фразу «мой профиль». В итоге была реализована форма с тремя полями (email, пароль, имя пользователя) и одной кнопкой («создать | войти»). Причем поле «имя пользователя» изначально заблокировано для ввода. Пользователь вводит свой email и как только переключается на поле пароля (поле email теряет фокус), отправляется запрос в базу данных с введенным email адресом по которому идет поиск среди пользователей. Если совпадение найдено, мы получаем его имя и отдаем клиенту. На стороне клиента имя вставляем в поле «имя пользователя», а кнопка меняет название на «войти». Если же пользователь с таким email адресом не найден в базе, то мы разблокируем поле ввода «имя пользователя» и меняем кнопку на «создать».
Так же я не забыл про пользователей, которые используют для входа соц. сети и другие популярные сервисы. Под формой регистрации располагается блок с социальными кнопками для входа. И ещё одна маленькая, но важная деталь, небольшой переключатель видимости пароля, который показывает/скрывает пароль для более точного ввода.
(Итоговая форма регистрации/аутентификации)
По моему у нас вышла отличная форма регистрации/входа. Весь процесс занимает заполнение трех, а если пользователь уже имеет профиль, то двух полей и нажатие на одну кнопку. В следующей статье мы рассмотрим архитектуру RESTfull и её реализацию на сервисе (с точки зрения пользователя).
Чек-лист тестирование формы регистрации
Также у меня есть вопрос по поводу positive и negative: Когда мы пытаемся ввести логин состоящий из 2 символов то, выводится сообщение » Введенное имя слишком короткое «. Я расцениваю это с одной стороны как пазитив, потому что форма реагирует и не дает нам совершить ошибку. С другой стороны мы же вводим 2 символа, а это не корректно для логина и является негатив тестом. Почему так?
Ссылка на документ: гугл док
2. это негативный тест, потому что вы при этом не можете пройти процедуру логина.
Мысли после поверхностного взгляда:
Много избыточных проверок, например, из позитивных:
пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)
пункты 12 и 13 по сути эквивалентные, тоже можно сократить до одного
пункты 19 и 20 так же эквивалентны
Продолжите мысль для негативных, там тоже есть избыточные проверки, но при этом, не хватает уникальных проверок, подумайте, что можно еще проверить.
Из списка позитивных проверок пункт 6 необходимо перенести в негативные, т.к. зарегистрироваться с занятым именем невозможно так же как с некорректным.
пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)
Таким образом я хотел проверить граничные значения(Указано что «Имя пользователя» может иметь от 3 до 26 символов) Если к примеру программист ошибся и указал >3 но не =>3. Или я не правильно понимаю что-то??
пункты 7 и 8 можно объединить в один, т.к. если проверка успешно проходит на 3-х символах, то на 4-х она тоже будет проходить (эквивалентные значения)
Таким образом я хотел проверить граничные значения(Указано что «Имя пользователя» может иметь от 3 до 26 символов) Если к примеру программист ошибся и указал >3 но не =>3. Или я не правильно понимаю что-то??
если программист ошибся и указал >3 но не =>3, то проверка на 3-х символах не пройдет и будет понятно, что это баг, а проверка на 4-х символах тут не нужна.
Тестирование веб форм (вопросы на собеседовании)
— Заполняем поля известными правильными данными жмём вход.
Далее негативные тесты.
— Заполняем не верными данными и вход
— Одно верными другое не верными данными и вход
— Тоже что и выше только наоборот
— Заполняем поля правильными данными жмём ок.
Далее негативные тесты.
— Какое-то из полей пустое
— Ник состоящий из смеси англ и русс букв
— Ник имеющий знаки препинания и символы
— Слишком длинный никнейм
— Слишком короткий комментарий
— Слишком длинный комментарий
— Слишком длинный комментарий состоящий из слова без пробела
Пожалуйста подкорректируйте где я не прав
У Алексея Лупана есть отличный пост «Тестируем логин/пароль»
у меня ник user12 Ж)
Говорят допустим спецификации нет. Видимо хотят чтобы я учёл все возможности.
Спасибо за статью почитаю
У Алексея Лупана есть отличный пост «Тестируем логин/пароль»
у меня ник user12 Ж)
В тестировании 1 пункта обратите внимание на то, что тестируете во 2м пункте. Большинство идей применимо и там.
О-хо-хо, как же я «люблю» такие ответы на собеседованиях.
Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».
А есть спеки нет вообще? А если она есть, но состоит из одной строки «сделать стандартный логин диалог»?
А если в конце концов там написано, что пароль должен состоять только из цифр и быть не длиннее 3 символов?
О-хо-хо, как же я «люблю» такие ответы на собеседованиях.
Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».
А есть спеки нет вообще? А если она есть, но состоит из одной строки «сделать стандартный логин диалог»?
А если в конце концов там написано, что пароль должен состоять только из цифр и быть не длиннее 3 символов?
При том, что автор темы указал, что это вопрос с собеседования.
Или дали спеку с откровенным бредом.
Меня не злит, меня расстраивает то, что благодаря Савину начинающие тестировщики считают, что без хорошо расписанной спеки работать невозможно, и полностью этой спеке доверяют.
Меня не злит, меня расстраивает то, что благодаря Савину начинающие тестировщики считают, что без хорошо расписанной спеки работать невозможно, и полностью этой спеке доверяют.
Конечно я согласен, что надо думать собственной головой.
но не согласен с этим:
Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».
на XSS и SQL иньекции можно добавить по идее к форме комментария.
При том, что автор темы указал, что это вопрос с собеседования.
Или дали спеку с откровенным бредом.
Меня не злит, меня расстраивает то, что благодаря Савину начинающие тестировщики считают, что без хорошо расписанной спеки работать невозможно, и полностью этой спеке доверяют.
Если нет спеки, нет программы, то смысл тестировать воздух?
Если что и тестируется данным воздухом то стрессоустойчивость.
По поводу тестирования полей SALar в разы лучше, чем Лупан написал: Тестирование полей ввода.
Конечно я согласен, что надо думать собственной головой.
но не согласен с этим:
Это звучит как «я не хочу думать сам, пускай другой умный дядя придумает за меня, какие проверки мне надо провести».
Вы противоречите сам себе. Вместо того, чтобы подумать, что пароль должен быть от 8 до 40 символов, вы требуете этого ответа от аналитика.
А если у вас простенький форум для внутреннего использования, вас не покоробит требование сложного пароля? Меня вот такое требование удивит, я буду против насильного внедрения сложных паролей.
А если это банковская система, вас не удивит требование только букв и цифр? Я бы настаивал на том, что спецсимволы надо позволять вводить в пароле.
А если у вас логин можно вводить на русском языке, то почему запрещать вводить русские буквы и в пароле?
Ну и в целом, аналитик тоже человек и тоже может ошибаться. Аналитик может быть настолько загружен, что у него нет возможности предусмотреть все мелочи по каждой фиче.
Если тестировщик не может принять решение, что является багом, а что нет, без подключения аналитика, то грош ему цена.
Это не значит, что такой ответ не подойдёт на собеседовании в другой компании. Но новичку, который спрашивает про задачу с собеседования, важно понимать, что существуют разные варианты.
Если нет спеки, нет программы, то смысл тестировать воздух?
Если что и тестируется данным воздухом то стрессоустойчивость.
О, ещё один человек считает, что без требований работать невозможно. Жаль, но это не соответствует действительности.
Если нет спеки, нет программы, то смысл тестировать воздух?
Если что и тестируется данным воздухом то стрессоустойчивость.
О, ещё один человек считает, что без требований работать невозможно. Жаль, но это не соответствует действительности.
Где я сказал что без требований работать невозможно?
А вы на собеседованиях людям что предоставляете потестировать, реальные программы, реальные требования, или всё-таки гипотетические программы?
А вы на собеседованиях людям что предоставляете потестировать, реальные программы, реальные требования, или всё-таки гипотетические программы?
Любой реальный, известный сайт.
ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.
И вы так и не ответили:
Любой реальный, известный сайт.
ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.
Прямо в офисе? Или на дом?
Был опыт выдачи на дом приснопамятного листбоксера, показал большие временные затраты и низкую эффективность в сравнении с тестированием прямо в офисе гипотетической программы.
Любой реальный, известный сайт.
ИМХО, это более эффективно, чем гипотетическая программа и сотрясение воздуха.
Прямо в офисе? Или на дом?
Был опыт выдачи на дом приснопамятного листбоксера, показал большие временные затраты и низкую эффективность в сравнении с тестированием прямо в офисе гипотетической программы.
Не Листбоксер, ибо вы правы он плох для оценки.
Другая тестовая программа.
— Заполняем поля известными правильными данными жмём вход.
Далее негативные тесты.
— Заполняем не верными данными и вход
— Одно верными другое не верными данными и вход
— Тоже что и выше только наоборот
— Заполняем поля правильными данными жмём ок.
Далее негативные тесты.
— Какое-то из полей пустое
— Ник состоящий из смеси англ и русс букв
— Ник имеющий знаки препинания и символы
— Слишком длинный никнейм
— Слишком короткий комментарий
— Слишком длинный комментарий
— Слишком длинный комментарий состоящий из слова без пробела
Пожалуйста подкорректируйте где я не прав
Если компания ищет не рядового бойца, то скорее всего вы не прошли собеседование.
«Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество.» © Стив Джобс
Наш чек-лист для форм на сайтах
Это вторая часть наших чек-листов. В первой мы подробно разобрали требования к фильтрам. В отличие от фильтров, требования к пользовательским формам более универсальны. Однако нам потребовалось несколько жарких дискуссий, чтобы выработать более-менее единый формат. Видео с HolyWarModeOn рассказывает о типовых ошибках юзабилити в проектах. Сразу под роликом ищите подробный чек-лист для форм на сайте.
Важность: Extra High
□ Сохранение формы.
□ Форма сохраняется в веб-формах (админ-панели) или SQL-таблицах.
□ Изменение адреса отправки.
□ E-mail, на который приходят данные из веб-формы, можно менять в административной панели.
Важность: High
□ Актуальность адреса отправки.
□ Прописан реальный e-mail лица, отвечающего за обработку заявок.
Почему именно так. Ситуация из типичных будней техподдержки: владелец
интернет-магазина рвет и мечет — нет заявок от клиентов. Открываем админку, смотрим: внесен адрес svetochek1988@mail.ru, куда и попадают все запросы. Дальше объяснять нет смысла.
□ Отправка формы.
□ Данные из заполненной формы отправляются администратору на e-mail.
□ Отправка уведомления пользователю.
□ Опционально. Пользователь получает уведомление на свой e-mail об успешно полученной заявке и последующих действиях, которые от него требуются.
Навигация
□ Предусмотрены плейсхолдеры (placeholder) для полей.
□ Если названия полей не подписаны, то внутри полей выводится подсказка, которая исчезает при внесении текста.
Почему именно так. Пользователям нужны инструкции, а проектировщикам и дизайнерам — компактный способ предоставления информации.
□ Прописан атрибут autocomplete для полей, поддерживающих это значение.
Атрибут autocomplete подставляет ранее введенные пользователем данные в поле, если функция не отключена в браузере.
Почему именно так. Чем быстрее пользователь заполнит форму, тем выше вероятность, что он ее отправит.
□ Правильная работа многошаговых форм.
□ Навигация рядом с формой показывает текущий этап и количество оставшихся шагов.
Почему именно так. Неизвестность пугает посетителей и снижает вероятность полного заполнения объемной формы. Положительный пример — Asos. В форме указано пять шагов, но по факту регистрация проходит в пять раз быстрее — основные функции сайта доступны сразу после заполнения первого экрана регистрации.
Замечание. На некоторых проектах мы отказались от стандартной регистрации в пользу авторизации через социальные сети.
Пример: Restlook.
□ Многошаговые формы корректно работают при навигации посредством кнопок «Вперед» и «Назад» в браузере.
Валидация
□ Для числовых значений из определенного диапазона прописаны ограничители минимального и максимального количества символов.
□ Проверьте это для дат, времени и прочих подобных характеристик.
Почему именно так. Простая подстраховка от ввода откровенного вранья или появления ошибок по невнимательности — даты рождения в будущем или времени доставки раньше времени заявки.
□ Для полей, предполагающих загрузку файлов, прописан атрибут accept, определяющий тип загружаемых документов.
Почему именно так. Если прописан атрибут accept, при выборе с жесткого диска пользователь видит только подходящие типы файлов для загрузки — например, doc и txt. Это исключает отправку документов в формате, не подходящем для обработки.
□ Для полей, валидация которых проходит через регулярное выражение, прописан атрибут pattern.
Валидация — это проверка введенных пользователем данных на соответствие требованиям системы. Информация проверяется путем сверки с регулярным выражением, заданном в специальном формате.
Например, регулярное выражение 3 <5,10>для пароля означает, что он может состоять только из цифр, а его длина колеблется от пяти до десяти символов. Если для поля прописан атрибут pattern, то форма не отправляется, пока данные не будут введены верно.
□ Требуемый формат данных, которые должен ввести пользователь, очевиден для него.
Почему именно так. Пользователь должен понимать, чего от него ждут при вводе данных. Для этого предназначены краткие пояснения вроде «Пароль состоит не менее чем из 8 символов и включает цифры и латинские буквы».
□ Доступна инструкция по формату вводимых данных на человеческом языке.
Почему именно так. Очевидная и понятная подсказка позволяет быстро разобраться в причинах ошибки и не чувствовать себя тупым при заполнении полей формы.
□ Пользователь не видит регулярного выражения как подсказки к действию.
Почему именно так. Подсказка у поля индекса, представляющая собой регулярное выражение 9, малоинформативна. Фраза «Индекс состоит из цифр от 0 до 9» намного понятнее пользователю.
□ Сообщения об ошибках понятны обычным пользователям и логичны.
Важно. Типовая ошибка — регулярное выражение в сообщении о неверном заполнении формы.
Прочее
□ Форма запрашивает у пользователя только необходимые данные.
Откройте форму, визуально убедитесь, что требуется внести только необходимый минимум информации.
Почему это важно. Объемные формы убивают конверсии. Регистрация, покупка или обратная связь должны быть максимально простыми, чтобы не путать пользователей.
□ Если все поля обязательны для заполнения, рядом с их названиями не выводятся звездочки — символ *.
Откройте форму и убедитесь в этом визуально. Желательно наличие поясняющего текста об обязательном заполнении всех полей.
□ Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.
Убедитесь визуально, что указанная пользователем в профиле информация автоматически выводится в полях форм, запрашивающих эти данные.
□ Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого.
Откройте форму с текстовым многострочным полем, введите в него максимально большое количество символов.
Почему именно так. Многие пользователи перечитывают написанное перед отправкой. Нужно дать им возможность воспользоваться скролл-баром или просмотреть все сообщение в расширенном поле вместо перемещения по тексту с помощью стрелок клавиатуры.
□ В полях формы прописан корректный атрибут TYPE, сообщающий браузеру тип элементов формы.
□ Правильно указаны типы дат, времени, телефонов, диапазонов, url, e-mail, чисел.
□ Во время отправки формы на медленном канале пользователь не может менять в ней данные.
Важно. Действительно для ajax-форм.
Почему именно так. При невысокой скорости соединения форма ajax отправляется не сразу, некоторое время оставаясь на экране со всей внесенной информацией. Пользователь не должен в этот момент передумать и поменять все данные. Точнее, передумать он как раз может, но реализовать свою задумку — уже нет: необходима блокировка от изменений до момента получения ответа от сервера.
При этом желательно визуально показать, что форма заблокирована. Один из вариантов — прелоадер:
Важность: Low
□ Вывод подсказок и ошибок сделан с анимационным эффектом.
Замечание. Этот параметр зависит от дизайна и не является обязательным.
Далее — три спорных истории, которые нужно решать с менеджером на этапе проектирования.
□ Кнопка отправки данных неактивна, пока не активирован чекбокс «Согласиться с правилами», «Пользовательское соглашение».
□ Кнопка отправки данных неактивна, пока все введенные данные не прошли положительную валидацию.
Откройте форму с полями для ввода, введите некорректные данные, проверьте, активна ли кнопка.
Это важно. В некоторых случаях некорректность — понятие относительное. Подстава подстав — валидация номеров телефонов в форме обратной связи. Если вкратце — отключайте ее.
□ Если данные не прошли положительную валидацию, при наведении курсора на кнопку для отправки данных выводится информационное сообщение.
Откройте форму, введите некорректные данные, наведите курсор на кнопку отправки данных, проверьте, выводится ли сообщение.
Список можно распечатать — пользуйтесь для тестирования юзабилити. То же самое — в документе Google.