четверг, 3 января 2013 г.

Тестируем регистрацию на сайте Люксор

Всех новичков беспокоит вопрос - а откуда набираться опыта, знаний? Что бы потестить, в конце то концов??? Ответ прост - да все, что угодно. Вон, на форуме пишут, что люди, начитавшись Савина, даже лужи тестируют Smile :)

Давайте рассмотрим простой пример, например, регистрацию на сайте довольно известного кинотеатра - Люксор.

Итак, открываем сайт - http://www.luxorfilm.ru/cinema/center/
Нажимаем справа сверху кнопку "Войти", а потом - регистрация.

И вот перед нами более-менее стандартная форма регистрации. Как будем тестировать?



Во-первых, самое святое - это позитивный тест-кейс, то есть нормальная регистрация. Но, честно говоря, когда я вижу такие формы, я редко могу устоять и сначала провожу другой позитивный тест - на обязательность заполнения всех полей.

То есть, ничего не трогая, сразу нажимаем на "Сохранить". Наверняка у нас на более сложные формочки будет спецификация, в которой четко прописано, какие поля обязательны для заполнения, а какие - нет.

Итак, какие поля обязательны на данном сайте? Кстати сказать, по правилам хорошего тона обязательные поля обычно отмечают звездочкой. Здесь это не сделано, очевидно, потому, что все поля являются обязательными. Но все ли?



Тут мы замечаем одну интересную вещь - около полей "подтвердите пароль" и "введите код из картинки" не появилось сообщений об ошибке. Хммм...

Но, прежде чем бежать регистрировать баг, давайте убедимся, что эти поля действительно необязательны для заполнения. Бывает и такое, что, если не заполнены "основные" поля, сообщения об ошибках появляются только около них. А заполнишь их - сообщения появятся и около других полей. Так у нас и происходит с полем кода картинки. Заполняем строго те поля, около которых появились сообщения об ошибках и видим следующую картину:


Окей! Заполняем код из картинки и нажимаем сохранить - ага, пароль сбросился, это, в принципе, правильно. Заполняем пароль и код из картинки... И регистрация проходит успешно!


Тут в нашу голову наверняка закралось сомнение - а зачем нам вообще нужно поле "Подтвердите пароль", если его необязательно заполнять?

Так как эта формочка довольно простая, то даже без спецификации можно догадаться, что данное поле нужно для того, чтобы человек, вводя длинный, правильный (то есть сложный) пароль, не ошибся. Поэтому система сверяет пароль из поля "Пароль" и пароль из поля "Подтвердите пароль" и, если они отличаются, выводит соответствующее сообщение об ошибке.

На данном сайте такой проверки нет. Но ведь тогда и поле не имеет смысла. Итак, теперь можно с чистой совестью писать баг:

-------------------------------------------------------------------------------------------------------------------

Шаги для воспроизведения:
  1. Открываем сайт
  2. Нажимаем на кнопку "Войти"
  3. Нажимаем на кнопку "Регистрация" (можно было изначально дать линк на http://www.luxorfilm.ru/Users/Registration.aspx, но ведь название странички может и измениться, поэтому такую ссылку вставить можно, но как дополнение к шагам. Да да, шаги тоже могут изменяться, но их суть часто остается прежней)
  4. Заполняем все поля, кроме "Подтвердите пароль".
  5. Нажимаем "Регистрация".
Результат
Пользователь успешно создан.

Ожидаемый результат
Видим сообщение об ошибке, что введенный пароль не совпадает с паролем, введенным в поле "Подтвердите пароль".

Иначе, если поле "Подтвердите пароль" не обязательно для заполнения - его лучше вообще убрать с формы, так как никакой смысловой нагрузки оно не несет.

-------------------------------------------------------------------------------------------------------------------

Отлично. обязательность полей проверили, позитивный тест-кейс на успешную регистрацию тоже проверили. Параллельно нашли usability багу - когда ставишь курсор в какое-либо поле, ты не видишь его там. То есть, если пользователь переключается между полями с помощью кнопки Tab, он не видит, срабатывает такой переход или нет... Это некритично, но неудобно - заводим минорную багу, когда поправят, тогда поправят.

Кстати, насчет заведенной нами баги про обязательность поля. Казалось бы, ну кто будет так делать, да? Оставлять поле пустым? По крайней мере, специально... А как вы думаете, я на это наткнулась - занималась в праздники тестированием рандомных сайтов? Smile :)

Итак, user-story, как я дошла до жизни такой, а точнее, до такого блог-поста:

Собрались мы "назавтра" в кино. Разумеется, чтобы места были хорошими, их лучше забронировать заранее, например, вечером предыдущего дня. Открываю сайт Люксора - не открывается Sad :(

Мда, бывает с ним такое... Ладно, тогда пытаюсь забронировать билеты на следующий день, уже перед выходом. Ура, сайт работает! Выбираем сеанс, места, подтверждаем, что согласны с условиями бронирования и-и-и-и... А где кнопка "забронировать"???

Да что ж такое-то... Ладно, вон там есть кнопка "Войти", может, если войти в систему, то будет бронь работать? Сомнительно, конечно, но вдруг? Итак, регистрируемся, email, ФИО, пол... А хотя зачем им моя дата рождения? Нажимаем сразу "Регистрация"!

Упс, логин и пароль не заполнила, и правда, куда без них. Заполняем, нажимаем "регистрация", и... Взгляд утыкается в строку "подтвердите пароль", которую я, разумеется, не заполнила, так как спешу и мысли о другом. Что сказали заполнить, то и заполнила... И вот сейчас сайт продумается и выдаст мне новое сообщение об ошибке... А так как он сегодня тугодум, то это лишнее время...

И вдруг перед моим изумленным взором возникает сообщение об успешной регистрации о_О

А ведь не искала специально...

Но что-то мы отвлеклись. Раз уж решили обсудить, как будем тестировать эту формочку, то давайте закончим рассуждения:
  1. Проверяем обязательность заполнения полей - нажимаем "Сохранить", ничего не заполнив, смотрим, где появились сообщения об ошибках.
  2. Проверяем план-минимум, то есть заполняем только обязательные поля и убеждаемся, что внутри системы не зашито обязательным какое-то необязательное поле.
  3. Проверяем план-максимум, то есть заполняем вообще все, а после регистрации в личном кабинете проверяем, что информация сохранилась правильно.
  4. Пока мы прошли первые 3 шага, заодно проверили и юзабилити формы регистрации, вон, даже багу нашли.
  5. Теперь пора докапываться до самих полей. Итак, заполняем все поля корректно, кроме поля "email" - вводим туда что-нибудь, не являющееся email-ом. Ок, сообщение об ошибке есть. Отлично. Копаем дальше - а если email невалидный, но содержит "@"? А если он косит под валидный, но не является стандартным? Например, aaa@bbb.cc? Итд. Сверяем со спецификацией - какие проверки должны быть у поля, соответствуют ли они реальности? Потом смотрим, а какова максимальная длина поля? О, 64 символа? Вводим граничное значение, проверяем, что работает. Потом вводим 65 символов, проверяем, что не работает. Потом ищем технологическую границу (то есть вводим ооооочень длинное значение, ну, скажем, нажимаем "9" и зажимаем кнопочку секунд на 5-10) - вдруг сайт упадет?
  6. Остальные поля, например, ФИО, проверяем на длину, если нет других ограничений.
  7. Вот разве что дата требует отдельного внимания. У меня, например, календарь вообще не открывается, можете кидать помидоры в сторону ИЕ, но мне лениво пробовать в мозилле. Хотя, если бы надо было протестировать, протестировала бы везде. Опять же, прежде чем заводить багу "не открывается popup календаря", надо локализовать проблему - он вообще не открывается или только в вашем браузере? Когда видите такие проблемы в веб-приложениях, всегда локализовывайте проблему. Далее. Вводим дату вручную - корректную, нижнюю границу (что-то типа 01.01.0001) и верхнюю (01.01.3333), веб-сайты, кстати, часто падают на таких некорректных значениях просто потому, что они не могут их обработать, код соответствующий не написан.
И последний, 8 пункт - на закуску осталось самое интересное. Казалось бы, на такой простой формочке уже все проверено? Ан нет. Попробуйте ввести неправильные данные, а потом - правильные. Желательно иметь доступ к БД, чтобы быть точно уверенным, что тест корректный.

А именно - вводим все поля, выбирая логин, например, "а1". А вот email указываем некорретный. Появляется сообщение об ошибке, мы ее исправляем и снова пытаемся зарегистрироваться. Но теперь нам выводится сообщение о том, что пользователь "а1" уже существует в системе! Но ведь он не был зарегистрирован!

Вот для того, чтобы в этом убедиться, нам и нужна БД - изначально делаем select, проверяя, что пользователя "а1" в системе нет. Потом регистрируем его так, чтобы регистрация не удалась, а потом корректно. И если мы видим сообщение об ошибке "пользователь "а1" уже существует в системе" - смело идем и регистрируем багу. Так как при ошибочном вводе транзакция должна откатываться, а не сохраняться в БД.

Резюмируем:
  1. Обязательность полей.
  2. План-минимум.
  3. План-максимум.
  4. Юзабилити.
  5. Длина полей для ввода.
  6. Спец проверки для email.
  7. Спец проверки для даты.
  8. Корректный ввод после некорректного.
Кстати, хочу заметить, что, если вы новичок и имеете только теоритический опыт, гораздо лучше будет, если, приходя на собеседования, вы не просто будете важно заявлять "Я прочитал Савина", а показывать, как вы применили эти знания. Или хотя бы пытались применить.

Например, "я люблю ходить в кино и поэтому, прочитав такие-то книжки, я решил попробовать свои силы на любимом сайте и провести функциональное тестирование системы. Я открыл формочку регистрации и провел такие-то и такие-то тесты. Сделал я это потому-то и потому-то. И даже баги нашел, представляете? Такие-то и такие-то. И даже в суппорт им написал, вот так-то и так-то (тут мы показываем, как умеем красиво, четко и понятно формулировать баги)". Это будет показывать как минимум вашу заинтересованность, ваш энтузиазм и стремление учиться!

Просто попробуйте, открыть часто посещаемый сайт и попробовать его протестировать. Это поможет вам структурировать свои знания и чувствовать себя увереннее! А иначе получится так, что - приходишь на собеседование, четко рассказываешь заученные формулировки функционального и нагрузочного тестирования... А потом тебе дают простенькую формочку - "как будешь тестировать?". И все, ты начинаешь волноваться, разом забываешь только что рассказанные определения, путаешься в показаниях и прочая прочая.

А если ты уже сам, дома, посидел над любой формочкой, подглядывая в книгу, поразмышлял, а какое тут возможно функциональное/smoke/нагрузочное тестирование, то и сидя на собеседовании, ты будешь чувствовать себя увереннее - потому что ты уже практиковался, а значит, есть не просто слова, а понимание этих слов.

PS — и напоследок, еще одна бага из этого кинотеатра. Пришли мы в зал, места 9 и 10. Сели. И тут я смотрю перед собой - на спинках впереди-сидящих ведь тоже дублируются номера кресел. И что я вижу? После 9 идет 12 Smile :)



На самом деле там забавнее, идет такая нумераци - 8, 9 , 12, 11, 12. Но сфотографировать это не удалось, увы. Вот вам и еще одна бага! Зато забавная:

- У тебя какое место?
- 12.
- Тебе справа или слева? Smile :)

PPS — а еще про одну багу я писала позднее, на этот раз про бронирование билетов на сайте.

PPPS — добавила пост в общую копилку багов.

41 комментарий:

  1. отличный обзор. как раз начал изучать тестирование сайтов. очень доступно написано.только не понятен был пункт про технологическую границу.


    Савина тоже начал читать.

    ОтветитьУдалить
    Ответы
    1. Про технологические границы просто отдельная песня - чтобы их найти, обычно вводят очень большие значение, например, двести девяток (мы помним, что поле ограничено 64 символами).

      Есть даже специальные инструменты, которые генерируют строки нужной Вам длины, но самый простейший тест - встать на поле и зажать любую кнопку :) Подержать какое-то время и попробовать сохранить. Вот если упадет, тогда и стоит искать ту самую границу, проверяя, что "ага, на 99 символах не падает, а на 100 - уже падает"

      Удалить
    2. Но спасибо за комментарий! :)

      Удалить
    3. ага, значит вот оно что такое:)

      Удалить
    4. Подробнее, конечно, можно узнать на курсах по тест-дизайну, но самый простой тест на поиск технологических границ именно такой - зажать и держать :) А потом проверить, не упадет ли система на таком вводе

      Удалить
    5. Добрый день, Ольга. подскажите, имеет ли смысл искать эту тех.границу, использую черноящечный подход? не займет ли время? ведь она может проявиться и на 300...600...1000..сиволов. что вы посоветуйте для такого случая? Спасибо:)

      Удалить
    6. Юрий, 300 символов для поиска технологической границы — это слишком мало :) 21 век на дворе, технологии так давно не ограничивают. Для ее поиска пытайтесь сразу много ввести, см, например, http://okiseleva.blogspot.ru/2015/08/blog-post_8.html

      Удалить
  2. Ответы
    1. а вот скажите,если б этот проект был реален, то на него нужно было б создавать тест-кейс в письменном/электронном виде? Просто,я только начал читать Савина, раздел про тест-кейсы,и мне кажется что цель тестировщика проверить работоспособность а не заниматься бумажной работой.

      Удалить
    2. Владимир, все зависит от проекта!
      Если для вас тест-кейсы - это просто бумажная работа, то не стоит их писать. Лучше ограничиться чек-листами.

      Тест-кейсы нужны, в основном, когда большой и сложный проект, на котором много людей. Чтобы любой мог пройти любой набор тест-кейсов.

      Если проект маленький и на нем всего пара тестировщиков, полностью его знающая, достаточно составить чек-листы. Это менее подробная вещь, фактически просто список того, что надо не забыть проверить.

      Потому что вообще без документации можно про что-то важное забыть, что-то упустить из виду.

      Удалить
  3. Большое спасибо за такой интересный обзор, открыла для себя много деталей, т к опыт тестирования еще совсем небольшой.


    Еще такой вопрос: а есть нет доступа к БД? Отдельно создавать систему для тестов с формой, БД и прочим не будешь же, а попрактиковаться "на кошках" хотелось бы с имеющейся базой данных...Есть ли какие-то проекты, где это можно сделать? Или это пока из области фантастики?

    Заранее спасибо за ответ!

    Ирина

    ОтветитьУдалить
  4. А почему не будешь?

    Создать БД очень легко - http://okiseleva.blogspot.ru/2012/01/blog-post_13.html
    Это если хочется потренироваться в SQL.

    Если с формочкой, то:
    десктоп - http://okiseleva.blogspot.ru/2012/02/win-forms.html
    web - http://okiseleva.blogspot.ru/2012/02/web-application.html

    А еще, если хотите подтянуть SQL, идите к Татьяне Зинченко на курсы, там Вы получите схемы создания БД :)
    Или у Алексея Баранцева на курсах тест-дизайна или программирования можно получить доступ к приложению + его БД.

    Тут вопрос, а зачем Вам приложение с доступом к БД?
    Выполнять один тест и тут же селектить данные из БД, проверяя и ее? Так мало кто делает :))
    Если просто для SQL, то тут хватит своей собственной БД, сначала научился создавать ее, потом изменять итд

    ОтветитьУдалить
  5. БД создавать я умею. Мне интересен сам тест-процесс больше, поэтому и спрашивала, есть ли такие варианты, которые можно уже тестироватьс разу, не отвлекаясь на другие моменты.
    К сожалению, территориально я нахожусь не в России, так что с курсами вряд ли получится.

    Кстати, в Google Chrome выше указанная Вами ссылка как-то странно выглядит.
    http://okiseleva.blogspot.ru/2012/02/web-application.html

    После слов:
    "Потом указали, что DataSource нашей таблички – тот самый отчет. И Заполнили ее командой DataBind. После чего завершили транзакцию." идёт картинка, которая выходит за поля поста вправо и частично перекрывает ссылки на другие посты в сайдбаре.
    Вот картинка: http://www.dropmocks.com/mBss0A
    Может быть, так надо, не знаю:)

    В любом случае, спасибо Вам за ответ, с удовольствием читаю Ваш блог дальше!:)

    ОтветитьУдалить
    Ответы
    1. Спасибо, поправила картинку!

      На самом деле все равно немного непонятно, зачем нужно приложение с Базой Данных? Какой именно тест-процесс Вы хотите проверить? Часто, кстати, у тестировщиков нет доступа к БД, работают вслепую :)

      А курсы, о которых я написала выше - онлайн, так что подходят для всех городов, неважно каких, получаете запись, задаете вопросы, делаете ДЗ, получаете фидбек :)

      Удалить
    2. Спасибо!
      По поводу базы данных. Да...возможно и не нужно:) У меня небольшой опыт мануального тестирования, где в основном доступ к базе данных был. Проще было искать причины ошибок, иногда это и не баги были вовсе, как выяснялось, а проблемы в конфигурации тестовой системы, например.

      Удалить
    3. Я тоже считаю, что не нужно :)
      Опыт придет с практикой. Если тестировщик имеет познания в своей области, но не сталкивался с конфигурацией - возьмут и научат. А "тестировать на кошках" в данном случае мало полезно. Так тебе объяснят, где именно среда настроена неправильно, а на тестовом приложении самому копаться.
      В любом случае, нигде не применяемые на практике знания быстро забываются. Так что не так страшно пытаться протестировать без доступа к БД - зато можно тестировать все, что угодно!

      Удалить
  6. Как всегда доступно написано, спасибо)) Есть вопросик, я сейчас пишу тест-кейсы на регистрацию на форуме, и мне подсказали про разделение на позитивное и негативное тестирование, разве это все? Я для себя это все структурирую в майнд мапе и какой-то он скудненький получается...может подскажите как это все преобразить))

    ОтветитьУдалить
    Ответы
    1. Ирина, спасибо ))
      Регистрация на форуме врядли сильно отличается от того, что описано в статье :)
      Если надо именно структурировать по умным словам, то вначале позитивное и негативное тестирование. Потом выделение классов эквивалентности для поля каждого типа (строка, дата, список выбора) и граничные значения. Еще можно выделить используемые технологии, язык разработки, база данных, тайминг (время загрузки), sql-инъекции, в конце концов :)

      Удалить
  7. Спасибо)) ну я так понимаю получается только 2 позитивных тест-кейса?

    ОтветитьУдалить
    Ответы
    1. Мы можем зарегистироваться, а можем отменить регистрацию.
      2 основных сценария, оба позитивные. Остальное уже идет ответвлениями

      Удалить
    2. а к чему мы тогда относим обязательное заполнение всех полей?

      Удалить
    3. Заполнение всех обязательных полей - к позитивному тесту на корректную регистрацию

      Удалить
    4. то есть я так поняла если не углубляться глобально, в регистрации есть 2 ответвления: позитивное тестирование и негативное, а от них уже идут еще ответвления и еще...)

      Удалить
    5. Исходное ветвление вообще можно любым выбрать.
      Позитивное-негативное - один из вариантов.
      Можно посмотреть в книге Савина (бесплатная в интернете есть версия) классификацию типов тестирования. Выбирайте любой, какой нравится :) Суть не в определениях, суть в том, что нам надо проверить и какое тестирование от нас ожидают

      Удалить
  8. В "Резюмируем" можно добавить пункт
    9. Создание уже существующего пользователя. С идентичным email, логином и т.д.

    ОтветитьУдалить
    Ответы
    1. Да, хороший пункт :)
      При проверке регистрации очень нужен. А еще удалить пользователя и снова завести - но это не всегда доступно тестировщику

      Удалить
  9. Ольга, благодарю за статью)
    Проверила многострадальный сайт Люксора. Ввела при регистрации электронный адрес qqqqqqqqqq@qqqq.qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
    Выдало "Ошибка доступа к БД
    SAC-0000 Invalid address" НО! Без подтверждения аккаунт зарегистрировали и я даже смогла забронировать билеты.
    В общем пошла тестировать сайты своего родного города и писать тест-кейсы подробные и понятные)

    Спасибо еще раз)

    ОтветитьУдалить
    Ответы
    1. Пожалуйста! Рада, что статья вам пригодилась ))) И удачи в тестировании! ))

      Удалить
  10. Ольга, помогите, пожалуйста. Вопрос по реальному тест-кейсу формы регистрации. Я проверяю позитивные сценарии, имя латиница, имя кириллица. Шаги писать нужно конкретно. Введите логин такой-то. Тогда каждый последующий, кто будет выполнять тест-кейс, не сможет зарегистрироваться, тк логин будет уже занят. Предполагаю, что можно предложить вводить логин и почту по формуле, связанной с номером выполняющего . login1 и почта login1@ya.ru для первого, login2 для второго и тд. А как на практике это делается?

    ОтветитьУдалить
    Ответы
    1. А зачем писать один комментарий под несколько постов? Ответила под постом про тест-кейсы

      Удалить
    2. Простите, пожалуйста, он у меня там не отобразился. Поэтому написала заново и в другом посте. Спасибо огромное за ответ!

      Удалить
  11. Привет! Там кстати грамматическая ошибка в тексте на скрине после предложения "И регистрация проходит успешно!" Написано "зерегЕстировались", а должно быть "зерегистрировались"

    ОтветитьУдалить
    Ответы
    1. Тоже верно! Прекрасный баг в документации :-)

      Удалить
  12. привет!
    Можете подсказать как писать позитивный тест кейс по usability?

    ОтветитьУдалить
    Ответы
    1. Ровно также, как и все остальные )
      Что у вас за задача, Дмитрий? Если это тестовое, погуглите, что такое юзабилити, а там тест несложно будет придумать

      Удалить
    2. задача протестить сайт)

      Просто в голову не приходит как написать поз тест по юзабилити,
      Уже на многих сайтах много поперечитывал. Возможно вы меня поправите. На главной странице нашол граматическую ошибку. Как её описать знаю) а вот как позитивное?

      Удалить
    3. Вы путаете понятие бага и теста.
      Тест — прочитать текст на сайте, проверить его адекватность, соответствие ТЗ и прочая. А вот если нашли ошибку, это уже баг.

      Как делать позитивные тесты, см статью http://okiseleva.blogspot.ru/2014/02/blog-post_10.html

      Удалить