Текст книги "Базовые знания тестировщика веб-приложений"

Профессия Тестировщик

Если Вы еще не определились, кем хотите стать, или ищете работу, но предложенные вакансии Вас не устраивают, то обязательно рассмотрите такую профессию, как “Тестировщик программного обеспечения”. Она позволит Вам влиться в сферу ИТ, даже не имея профильного образования. Работа в ИТ всегда оплачивается выше, чем в других отраслях, вакансии есть в любом городе, Вы не будете сокращены в кризис, и Вам не придется работать на морозе. Сейчас существует большое количество ИТ-компаний, ведущих международный бизнес, поэтому работа в них еще и престижна. Работая тестировщиком, Вы всегда будете развиваться профессионально и сможете освоить другие профессии в ИТ. Работая в международной компании, Вы еще и улучшите свои знания английского языка.

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

Главная задача тестировщика – проверить, что программа работает так, как этого хотел заказчик (клиент). Другими словами, он должен проверить, что работают все описанные в документации функции, при их выполнении не возникает ошибок, а также нет ничего лишнего. Обо всех несоответствиях, ошибках и прочих проблемах тестировщик сообщает программисту, который будет их устранять. На профессиональном сленге любую проблему в работе программы называют багом (с английского bug – жук). Согласно Википедии, по одной из версий, в 1946 году учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник с сопроводительной надписью: «First actual case of bug being found» ("первый реальный случай, когда был найден жук"). Еще одно модное словцо, крепко засевшее в лексикон ИТ-специалистов – это фича (с английского feature – особенность, свойство, фишка). Большинство команд разрабатывают программы итеративно, то есть вначале пишут минимальный базовый функционал, а затем понемногу его расширяют. Так вот, каждое такое небольшое изменение в программе и называют фичей. Теперь, пользуясь сленгом, можно сказать, что задача тестировщика – это тестировать фичи и заводить баги.

Давным-давно, когда написание программ и пользование ими было уделом лишь группы ученых в крупных научных центрах, тестированию не уделяли столько времени, сколько сейчас. Если у пользователей возникали проблемы, то они писали письмо издателям с описанием проблемы. В ответ они получали по почте дискету с исправлениями. С ростом количества пользователей издателям становилось все труднее обрабатывать все их запросы. Им приходилось всё тщательнее проверять свои программы перед их распространением, чтобы не получить кипы гневных писем. Также с ростом количества издателей у пользователей появился выбор и они стали делать его в пользу издателей, делавших более качественное ПО. Программисты стали тратить существенную часть своего рабочего времени, занимаясь проверкой работоспособности. Для того, чтобы проверить работоспособность приложения, не обязательно знать, как оно устроено и как его написать. Поэтому, в помощь программистам стали давать людей, не имеющих опыта программирования, но имеющих опыт пользования программами. Это позволило программистам уделять больше времени написанию кода и исправлению ошибок, а также облегчило поиск новых сотрудников, так как сократился список требований к кандидату. Так появилась профессия “Тестировщик программного обеспечения”. Впоследствии на плечи тестировщика легли и другие задачи, возникающие в процессе разработки ПО: сбор требований, ведение документации, поддержка пользователей. Чем больше тестировщик сможет выполнить работы, которую делал бы программист, тем больше он будет получать зарплату. Обычно зарплата тестировщика составляет около 75% от зарплаты программиста того же уровня. Поэтому постоянно расширяйте спектр ваших навыков, чтобы достичь этой цифры или даже превысить её. Большинство книг по тестированию советуют тестировщикам никогда не говорить: “Это не моя работа”.

От программистов нередко можно услышать, что во всех бедах виноваты тестировщики. Не стоит принимать это всерьез и думать, что они хотят свалить на Вас всю вину за любую оплошность. Из этой фразы нужно извлечь только один вывод: большая ответственность – это большие полномочия. Если Вы столкнулись с серьезной проблемой, то бейте во все колокола. Трясите всех, кто может помочь Вам в ее решении, особенно тех, кто говорит, что Вы в чем-то виноваты. Навыки общения с людьми и умение работать в команде (soft skills) для тестировщика важны даже больше, чем его компетенция в тестировании. Например, тестировщики терпят фиаско в своей карьере из-за нерешительности подойти и сообщить о серьезной проблеме (возможно возникшей по их вине), из-за того, что не смогли убедить, почему она столь критична или из-за того, что побоялись выглядеть глупо, попросив помощи.

Поиск работы

Поиск вакансии нужно вести по ключевым словам ”Тестировщик”, “Специалист по качеству” или “QA”. QA (Quality Assurance) – название профессии “Тестировщик ПО” на английском языке. Откликаясь на вакансию, вышлите резюме. Ниже представлен список навыков, наиболее интересных потенциальному работодателю. Если Вы обладаете чем то из этого списка, то упомяните об этом в резюме:

Навыки программирования, в том числе написание скриптов (PowerShell или bat-файлы);

Опыт работы с базами данных (администрирование и написание запросов к базе);

Опыт работы с CMS (Content management system). CMS – это программы, позволяющие быстро создавать сайты по заранее подготовленным шаблонам (joomla, wordpress, bitrix);

Администрирование OS семейства Windows или Linux;

Знание английского языка;

Опыт написания технической документации;

Техническое образование;

Игровой опыт (Только для игровых проектов)

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

На собеседовании на должность тестировщика чаще всего встречается три типа вопросов:

1) Как бы Вы протестировали тот или иной предмет. Вся суть этих вопросов выяснить, как кандидат понимает суть тестирования. Почему-то распространено ошибочное мнение, что хороший тестировщик обязательно должен что-то сломать или вызвать ошибку в работе программы. Это не совсем правильно. Конечно, полезно узнать слабые места в приложении, но в первую очередь, нужно убедиться, что оно корректно выполняет все основные функции. Например, плохо, если калькулятор ломается при делении на ноль, но куда хуже, если он выдает 5 при умножении 2 x 2. Например, Вас попросили рассказать о том, как Вы будете тестировать стул. Хороший кандидат скажет: “сначала я сяду на него и посижу 5 минут", плохой скажет: “я кину его с 3-х метровой высоты ”.

2) Что Вы будете делать, если у Вас возникла проблема. Например, у Вас есть ноутбук и компьютер. Оба подключены к роутеру. Роутер подключен к интернету. На ноутбуке есть интернет, а на компьютере нет. Ваши действия? Цель такого вопроса – выяснить не только ваши знания, но и насколько эффективно Вы решаете проблемы. Лучше всего здесь будет ответ типа: «попробую сделать то-то и то-то. Если не получится, то поищу решение в интернете. Если и 30 минут поиска не даст результата, то обращусь за помощью». Важно показать здесь Ваше стремление преодолеть проблему, попытаться сначала сделать это самостоятельно, а лишь потом просить помощи.

3) Логические задачи. Чтобы выяснить, какие действия привели к возникновению ошибки и найти кратчайший путь для ее воспроизведения, иногда приходится хорошенько поломать мозг. Поэтому на собеседованиях дают задачки, чтобы проверить, насколько сообразителен кандидат. Если решить задачку не получается, то хотя бы делайте вид, что стараетесь решить её. Давайте больше версий, делайте предположения. Не стесняйтесь просить подсказку. Вот пример типичной задачки: у Вас есть два шнура (фитиля). Каждый шнур, подожженный с конца, полностью сгорает дотла ровно за один час, но при этом горит с неравномерной скоростью. Как при помощи этих шнуров и зажигалки отмерить время в 45 минут?

В остальном собеседование не отличается от собеседования на любую другую специальность. Желаю удачи и терпения в поиске работы.

Состав команды

Если Вы успешно прошли собеседование, то, скорее всего, Вас познакомят с наставником, который будет вводить Вас в курс дела. Обычно их называют менторами (с латинского – учитель, воспитатель). Их назначают из числа наиболее опытных тестировщиков. В небольших организациях ментор будет совмещать свою основную работу и общение с Вами. Он познакомит Вас с основами теории тестирования и даст несколько тестовых заданий. Возможно, Вам предстоит сдать внутренний экзамен. После успешной сдачи экзамена Вас уже направят на работу над проектом.

Большинство команд состоит только из программистов и тестировщиков. Ведущий программист (dev lead) – главный среди программистов. Он распределяет задания, просматривает код, написанный другими программистами (code review), оценивает трудозатраты, пишет наиболее сложные участки кода, выполняет выкладку кода на демонстрацию заказчику и на продуктовый сайт. У тестировщиков также есть свой лидер (test lead). Его основные задачи: написание тестовой документации, повторное тестирование (overview testing), оценка трудозатрат на тестирование, редактирование багов, заведенных другими тестировщикам.

В зависимости от специфики проекта могут быть и другие роли. Например, в крупных финансовых приложениях в состав команды также входит аналитик. Его главные задачи: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла. Если возникают противоречия, то аналитик ищет пути решения, и своими выводами он делится с клиентом.

Верстальщики помогают программистам реализовать пользовательский интерфейс – пишут разметку страницы и ее стили. Тестировщики со знанием основ программирования (SDET – Software Development Engineer in Test) пишут автоматизированные тесты.

Цикл Разработки ПО

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

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

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

Написание спецификаций. На этом этапе вся переписка должна быть упорядочена и зафиксирована в одном месте. Обычно этим занимаются тестировщики.

Написание кода. Когда все требования собраны, программисты приступают к реализации. Тестировщики не участвуют в этом процессе, но и не сидят без дела. Они готовятся к тестированию, например, пишут списки того, что должно быть проверено (Check-list), или занимаются другим функционалом.

Написание автоматизированных тестов. Чаще всего их пишут для покрытия уже готовой функциональности (регрессионное тестирование). Тесты запускают для того, чтобы проверить, что последние изменения ничего не поломали в существующем коде. Их написанием обычно занимаются опытные тестировщики со знанием основ программирования. Также сейчас становится популярной практика написания автоматизированных тестов до того, как будет написан какой-либо код – Test Driven development.

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

Тестирование клиентом. Клиент также тестирует готовый продукт, чтобы убедиться, что все сделано так, как он хотел. Также клиент может найти пропущенные баги. Обо всех своих замечаниях он сообщит в письмах. Обязанность тестировщика – ознакомиться с письмами и попытаться воспроизвести проблему в своей тестовой среде. Если это баг, и его удалось воспроизвести, то тестировщик должен завести баг в баг-трекере и передать его на починку программисту. Если клиент сообщил о несоответствии продукта его ожиданиям, то тестировщик должен выяснить от клиента все детали и дать задание программисту по устранению этого несоответствия. Также бывает, что клиент не смог разобраться, как пользоваться новыми фичами. В этом случае тестировщику необходимо лишь снабдить его детальными инструкциями.

Выкладка кода в тестовую среду. Продуктовый сайт – это сайт, которым пользуются реальные пользователи. Это конечный пункт назначения. Залив на него новый код, можно столкнуться с непредвиденными проблемами. Их устранение может привести к простою сайта. Это, непременно, вызовет большое недовольство пользователей или даже приведет к финансовым издержкам. Быстрая починка багов на продуктовом сайте может принести еще большие проблемы. Поэтому, как только клиент одобрит новый код, его следует выложить в тестовую среду (Stage environment). Он представляет собой полную копию продуктового сайта (иногда даже с базами данных). Это позволит узнать, какие проблемы могут возникнуть на продуктовом сайте, а также произвести тестирование в условиях приближенных к реальным. Задача тестировщика – проверить работоспособность сайта после выкладки.

Выкладка кода на продуктовый сайт. Выкладка кода на продуктовый сайт – это наиболее ответственный этап во всем процессе разработки. Выполняется он по такому же сценарию, что и выкладка кода на тестовый сайт. Если Вы используете один сервер, то всю процедуру нужно выполнить максимально быстро, чтобы сократить время простоя сайта. Использование нескольких серверов немного снижает риски, но увеличивает трудозатраты. При таком подходе один из серверов отключают. Вся нагрузка распределяется на оставшиеся серверы, поэтому выкладку лучше выполнять в часы с минимальной нагрузкой (выясняются опытным путем). Затем обновляют код отключенного сервера, тестируют его и включают обратно. Вся процедура повторяется до тех пор, пока не будут обновлены все серверы.

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

Начало Работы

Попадая в команду, новый тестировщик оказывается в “колыбели”. Вся наиболее сложная работа проделана более опытными коллегами. Новичку, скорее всего, доверят тестирование какой-нибудь новой фичи, по которой уже собраны все требовании и написаны чек-листы (Check-list – список того, что нужно проверить при тестировании). После новичка всё еще раз протестируют. Здесь как раз можно хорошо проявить себя, поэтому вначале мы рассмотрим подходы к тестированию c наиболее распространенных элементов приложения.

Начнем с формы с несколькими полями, в которые нужно что-то ввести. Данные будут сохранены при нажатии на кнопку. Для простоты в начале на нашей форме будет только пара текстовых полей и собственно кнопка – “Сохранить” (Submit).

Первым делом нужно проверить, что форма хоть как-то работает и готова к тестированию. Для этого выполним самый позитивный кейс (case). Кейс – это тестовый случай. Если весь процесс тестирования разделять на кусочки, то кейс – это минимально возможный кусочек, как квант для энергии или фотон для света. Под самым позитивным кейсом понимают действия, которые пользователи будут выполнять чаще всего. Например, в поле “Имя” пользователи чаще всего будут вводить значения типа “Иван”, “Петр” и т.д., а затем будут нажимать кнопку [Submit]. Это и будет самый позитивный кейс. Начинать тестирование всегда нужно с самых позитивных кейсов. Это непреложная истина тестирования. Начинать тестирование поля “Имя” с ввода строки типа “?><@!#” – дурной тон. Скорее всего, Вас посчитают дилетантом или человеком недалеким. Если позитивный кейс не прошел, то возвращаем эту форму на доработку с комментарием: “Плохое альфа-тестирование. Позитивные кейсы не проходят”. Альфа-тестирование – это тестирование, которое должен делать программист перед тем, как отдать новый функционал (feature) тестировщикам. Он должен проверить позитивные кейсы. Программисты нередко ленятся это делать, считая тестирование чем-то недостойным их величества, за что могут получить от руководства, ибо потратили время тестировщика впустую. Тестировщик должен искать сложные баги, придумывая разнообразные ситуации, а не открывать форму и видеть, что ничего не работает.

К сожалению, мне приходилось видеть тестировщиков, которые начинали тестировать нерабочую форму с извращенных кейсов и даже заводили баги типа “Данные не сохраняются при вводе кавычек”. Подобные баги не имеют смысла, если форма не работает ни при каких условиях. Хуже того, они вводят всех в заблуждение, программист начинает повторять действия, описанные в баг-репорте, хотя не все настройки были сделаны или программа установлена неправильно. Распутать подобные ситуации бывает непросто – будьте внимательны и профессиональны.

Итак, позитивные кейсы прошли и перед нами работающая форма – введенные данные сохраняются в базу данных. Здесь нужно уточнить, что для действительно хорошего тестирования тестировщику нужно иметь доступ к тому месту, где хранятся данные, с которыми работает программа. Чаще всего в веб-приложениях таким местом является реляционная база данных. Чтобы извлечь из нее данные, нужно написать запрос на языке, который она поддерживает. Обычно это язык SQL. Освоить простые запросы можно за несколько минут. Для начала этого вполне будет достаточно. Возможно, в вашем проекте данные хранятся как то по-другому, но это не меняет сути – необходимо получить возможность контролировать, что данные действительно сохранены. Конечно, можно поверить пользовательскому интерфейсу, где после нажатия на кнопку [Submit] нам сообщат, что данные успешно сохранены, но где гарантия, что это действительно так.

Приступим к тестированию отдельных полей нашей формы. Начинать тестирование нужно с ознакомления с требованиями к готовому продукту. Возможно, не все аспекты работы отдельных элементов были освещены в требованиях в силу различных причин. Возможно, заказчик доверяет Вам самостоятельно определить незначительные детали, давая лишь общее представление о новом функционале. Например, может быть не уточнено, какое количество символов может принимать поле “Имя”. Поэтому мы будем руководствоваться здравым смыслом в определении максимальной длины ввода, и не будем раздражать заказчика большим количеством вопросов. На данном этапе мы будем считать, что все ключевые требования собраны и понятны, а остальные аспекты интуитивно понятны. О проблемах сбора требований мы поговорим в поздних главах этой книги. Далее рассмотрим подходы к тестированию основных типов полей – текстового поля, текстового поля с автозаполнением, выпадающего списка и т.д.

Текстовое поле (Input text field) – это основной элемент, предназначенный для ввода текстовых данных. Что нужно проверить:

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

– Пользователь может ввести с клавиатуры все разрешенные символы. Бывает так, что поле имеет защиту от ввода некоторых специальных символов. Поэтому нужно проверить, что разрешённые символы не под запретом. Проверьте, что не возникает ошибок при сохранении данных, имеющих все разрешенные символы. Особенно важно это проверить, если поле должно принимать все символы, которые можно ввести с клавиатуры. Чаще всего возникают ошибки при вводе символов, которые являются зарезервированными в таких языках как XML, JSON, HTML, SQL, так как эти языки используются для передачи и хранения данных. Использование зарезервированных символов может нарушить работу приложения, если они не были преобразованы в специальную последовательность разрешенных символов (escape or encode). При извлечении данных из базы происходит обратное преобразование (decode). Весть процесс не заметен для пользователей.

Примеры того, в какую последовательность преобразуются символы в XML:

" – "

' – '

< – <

> – >

& – &

Примеры зарезервированных символов в различных языках:

XML: ‘ “ < > &

HTML: ‘ “ < > &

JSON: ‘ “

SQL: ‘

– Поле разрешает ввести количество символов, указанное в требованиях, но также не разрешает превысить это количество. Плохо, если поле разрешает ввести большее количество символов, чем нужно. При попытке сохранить строку с длиной, превышающей максимальную для этого поля, случится ошибка или часть строки обрежется. Если количество символов не оговорено, то проверьте, что оно достаточно, руководствуясь здравым смыслом.

– Проверьте, как сохраняется пустое значение (в поле ничего не введено), если оно разрешено, конечно. Оно должно сохраниться в базу как NULL (специальное значение, которое используется для заполнения пустых ячеек).

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

Валидация

Говоря об элементах ввода, нельзя не упомянуть про такое понятие, как валидация. В нашем контексте валидация – это проверка данных перед сохранением. Мы проверяем, что данные соответствуют нашим ожиданиям. Например, мы проверяем, что в числовое поле пользователь не ввел буквы. Валидация позволяет нам избежать заведомо некорректных данных и повышает стабильность работы программы. Если пользователь пытается ввести некорректные данные, то при срабатывании валидации пользователю будет выведено сообщение о том, что он сделал не так и как это исправить. Чаще всего валидация срабатывает при нажатии на кнопку [Submit], но бывают и другие способы вызвать валидацию. Об этом чуть позже. Работа валидации также должна быть описана в требованиях. Частично она вытекает из требований к типу и формату данных, принимаемых полем.

Что может проверять валидация:

– обязательность заполнения поля;

– запрещенные символы;

– формат введенных данных;

– уникальность данных;

– истинность данных (Captcha).

Валидация на обязательность заполнения поля – наиболее частый кейс. Ее работу легко проверить. Оставьте обязательное поле пустым и нажмите кнопку [Submit]. Мы должны увидеть сообщение об ошибке, например:

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

Большое количество обязательных полей может вызвать раздражение у пользователей, так как требует от него больших усилий. Поэтому, делая поле обязательным, задайте себе два вопроса:

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

2) Можно ли заполнить обязательное поле каким-нибудь значением по умолчанию. Например, ваш интернет-магазин делает доставку только по Москве и Московской области. Поэтому поле “город” лучше всего не оставлять пустым, а по умолчанию вписать в него самый большой город на обслуживаемой территории – Москва.

Всегда проверяйте, что валидация отсекает все ненужные символы. Даже если список разрешенных символов не оговорен, то лучше все равно добавить валидацию на специальные символы. Сложно предугадать поведение пользователей. Иногда думаешь: “Ну кто в поле Имя будет вводить угловые скобочки или одинарные кавычки?”. К сожалению рано или поздно это все равно случится. Например, к Вам попытается зарегистрироваться пользователь, пожелавший остаться неизвестным. Вместо своего реального имени он введет свой игровой ник – “Roc!<&Roll”. Данные, введенные в наше поле, могут проделать очень длинный путь от браузера пользователя на сервер, оттуда на сервер базы данных и обратно по этой цепочке в браузер другого пользователя или в другую часть приложения. Также данные могут быть использованы в другом проекте или сторонней библиотеке, используемой в вашем проекте. Предусмотреть качественную обработку специальных символов во всей этой длинной цепи крайне сложно. Какой-нибудь компонент обязательно выдаст ошибку. Выявить слабое звено на этапе тестирования не представляется возможным, так как не все компоненты готовы и собраны воедино.

Из всего выше сказанного следует один единственный вывод: всегда разрешайте вводить пользователям только те символы, которые действительно необходимы. Кстати, иногда валидация на специальные символы бывает слишком навязчивой: “Вы ввели запрещенный символ, используйте другой”. Поэтому иногда просто не разрешают вводить некорректные символы – пользователь нажимает на клавиатуре кнопку, но в поле ничего не появляется. При таком подходе не забудьте проверить, что ничего также не появляется при вставке данных из буфера обмена:

– нажимая сочетание клавиш Ctrl+V для Windows

– через контекстное меню (правая кнопка мыши в Windows)

– через alt code (зажав клавишу alt, нужно набрать число от одного до 5 символов)

Некоторые поля, такие как email или пароль, могут иметь валидацию, проверяющую, соответствует ли введённая строка некоторым правилам – формату. Например, пароль должен быть длиной не менее 6 символов, иметь хотя бы одну цифру и специальный символ. Такую валидацию лучше всего проводить на лету, то есть, как только пользователь установил курсор в это поле, сразу нужно подсказать, каким требованиям должен удовлетворять пароль. Также, по мере заполнения этого поля, нужно сообщить, каким требованиям ввод пользователя уже удовлетворяет. Ниже приведен пример такой валидации. Конечно, я не берусь утверждать, что такой подход единственно верный, но как показала моя практика, валидация на лету (on fly) очень удобна пользователям.

Для ввода даты или телефона лучше всего использовать дополнительные инструменты – виджеты, которые облегчают ввод данных и исключают ошибки в соблюдении формата. Пример такого виджета – Date Picker:

Такие поля, как User Name или Email, принимают только уникальные значения и не допускают повторений. Ведь нельзя, чтобы на сайте было зарегистрировано 2 пользователя с одинаковым именем – как их различать?

Также иногда нужно проверить, является ли пользователь человеком. Для этого с сервера пользователь получает картинку с трудночитаемым текстом – Captcha. Роботу не под силу ее прочитать, а без нее он не сможет зарегистрироваться (это как раз нам и нужно). Человек введёт текст с картинки и успешно зарегистрируется. Здесь будет уместна валидация, проверяющая истинность введенных данных.

Проверить два описанных выше случая не сложно.

В первом (Email):

– вводите уникальный email и проверяете, что валидация прошла;

– вводите использованный email и получаете сообщение об ошибке.

Во втором (Captcha):

– вводите надпись с картинки и видите, что валидация прошла;

– вводите заведомо ложную надпись и получаете сообщение об ошибке.

Для проверки правильности ввода e-mail и captcha их необходимо отправить на сервер. Это нужно делать по следующим причинам:

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

Captcha: Captcha служит защитой от автоматической регистрации. Если выслать истинное значение, то робот, выполняющий регистрацию, сможет перехватить его и обойти защиту.

К сожалению, иногда всё ещё приходится видеть сайты, на которых проверка captcha и e-mail происходит только после отправки всей формы (отправляются данные со всех полей). Сервер проверит правильность данных и в случае ошибки не сохранит данные. Пользователю вернется сообщение, в каком поле он ошибся. При этом ему придется заполнять все поля еще раз, так как форма будет перезагружена. Ошибиться в вводе Captcha несложно, поэтому ситуации, когда нужно заново вводить все данные, будут случаться часто. Запомните, что в XXI веке заставлять пользователя заново вводить все данные из-за того, что он ошибся в одном месте, просто преступно. Поэтому проверки на уникальность и истинность данных всегда должны проходить на лету без необходимости перезагружать форму. Если всё же из-за каких-то ограничений на вашем сайте нет возможности избежать перезагрузки формы, то попросите программистов сохранять все введенные пользователем данные при перезагрузке страницы. Исключением могут быть только пароли (это необходимо для обеспечения безопасности).