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

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

Итак, позитивные кейсы прошли и перед нами работающая форма – введенные данные сохраняются в базу данных. Здесь нужно уточнить, что для действительно хорошего тестирования тестировщику нужно иметь доступ к тому месту, где хранятся данные, с которыми работает программа. Чаще всего в веб-приложениях таким местом является реляционная база данных. Чтобы извлечь из нее данные, нужно написать запрос на языке, который она поддерживает. Обычно это язык 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 их необходимо отправить на сервер. Это нужно делать по следующим причинам: