Первым делом нужно проверить, что форма хоть как-то работает и готова к тестированию. Для этого выполним самый позитивный кейс (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]. Мы должны увидеть сообщение об ошибке, например: