Как протестировать поле ввода

Чек-лист по тестированию веб-форм

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

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

• Форму вообще невозможно заполнить, потому что данные в поля не вводятся
• При отправке уже заполненной формы появляется непонятное сообщение об ошибке
• При вводе пробела и нажатии на Enter приложение зависает, пользователь получает сообщение, что форма отправлена, но информация никуда не отправляется.

Бывают и такие ошибки, о которых пользователь не подозревает, потому что они возникают внутри приложения. Например, в заявке на кредит пользователь вместо номера телефона указал адрес регистрации, и банковские службы с ним не смогли связаться. Или вместо русских букв написал фамилию латинскими, и его заявка не была рассмотрена. Такие ошибки могут иметь серьезные негативные последствия как для пользователя, так и для бизнеса. Чтобы не допустить этого, веб-формы необходимо тестировать.

Задача тестировщика — найти возможные ошибки в работе приложения или сервиса. Хороший тестировщик не просто проверяет все подряд, а полагается на определенную логику и последовательность.

Инженер по тестированию — с нуля до трудоустройства за 4 месяца

• Постоянная поддержка от наставника и учебного центра
• Помощь с трудоустройством
• Готовое портфолио к концу обучения
• Практика с первого урока

Вы получите именно те инструменты и навыки, которые позволят вам найти работу

С чего начать тестирование веб-формы

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

Рассмотрим стандартную веб-форму. Там почти наверняка будут поля для ввода информации: имени, фамилии, адреса почты. Такие поля называются текстовыми. Пользователь может ввести буквы, цифры и символы. Какими конкретно данными может быть заполнено поле, решают на этапе разработки.

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

Позитивное тестирование

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

Как правило, текстовые поля подразумевают ввод следующих данных: фамилия, имя, адрес, логин, комментарий. В нашем поле будет фамилия.

Проверки для текстового поля разделим на две категории:

• Проверки допустимого количества символов в поле. Например, в поле можно ввести только 30 букв
• Проверки ввода допустимых символов, то есть букв, цифр, специальных символов.

Для тестирования количества символов в текстовом поле проводятся следующие тесты:

1. Среднее количество символов в поле: Иванов
2. Минимальное количество символов в поле: И
3. Максимальное количество символов в поле: Ивановпертровсидоргончаровпушкинлермонтов
4. Ноль символов: если поле необязательно для заполнения.

Для проверки ввода допустимых символов применяют следующие тесты:

• Буквы, цифры, специальные символы
• Текст с пробелом: в начале строки, в середине и в конце
• Можно вставить в поле скопированный текст
• Перенос строки внутри поля через Enter.

При тестировании важно учесть, что некоторые поля могут оставаться пустыми, а некоторые обязательны для заполнения. Например, логин при регистрации или номер телефона при заказе товара. Такие поля всегда отмечены астерисками (звездочками). Без указания в них информации невозможно отправить форму для обработки. Тестировщик должен убедиться, что при незаполнении обязательного поля появляется сообщение об ошибке. Можно сделать общую проверку сразу для всех полей: не заполнив веб-форму, нажать на кнопку «Продолжить» или «Отправить».

Негативное тестирование

После проведения позитивного тестирования нужно проверить негативные сценарии: когда пользователь указывает некорректные значения в поле и приложение сообщает ему об ошибке или вообще не позволяет ввести данные.

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

Время на тестирование всегда ограничено, да и протестировать все вероятные негативные сценарии просто невозможно. В этом случае можно ориентироваться на своего «целевого» пользователя, для которого создается веб-форма, а также на здравый смысл. Исходя из этого тестировщик выбирает наиболее вероятные негативные сценарии. Например, если в поле можно вводить только русские буквы, какова вероятность того, что пользователь в России введет английские буквы? Достаточно высокая, учитывая английскую раскладку на всех клавиатурах страны. А что насчет китайских иероглифов? Вероятность их попадания в поле в русскоязычном сегменте невысока, поэтому их проверкой можно пожертвовать в целях экономии времени.

Негативные сценарии, которые можно применить для тестирования полей в зависимости от требований и целевой аудитории:

• Количество символов меньше минимального
• Количество символов больше максимального
• Символы, ввод которых требованиями не предусмотрен
• Текст с пробелом: в начале строки, в середине и в конце
• Только пробел
• Символы не ASCII (например, эмоджи) — ♣☺♂

Далее для тестирования текстового поля можно применять уже более специализированные проверки, например, связанные с использованием SQL инъекций, XSS, html-тегов. Такие проверки предназначены для тестирования безопасности приложения. Каждое поле — это своего рода путь внутрь приложения: информация, переданная пользователем, записывается в базу данных. Поэтому нужно проверить, что в поле нельзя ввести ничего, что может навредить базе данных и другим частям приложения.

При тестировании текстовых полей могут встретиться следующие ошибки:

• Обязательные поля можно оставить пустыми
• Отсутствие сообщения об ошибке, если пользователь вводит некорректные данные
• Запрет ввода дефиса — пользователи с двойным именем или фамилией не могут заполнить данные о себе
• Ограничение по количеству символов — может не поместиться полностью имя, фамилия, адрес
• Минимальное количество символов в поле 3 символа — пользователи с фамилиями из двух букв не смогут подать заявку
• Отсутствие ограничения на количество символов — можно ввести очень большой текст и нарушить работу системы.

В веб-формах бывают не только текстовые поля. После ввода имени, фамилии, адреса или логина может потребоваться ввести числовые данные: возраст, количество чего-либо и тому подобное. Как тестировать такие поля?

Тестирование числового поля

Снова начинаем с позитивных сценариев: проверяем, что поле работает в соответствии с требованиями. Как и в случае с текстовыми полями, учитывается количество символов и содержание этого поля:

• Среднее количество символов в поле: 111111
• Минимальное количество символов в поле: 1
• Максимальное количество символов: 7490237407235192389273409720394729734
• Ноль символов: если поле необязательно для заполнения
• Цифры
• Положительные числа
• 0 как число.

Негативными сценариями могут быть:

• Буквы, специальные символы
• Только пробелы
• Пробелы внутри числа
• Отрицательные числа
• Дробные числа
• Степени двойки: 23
• Научная запись чисел: 1Е-10
• Вычисляемые выражения: 2+2

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

Последующие проверки зависят от назначения числового поля. Здесь нужно протестировать точные данные, которые важны для работы системы. Допустим, требованиями установлено, что можно добавить от 1 до 10 товаров для покупки. Тогда в поле «Количество товаров» для позитивных тестов будем вводить:

• Среднее значение: 5 шт.
• Минимальное значение: 1 шт.
• На один больше минимального: 2 шт.
• Максимальное значение: 10 шт.
• На один меньше максимального: 9 шт.

Для негативных тестов можно использовать следующие данные:

• Меньше минимального, в данном случае ноль: 0 шт.
• Больше максимального: 11 шт.
• Отрицательное значение: — 5 шт.
• Буквы, специальные символы.

Самые частые ошибки в числовых полях:

• Обязательные поля можно оставить пустыми
• Нет сообщения об ошибке, если пользователь вводит некорректные данные
• Можно вводить буквы и специальные символы в поле «Номер телефона» и другие подобные поля
• Нет ограничения на количество символов в полях: можно ввести несколько тысяч знаков и повредить работу приложения.

На скриншоте пример одного из дефектов: отсутствует сообщение об ошибке, когда поле «Номер телефона» заполнено буквами и символами.

Чек-боксы и радиокнопки

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

Еще один вариант выбора готового ответа — радиокнопки. Они используются для переключения между вариантами и позволяют выбрать только один вариант из нескольких.

Подведем итоги

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

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

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

Профессия «Инженер по тестированию»

• Смените профессию за 4 месяца — короткий путь в IT
• Познакомьтесь с этапами разработки и жизненным циклом ПО
• Узнайте всё о техниках тест-дизайна
• Разберитесь с системами управления тестированием и системами баг-трекинга
• Научитесь работать с API и базами данных

Тестирование полей ввода (Чит-листы)

Всем привет! Продолжаем делиться интересными кейсами из рабочей практики и новостями из мира тестирования. Сегодня будем говорить об ограничениях в тестируемых продуктах. Сегодня Нина Агеева, тренер курса «Погружение в тестирование. Jedi Point», расскажет про то, как жить с ограничениями в тестируемых формах: как их искать и с помощью какой техники быстро тестировать.

Дата публикации: 23.12.2019

Последние новости

• Стажировка мечты. Где брать опыт начинающему тестировщику
• Нашла работу мечты за месяц. История выпускницы курса для начинающих тестировщиков
• Как проходит рабочий день тестировщика
• QA-word of the day: maintainability
• Наши секреты: почему надо выбрать нас
• Лучшие курсы по тестированию ПО в ноябре 2023
• Тестировщик: кто это и как им стать

Home

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

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

• Нажмите Submit, ничего не заполняя.
• Нажмите пробел несколько раз, находясь в поле, а затем нажмите Submit.
• Посмотрите, сколько символов можно ввести в текстовое поле, а затем нажмите Submit (отличный инструмент для подсчета символов — https://lettercount.com).
• Заполните поле максимальным количеством цифр, а затем нажмите Submit.
• Введите минус, заполните поле максимальным количеством цифр, и нажмите Submit.
• Введите все спецсимволы клавиатуры и нажмите Submit. Если вы получите ошибку, попытайтесь разобраться, какой символ или символы ее вызывают.
• Введите символы, не относящиеся к ASCII, и эмоджи, и нажмите Submit. Если вы получите ошибку, попытайтесь разобраться, какой символ или символы ее вызывают.
• Попробуйте межсайтовый скриптинг – введите такой скрипт: . Если при нажатии на Submit появится всплывающее окно – значит, поле уязвимо для XSS-атаки.
• Попробуйте ввести SQL-инъекцию, например, FOO’); DROP TABLE USERS; (не делайте этого на базе данных прода!).

Затем давайте предположим, что мы что-то знаем о том, что должно вводиться в это поле, и каковы ограничения для данных:

• Попробуйте ввести значение с типом данных, отличным от ожидаемого – к примеру, если поле ожидает ввода стоимости, попробуйте ввести текст или дату.
• Если поле ожидает строку, попробуйте ввести строку на 1 символ короче, чем нужно, на 1 символ длиннее, чем нужно, минимально возможное количество символов, максимальное их количество, и количество, вдвое превышающее максимум.
• Если поле ожидает числа, попробуйте ввести максимум, минимум, значение выше максимума и ниже минимума, и значение, вдвое превышающее максимум.
• Если поле ожидает целого числа, попробуйте ввести десятичную дробью.
• Если поле ожидает числа с плавающей точкой, попробуйте ввести значение с двумя запятыми и значение, начинающееся с запятой.
• Если поле ожидает стоимости, попробуйте ввести значение с более чем двумя знаками после запятой.
• Если поле ожидает даты, попробуйте ввести максимальную дату, минимальную дату, на день больше максимума и на день меньше минимума, и дату на сто лет больше или меньше границ.
• Для полей дат попробуйте ввести бессмысленную дату – например, 6/31/17 or 13/13/17 (есть много способов тестировать поля дат, я затрону этот вопрос в другой статье).
• Если поле ожидает времени, попробуйте ввести бессмысленное время – например, 25:15.
• Если поле ожидает номера телефона, попробуйте ввести номер, не соответствующий ожидаемому формату (множество способов тестирования номеров я тоже затрону в другой статье).

Для всех вышеописанных тестов выясните, какое сообщение об ошибке вы должны получать, и убедитесь, что получаете правильное сообщение.

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

• Ввод нулевого значения.
• Ввод пустоты.
• Ввод значения, удовлетворяющего критериям («счастливый сценарий»).
• Ввод максимальной длины или максимального значения.
• Ввод минимальной длины или минимального значения.
• Ввод значения, превышающего максимальную длину или допустимый максимум.
• Ввод значения меньше минимума.

Это не исчерпывающий список, а просто способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле. Не верьте на слово, что разработчик, создававший поле, добавил нужную валидацию, проверьте ее сами! Как-то раз я тестировала поле ввода даты, у которого было ограничение на год – он не мог быть меньше 1900 или больше, чем текущий год. Я получала нужное сообщение об ошибке, вводя 1880, но даты 1300 года легко принимались!

Жизнь — это движение! А тестирование — это жизнь 🙂

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

Ссылка на ХАБР (там кликабельное оглавление)

Что надо узнать

1. По каким полям поиск должен работать / по каким нет
2. Ищет по включению или полному соответствию?
3. Регистрозависимый ли поиск?
4. Какая максимальная длина поисковой строки?
5. А если длина превышена, запрос обрезается?
6. Как работает поиск при пустом запросе?

Что надо проверить

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

1. Поиск ищет по всем полям, указанным в ТЗ
2. Поиск НЕ ищет по тем полям, которые НЕ указаны в ТЗ
3. Релевантность выдачи — то, что я ищу, в начале списка, или в конце?
4. Учитывается ли контекст поиска — ищу я по всему сайту или только разделу игрушек
5. Регистронезависимость поиска — найдет ли «Платье», если я ввела «платье»?
6. Ищет ли по включению или полному соответствию — «ту» найдет мне «туфли»?
7. Найдет ли 2 слова из одного поля? В любом порядке введенные?
8. Найдет ли 2 слова из разных полей?
9. Ошибка в вводе (исправляются ли опечатки, ищет ли похожее)
10. Исправляет ли система неправильную раскладку?
11. Ищет ли на разных языках? А если сразу на двух попробовать?
12. Поиск со спецсимволами работает?
13. А с эмоджи? Не упадет система при вводе какашки?
14. Тримаются ли открывающие и закрывающие пробелы
15. Пустое поле / только пробелы в поле
16. Нижнюю границу (от скольких символов ищет)
17. Верхнюю произвольную границу — указанную в ТЗ
18. Верхнюю границу на выходе
19. Поиск технологической границы — ввести «войну и мир», 100 млн символов

Давайте пройдемся по каждому пункту и выясним, как и зачем его проверять.

1. Поиск ищет по всем полям, указанным в ТЗ

Вроде бы капитан очевидность, но с чего только новички не начинают свой чек-лист:

• Оставить поле пустым
• Вбить кириллицу / латиницу
• Большую строку
• Всяко потыкать поиск по названию (а если часть названия указать, а если с опечаткой, а если. )

Если надо выбирать, то последний вариант выглядит наиболее логичным. Он по крайней мере не абстрактная серебряная пуля про любое текстовое поле. Он про поиск.

Но ведь чтобы всяко-разно издеваться над названием, надо сначала убедиться, что по названию вообще ищет, верно? Так что пишем в названии слово «Тест» (или любое другое, но одно, без спецсимволов и прочего), его же вводим в строку поиска. Так мы понимаем, что поиск по названию в принципе работает. Значит, можно будет дальше над ним изгаляться =)

Но сначала надо проверить основное — то, что поиск вообще работает. Что он ищет по всем тем полям, по которым должен.

Иначе сами представьте, идет у нас чек-лист на 30 проверок по названию, а потом уже «что поиск работает по описанию, категории товара, бренду. ». А времени на тестирование нет, и выделяется буквально 5-10 минут.

В итоге тестировщик провел первые 20 тестов и гордо говорит:

— Всё отлично! Поиск работает! А если всякую чухню в него вбить, не падает!

При этом поиск работает по 1 полю из 10 обязательных. И пользователи пытаются искать, а у них ничего не получается, потому что ищут не по названию. Нехорошо…

В любом чек-листе надо думать о приоритетах. Сначала — самое важное. Как в чек-листе в целом, так и внутри каждого блока проверок, постепенно идем от важного к неважному. От позитива к негативу.

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

А что самое важное в поиске? Для этого думаем, зачем его вообще делают. Чтобы искать. По чему? По каким-то полям / признакам. По каким? Узнаем и проверяем, ищет он по ним или нет.

2. Поиск НЕ ищет по тем полям, которые НЕ указаны в ТЗ

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

А теперь представьте себе ситуации:

1. Я ищу в интернет-магазине «белая майка», а система вываливает всё, что угодно:

• Черная майка
• Зеленый топ
• Красные штаны
• …

И если разобраться, то найдем слова «белая» и «майка» где-то внутри этих товаров. Например, в комментариях.

2. Я операционист банка. Пришла клиентка «Ольга Гагарина», я ищу её в системе, а в ответ получаю:

• Ольга Морозова (у которой адрес прописки на ул Гагарина)
• Иван Иванов (жена Ольга, в адресе тоже есть Гагарина)
• Петр Забубенов (в комментарии к адресу «арендодатель Ольга», в любимых певицах Гагарина)
• …

Ведь не зря же делают поиск по конкретным полям, а не «ищи по всему, что видишь». Как раз для того, чтобы результат был более релевантным. И если не тестировать, что поиск НЕ ищет там, где не должен, то в поисковую выборку может попасть вообще не то, что хотелось.

Поэтому проверять «поиск по полю НЕ ищет» тоже надо. А как? Вот тестируют у меня студенты Folks. Читаем ТЗ:

Фолкс найдет человека по следующим признакам: ФИО, предпочтительному имени, дате рождения(дд.мм.гггг), компании, модели девайса, его OS, автору изменений

Первая попытка — проверяют только перечисленные поля в чек-листе. Убеждаются, что поиск по ним работает. Обсуждаем, зачем тестировать «негатив», выясняем. Следующая попытка — проводится один дополнительный тест, что по одному из оставшихся полей карточки поиск НЕ работает. И всё.

Обсуждаем на кошках: допустим, в системе есть 100 полей. Поиск работает только по 10 из них. Что проверяем?

— Что по каждому из этих полей ищет. И одно любое другое, что по нему НЕ ищет.

Моя коллега Ольга Алифанова придумала такую аналогию для этой ситуации:

У нас огромный гипермаркет, в нем сто отделов

В десяти из этих отделов продавщицы Клава, Маня, Муся, Света, Ира, Ната, Дина, Раиса, Тамара и Галя никогда не должны обвешивать никого. В 90 оставшихся отделах продавщицы обвешивают всех.

Достаточно ли нам убедиться, что Муся дает точный вес, чтобы сказать, что Света и Раиса тоже не обманывают покупателей?

Если мы проверили одно поле, мы знаем ровно то, что именно по этому полю система НЕ ищет. Но мы ничего не знаем про оставшиеся 89 полей. И не узнаем, пока не проверим.

А проверять надо, потому что иначе мы рискуем получить нерелевантный поиск, который работает по абсолютно рандомным полям системы.

Но тогда возникает другой вопрос. Сколько это тестов?

• Поиск ищет по всем полям, указанным в ТЗ
• Поиск НЕ ищет по тем полям, которые НЕ указаны в ТЗ

Нужно ли нам писать отдельный тест на каждое поле? Или их можно объединить? Не получится ли кейс «я надену всё лучшее сразу» и при падении теста будет совершенно непонятно, на чем именно сломалось?

Смотрите, допустим, что у нас по полю с именем искать система должна, а по фамилии — не должна. Я пишу тест:

В строку поиска вбить: Тест

В системе подготовить карточки с данными:

1. Имя = Тест

2. Фамилия = Тест

ОР: 1

Давайте предположим, что в системе баг и по фамилии она тоже ищет. Какой будет ФР?

Вернулись обе карточки. Можно ли на основании этого сделать вывод, из-за чего именно поиск сломался? Из-за какого конкретно поля? Можно! Мы четко понимаем из такого ФР, что:

1. Поиск по имени работает правильно
2. А вот с фамилией косяк

И наоборот, если у нас будет такой результат:

Мы тоже вполне четко понимаем, что:

1. С именем косяк
2. Фамилия работает как надо

Получается, мы можем объединить тесты без потери простоты локализации при падении! Даже если полей будет 100, а не 2.

А дальше уже встает вопрос простоты проведения =) Вернемся к примеру про 100 полей, из которых поиск работает только по 10.

Вот смотрите, если мы делаем автоматизированный тест, то делаем «сразу хорошо». Один раз заполнили 100 карточек, в каждой 1 поле (каждый раз разное).

А вот если мы проводим тест вручную, то тут надо понимать, что заполнение каждой карточки — это затраты времени. Нажал «создать», заполнил поле, нажал «Сохранить» и система чуток подумала при сохранении. И так 100 раз? Грустновато получается.

Вообще в этом случае идеальный вариант — полуавтоматизация. Например, REST-метод создания карточки. Тогда создали в постмане коллекцию для создания 100 карточек один раз — а потом один щелчок кнопки, и все карточки готовы!

Или может, разработчик поможет написать утилитку для заполнения базы. Вот как пример у меня было на одном из проектов: заполняешь табличку экселя значениями, одна команда — и они уже в базе! И снова всё просто. Один раз табличку подготовили, потом используем.

А вот если у нас только графический интерфейс, тогда уже начинаем думать, что можно совместить без потери «качества».

Можно ли ввести искомое слово во все 10 полей одной карточки? Нет, потому что когда система её найдет, мы не будем знать, по какому из 10 полей она сработала. И информацию от такого теста мы получим лишь “по какому-то полю из 10 обязательных поиск работает”. Не совсем то, что надо. Значит, позитив объединить нельзя, создаем 10 карточек.

А как насчет негатива? Поиск НЕ должен сработать по 90 полям. Значит, мы можем заполнить все 90 полей одним значением в одной карточке. И поискать по нему. В идеале система ничего не найдет.

Конечно, если в системе есть баг и карточка нашлась, ошибку придется локализовывать. И тогда уже или заполнять 90 разных карточек, или использовать метод бисеционного деления.

А как правильно заполнить наши поля? Каким-то одним значением. Оно должно быть простое, без излишеств, без принципа «надену всё лучшее сразу». То есть не надо сразу класть туда спецсимволы, эмоджи, разные алфавиты и регистры, комбинацию слов через пробел… Написали везде «тест» или «котик», и всё.

Потому что сейчас мы проверяем самое важное — что поиск вообще работает. А вот как он работает и обрабатывает всяко-разный ввод — проверим чуть позже. А иначе если поиск не сработает на «%#$**», как понять, он вообще не работает по полю, или не ищет спецсимволы?

3. Релевантность выдачи

Здесь важно проверить приоритет поисковой выдачи. Понятно, что туда может попасть что-то «не то». Чем больше у нас данных и чем больше полей, по которым поиск возможен, тем больше вариантов на каждый запрос.

Вот, допустим, пытаюсь я найти однотонное платье в интернет-магазине. Что я могу задать в поиске? «Желтое платье». Что я получаю в выборке?

Целиком желтое платье на ШЕСТОМ месте. После 5 черных с вкраплениями желтого цвета.

С одной стороны, это логично. Ведь на других платьях желтый цвет тоже есть, поэтому его добавили в параметр «цвета». Ищем по параметрам:

• Платье — да, тут платья
• Желтый цвет — да, в блоке «цвета» есть слово «желтый» у каждого.

И как раз в силу большого ассортимента товаров мы получаем то, что получаем. Можно ли как-то на эту выборку повлиять?

Можно. Причем можно даже разные варианты придумать:

1. Можно добавить в систему галочку «однотонная вещь». И проставлять её при заполнении товаров. А потом уже по запросу вещи конкретного цвета выводить сначала вещи с этой галочкой, а потом уже все остальные. При этом можно даже в фильтры вывести такую галку, чтобы пользователь мог выбрать “только однотонные”, и получить только вещи нужного ему цвета.
2. Можно фильтр настроить так:
   1. Сначала вещи, у которых только один цвет
   2. Потом все остальные (многоцветные)

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

   И тогда уже при выдаче результатов сначала отдаем вещи, у которых запрошенный пользователем — приоритетный.

   А вот другой пример. Исходный запрос — «красная майка женская»:

   

   Что вернула система:

   1. Черная майка
   2. Мужская майка
   3. Розовая с белым
   4. Белая майка
   5. .

   А то, что нам нужно, аж на 8-ом месте. Почему так? А снова приоритеты. Где-то мелькнуло слово «красный», вон на мужских майках то каемка красная, то майка. Где-то просто ошиблись цветом при заполнении данных (и такое бывает), где-то в комментариях или другом описании было написано ключевое слово (что-то типа «подойдет и мужчинам, и женщинам, унисекс!»).

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

   Тут хотелось бы добавить, что поиск может быть не только в интернет-магазине. Искать можно среди данных: ФИО, адресов, телефонов. Например, если у нас система с клиентскими данными типа Users. Или подсказки Дадаты, ведь они работают по своим справочникам, но приоритезируют информацию:

   

   Имена бывают самые разные, но если вместо Александра и Алексея система предложит Алладина, Алана и Алмаза, то толку от такой системы? Проще руками ввести.

   4. Контекст поиска

   Откуда я вызываю поиск? С главной страницы сайта или из конкретного раздела?

   Скажем, если на Озоне попробовать поискать «котенок» на главной странице, он поищет везде: в книжках, игрушках, чашках, воздушных шариках.

   

   А вот если я буду искать в разделе книг, то буду ожидать только книги про котят, не игрушки:

   

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

   А ещё контекст очень важен в мессенджерах. Искать вообще везде, во всех 100500 чатах, или только в одном? Будет очень плохо, если я запущу поиск по диалогу с мамой, а система выдаст мне кучу рабочих чатиков, где нашла совпадение…

   

   5. Регистронезависимость поиска

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

   А система ничего не находит, ведь у неё есть только «Платье» (первая заглавная, а у нас в запросе — нет)… Но пользователь же не в курсе, что надо немного изменить запрос, он будет думать, что платья тут просто не продаются…

   Так что проверяем:

   1. нижний регистр
   2. ВЕРХНИЙ РЕГИСТР
   3. ЗоЛоТую СеРеДиНу

   6. Ищет ли по включению или полному соответствию

   Поиск по включению — это когда можно ввести только часть слова. Например, «ко» вместо «котик». Это очень удобно во всяких чатах. Вот, например, я помню, что Ольга рассказывала историю про баг, связанный с кораблем. Но в каком падеже она говорила?

   Если поиск работает по полному совпадению, то нужно перебирать все падежи. Если он работает по включению, мне достаточно написать «корабл».

   Бывает, что сам поиск работает по полному совпадению, но при вводе подсказывает варианты:

   

   При этом если выбрал подсказку — показались товары. А если не выбрал, то сам себе злобная чебурашка.

   

   Впрочем, некоторые магазины всё равно предлагают товары. Или которые включают в себя введенный текст, или какие-то вариации (Озон мне на «ту» выдал товары с «Two» в названии!)

   В любом случае, нужно уточнить — как должно работать? А потом проверить:

   • Поиск по полному соответствию в одном слове
   • Поиск по частичному соответствию в одном слове — совпадение в начале слова / середине / конце (вспоминаем про классы эквивалентности и граничные значения)

   7. Два слова из одного поля

   А что будет, если у нас не одно слово, а два или более? Причем 2 слова у нас может быть:

   1. В искомом поле
   2. В поисковом запросе

   И это будут разные тесты! Например, название товара: «Игровой набор». Тесты при этом:

   1. Игровой → то есть в поле несколько слов, а мы ввели одно из них, найдётся?
   2. Игровой набор → в поиске тоже несколько слов

   Но что будет, если в поиске мы изменим порядок слов?

   

   • Набор игровой → найдется ли он в таком формате? Или нужно прям четкое совпадение?

   8. Два слова из разных полей

   Если мы проверяем несколько слов в поиске, то тут тоже возможны варианты:

   1. Они все из разных полей — например, мы ищем по цвету + названию + полу: «красная майка женская».
   2. Они из одного поля — как выше с игровым набором. И в этом случае намного интереснее изменить порядок слов и проверить поведение системы =)

   Важно понимать, что это разные тесты. И стоит проверить и тот вариант, и другой.

   9. Опечатки

   Как система работает с опечатками? Найдет ли похожее слово?

   Краный галстук → Красный галстук

   Если система работает с опечатками, то как:

   • 1 неправильную букву исправит / 2 и более
   • 1 пропущенную букву исправит / 2 и более

   Это, конечно, зависит от длины искомого слова, но тогда исправляются ли опечатки в коротких словах? Тут, главное, не увлечься, и не побежать ставить баг «система не исправила хлеб на пиво» =))

   

   10. Неправильная раскладка

   Типичный пример опечатки — пользователь забыл изменить раскладку на клавиатуре и напечатал английскими символами русский текст. Ищем «котик» но вводим «rjnbr».

   Озон понимает, что мы ошиблись и ненавязчиво исправляет ошибку, подсказывая варианты по котикам:

   

   Если нажать энтер, то увидим, что система исправила раскладку прямо в поисковой строке, но на всякий случай уточняет, правильно ли сделала:

   

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

   Всегда лучше ненавязчиво исправить ошибку пользователя, чем гневно тыкать ему под нос «По такому запросу ничего не найдено!!»

   11. Другой язык

   Что, если в системе есть данные и на русском, и на английском? Или даже смешанный вариант: «Сухой корм Purina ONE». Найдет ли система и по русскому алфавиту, и по английскому?

   А ещё интересный кейс, если в системе можно изменить язык! Что будет, если я изменю язык сайта на английский, а поищу по русскому названию, или наоборот?

   

   12. Спецсимволы

   Это стандартная серебряная пуля для всех текстовых полей:

   • Русский алфавит
   • Английский
   • Спецсимволы
   • Эмоджи
   • Перемешал

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

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

   1. Спецсимвол есть в искомом поле. Вот буквально на днях студентка завела такой интересный баг на одном из сайтов поиска книг — если в запросе есть восклицательный знак, поиск не срабатывает:

   

   При том, что сама книга на сайте есть:

   

   И система умеет работать со спецсимволами. Скажем, по вопросительному знаку она ищет:

   

   Поэтому проверить нужно все спецсимволы. Я обычно делаю это примерно так: создаю товар / искомый объект сразу с набором спецсимволов:

   И по нему ищу. А вот если не срабатывает, тогда уже разбираюсь, с каким именно символом проблема.

   2. Пользователь может забыть переключить раскладку и вот уже вместо «Хлеб» он вводит «

   3. Пользователь может случайно вкопипастить в поле какой-то текст со спецсимволами. Ошибки тоже надо предусмотреть, и уж точно не падать на этом =)

   13. Эмоджи

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

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

   14. Тримаются ли открывающие и закрывающие пробелы

   Метод trim() удаляет пробельные символы с начала и конца строки.

   То есть вводим « тест », а система преобразует строку в «тест» и потом уже передаёт дальше, в нашем случае — функции поиска.

   Надо признать, что проверка на трим более логична при заполнении и сохранении полей — ввела случайно « Ольга» в имя, а потом поиск не находит, требуя точного совпадения. И тогда логично системе перед сохранением сделать трим.

   

   В поиске обычно пробелы используются как разделители слов. Поэтому пробелом больше, пробелом меньше — системе неважно.

   Хотя лидирующий пробел всегда интересно проверить — а что, если система посчитает « майка» за пустую строку, так как обнаружила в первом поле пробел и посчитала строку мусорной?

   15. Пустое поле

   Фактически это проверка на ноль. А ноль — это отдельный класс эквивалентности, который часто приносит баги, поэтому его надо проверять!

   

   Если мы оставили поисковую строку пустой, то есть варианты:

   • Система выводит всю базу
   • Система выводит пустоту
   • Кнопка поиска просто не срабатывает / вообще заблокирована до ввода символов (что сомнительно, впрочем, да и зачем?)

   16. Пробелы в поле

   Ещё один вариант тестирования нуля — ввести в поле ТОЛЬКО пробелы. Как система их обработает?

   По идее также, как и пустую строку. Но может быть так, что при пустой строке выводится вообще всё, а вот если ты начал что-то вводить — начинается поиск. И хотя пробел наверняка встречается в искомых полях, найдет ли система хоть что-то?

   Впрочем, в данном тесте мы просто собираем информацию о том, как работает система. Потому что почти любое поведение (разве что кроме ошибки) можно считать нормальным.

   17. Нижняя граница

   Пустое поле (ноль) — мы уже проверили. А дальше думаем, какая у наших данных будет нижняя граница?

   Важно подобрать её осознанно, а не просто ввести одну букву и потом заводить баг, что вы ожидали что-то другое (и обязательно при этом добавить «если не исправите, пользователи обидятся и уйдут!»)

   Павел Абдюшев в своем докладе «Есть фича. Помогите протестировать!» привел замечательный пример с писателем и поэтом Эдгаром ПО. Это пример короткой реальной фамилии, по которой могут искать.

   А теперь пойдем на OZON, который раньше, на минуточку, только книги и продавал, и попробуем найти там книгу «Ворон».

   Сначала пробуем по фамилии:

   

   Хммм, нет, даже среди вариантов не предлагает, думаем, что мы ввели начало слова. Ладно, попробуем с названием книги:

   Теперь Озон нашел нужную книгу, вот только я могу её не заметить, так как над ней аж 7 рекламных пункта:

   

   Пожалуй, нажму «энтер», чтобы перейти на страницу результатов поиска. Нашлась!

   

   Так что Озон с задачей справился. Но это Озон, а как поведет себя другой магазин с книгами, мы не знаем, пока не проверим.

   Если книги автора найти не получается — то проблемы с приоритетами в выборке. Поиск по ФИО автора должен быть более релевантным, чем совпадение какого-то слова в описании.

   18. Верхняя произвольная граница

   Есть ли ограничение в строке поиска? Если есть, то оно обычно в разумных пределах — 100 / 500 / 1000 символов. И если пользователь вводит больше, то значение обрезается до максимального.

   И это разумно. Всегда лучше не дать ошибиться (не дать ввести больше N, обрезать запрос самостоятельно), чем ругаться на пользователя «да ты дурак, куда так много вводишь!».

   

   Начинающие тестировщики, прочитав в ТЗ про границу в 1000 символов, записывают в свои чек-листы ожидаемый результат «при вводе больше система выдает ошибку». Но зачем выводить ошибку там, где можно обойтись без неё? Если системы ещё нет и вы пишете чек-лист заранее, просто уточните, как она будет работать.

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

   19. Верхняя граница на выходе

   Прошлый пункт — о том, как подать много на вход. А что будет, если «много» не на входе, а на выходе? Или «где-то посередине», то есть там, где поиск идёт?

   • Вернулось много данных по поиску (распространенный запрос)
   • Много данных находится в самой системе / базе данных

   Сколько времени займет поиск? И пройдет ли он вообще? А то может на поиск установлен тайм-аут в 1 минуту. И при плохом интернете / большом объеме данных он будет просто висеть-тупить, а потом отваливаться.

   

   20. Поиск технологической границы

   Для поиска технологической границы мы вбиваем в строку поиска ОЧЕНЬ БОЛЬШОЕ значение. Тут хочется напомнить, что мы живем в 21 веке, поэтому 1000 символов — не поиск технологической границы. И даже 10 000, или 100 000.

   Введите 100 миллионов символов или главу «Войны и мира». Есть куча инструментов, которые помогут вам в этом.

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

   Мы столкнулись с этим на тестовом стенде подсказок Дадаты — ввели в подсказки по организациям большой текст и подвесили систему.

   

   Поиск там работал по условию OR → то есть механизм брал каждое слово и искал его в справочнике так:

   Слушай, у тебя есть слово 1 ИЛИ слово 2 ИЛИ слово 3 ИЛИ слово 4.

   Если слов много → то и комбинаций получается много → вот он и зависал, все их перебирая… При этом зависал сервер, то есть подсказок бы никто не увидел, если бы баг дошел до продакшена. А это уже нехорошо =)

   Поэтому мой вам совет при тестировании поиска — когда исследуете технологические границы, генерируйте ТЕКСТ, а не строку. То есть кучу слов с пробелами. А то вдруг ваша система тоже не выдержит много комбинаций?

   Это можно сделать и через perlclip. Просто задайте условие вида

   21. А дальше что?

   Это чек-лист конкретного функционала — поиска. Но стоит ли останавливаться на проверке того, что «товар найден / не найден»?

   Послушайте доклад Павла Абдюшева «Есть фича. Помогите протестировать!». Он там показывает, как выйти за рамки тестирования функционала. Как посмотреть на него с разных сторон. Что ещё стоит проверить и включить в план тестирования.

   Как подключить связанный функционал — например, на что обратить внимание в результатах поиска, есть ли там сразу кнопка “купить”.

   Итого

   Помните, что мы всегда начинаем тестировать с самого важного. Поиск нужен для чего? Чтобы искать по каким-то полям. Поэтому в первую очередь проверяем:

   • что поиск ищет по всем полям, указанным в ТЗ
   • что он НЕ ищет по тем полям, которые НЕ указаны в ТЗ

   А потом уже начинаем проверять регистр, включение, опечатки и прочая. И идём от простого к сложному, потому что если в одном тесте проверять сразу всё, то потом очень сложно будет понять, из-за чего конкретно поиск не сработал.

   

   Также не забывайте про стандартные тесты для любого текстового поля:

   • Разный регистр / язык / спецсимволы / эмоджи
   • Пустое поле / поле из пробелов
   • Нижняя граница — есть ли у вас адекватные, но короткие данные, ищет система по ним?
   • Верхняя произвольная граница — если она есть
   • Поиск технологической границы — вводим МНОГО слов, желательно с пробелами.

   Но помните, что это серебряная пуля для любой текстовой строки. А, значит, она явно менее приоритетна тестов именно на ваш функционал — в данном случае на поиск. А тестировать надо начинать с самого главного!

   8 комментариев:

   Вы когда-нибудь пользовались поисковой системой сайта «smotrim.ru»? Судя по обилию ваших статей с отсылкой к поисковой системе вы на ней «собаку съели». Так поясните, пожалуйста, что в функционале сайта «smotrim.ru» является фичей, а что багом.
   1. В верхней части страницы имеется кнопка для открытия формы поиска. А после получения первого результата в центре страницы появляется ещё одно поле поиска.
   Такое дублирование чем обосновано? Это новый тренд?
   2. По нажатию кнопки с лупой в верхней части главного окна появляется поле для ввода строки поиска.
   2.1. Если по окончании ввода нажать клавишу Enter, то результат поиска окажется нулевой.
   Как объяснить такое поведение? Необработанное стандартное действие пользователя или что-то новенькое в программировании?
   2.2. После 2-3 секундной задержки при вводе поисковой строки появляется ниспадающий список с совпадениями, клик по которым открывает искомый ролик. Ещё месяц-другой назад этот же список найденного, но в виде ячеек с картинками и подписями, отрисовывался по нажатию клавиши Enter. Это убеждает меня, что предшествующий пункт — явный баг.
   Но поскольку ниспадающий список отрабатывает в ожидаемом режиме, то гипотетически такое поведение — современный тренд поисковой системы. А как вы считаете?
   3. По-моему, в вашем чит-листе не хватает пункта про отображение результатов поиска:
   — умещается ли всё важное на первой странице;
   — в каком виде отображается результат (список, таблица, . );
   — имеются ли последующие линки или графические элементы для увеличения инфы о найденном объекте;
   — достаточно ли инфы про каждый найденный элемент;
   — можно ли запустить вложенный поиск среди результатов первого уровня (когда-то первый русскоязычный поисковик имел галку «найти в найденном»). Ответить Удалить

   Нет, не пользовалась
   1. Не в курсе трендов, но меня устраивают поисковые строки вайлдберриз, озон и иже с ними)
   2. Это могут делать для экономии места, но для пользователя лищнее действие
   2.1. Не знаю как пояснить, но судя по пункту 2.2 вы обязаны сделать выбор из выпадающего списка. И раз вы просто жмете «энтер», ничего не выбрав, то поле остается пустым. Так на всяких гос сайтах делают ввод адреса, только выбор из их вариантов и никак иначе
   2.2. Так себе тренд с точки зрения юзабилити)
   3. У меня есть про самое важное) Только зачем ограничиваться первой страницей?
   А про «в каком виде отображается» и прочее есть в последнем пункте, в Пашином докладе, но у меня речь про функционал поиска скорее Удалить

   К пункту о небуквенных символах. На сайте «smotrim.ru» поиск ролика с запятой или точкой не работает, если поисковая строка вставлена из буфера, а не набрана вручную. Своеобразный баг, да? Удалить

   Похожие публикации:

   1. Как изменить стиль на андроид
   2. Как переименовать файл в java
   3. Как сгруппировать radiobutton c
   4. Что такое эмуляция действий пользователя