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

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

В статье будут рассмотрены чек листы, связанные только с веб-тестированием (чек листы для тестирования АПИ или чек листы для тестирования мобильных приложений здесь рассматриваться не будут).

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

➀ Составление чек листа

Давайте поговорим о том, как правильно составить чек лист для тестирования сайта. Сначала нужно определиться с объектом тестирования. Например, у нас объектом тестирования может быть сам сайт. Разделяем сайт на несколько областей. К примеру, разделить можно следующим образом: меню, основная часть сайта и подвал сайта. И начинаем писать чек лист. После того, как мы написали чек лист, можно его оформить в виде списка, таблицы, определить структуру, нумерацию, как он будет выглядеть. Таким образом мы можем составить чек лист тестирования сайта.
Ниже мы рассмотрим на шаблоны (образцы), как могут выглядеть чек листы тестирования сайта на разные случаи жизни, иногда даже пробуют проводить тестирование на основе чек листов.

➁ Готовые чек листы тестирования

➁.➀ Чек лист функционального тестирования

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

➁.➁ Чек лист тестирования верстки

☑ Кодировка UTF-8.
☑ Шрифты прогружаются и работают.
☑ Нет ошибок HTML и CSS.
☑ Проверить элементы на разных разрешениях экранов.
☑ Проверить кнопки на разных страницах.
☑ Формы при сворачивании окна.
☑ Проверить верстку в разных браузерах.
☑ Проверить, что нет больших комментариев в коде.
☑ Есть favicon на сайте.

➁.➂ Чек лист смоук тестирования

☑ Сайт открывается и доступен.
☑ Основные элементы сайта работают корректно.
☑ Нет ошибок в консоли.
☑ Нет битых ссылок.
☑ Основные страницы сайта открываются и работают.
☑ Нет видимых ошибок на главной странице.

➁.➃ Чек лист формы регистрации (логина, пароля)

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

➁.➄ Чек лист интернет магазина

☑ Наличие кнопок Купить, Заказать.
☑ Можно положить товар в корзину.
☑ После заказа приходит письмо на почту.
☑ Есть фильтры для поиска товаров.
☑ Есть форма обратной связи.
☑ Есть раздел с контактами.
☑ Есть ссылки на социальные сети.
☑ Строка поиска находится на видном месте.
☑ Присутствуют хлебные крошки.
☑ Отсутствуют опечатки.
☑ Проверка возможностей личного кабинета.
☑ Легко найти нужный товар.
☑ Нет дублирующихся товаров.

➁.⑥ Тестирование мобильной версии

☑ Сайт открывается в мобильной версии сайта.
☑ Пройтись по пунктам «Чек лист функционального тестирования».
☑ Пройтись по пунктам «Чек лист тестирования верстки».
☑ Пройтись по пунктам «Чек лист смоук тестирования».
☑ Пройтись по пунктам «Чек лист формы регистрации».
☑ Если интернет-магазин: пройтись по пунктам «Чек лист интернет-магазина».
☑ Проверить мобильную версию с поворотом экрана (горизонтальный и вертикальный вид экрана).
☑ Проверить в разных браузерах телефона.
☑ Проверить на разных телефонах.

➁.⑦ SEO чек лист

☑ Проверить, что нет запрета индексации в файле robots.txt.
☑ На всех страницах есть ровно один тег H1.
☑ Сайт на протоколе HTTPS.
☑ На сайте есть favicon.
☑ На сайте есть sitemap.
☑ Нет дублирующихся страниц.
☑ Есть хлебные крошки.
☑ Настроены ЧПУ.

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

См. также чек-лист тестирования мобильного приложения.

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

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

• проверить, соответствует ли ПО заявленным требованиям;

• найти потенциальные ошибки в функциональности и/или коде;

• обнаружить варианты использования программы, которые раньше не предполагались;

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

Каждый вид тестирования сопровождают три вида документов:

• план тестирования — документ, описывающий весь объем проводимых работ: описание программы, стратегию тестирования, расписание тестирования, количество тестировщиков и др.

• чек-лист — документ, описывающий, что необходимо протестировать в конкретной программе;

• тестовый сценарий — документ, описывающий ступени тестирования с определением их параметров и условий.

Сегодня мы расскажем о таком виде документа, как чек-лист.

Чек-лист и тестирование 

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

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

Выполняемая задача	Статус
Регистрация по e-mail	Passed
Регистрация через Facebook	Passed

Статусы могут быть разными. Например:

• passed — пройдено;

• failed — неудачно;

• blocked — заблокировано;

• skipped — пропущено;

• not run — не работает.

Чем чек-лист улучшает тестирование:

• видно статус каждого пункта, что улучшает видимость всей системы тестирования;

• дает возможность понять объем проделанной и предстоящей работы;

• помогает не запутаться в тестировании: не проводить тестирование одного и того же компонента и наоборот — не забыть протестировать что-то;

• и др.

Разновидности чек-листов в тестировании

Чек-лист в тестировании может быть 2-х основных видов:

1. Специальный чек-лист. Такой чек-лист создается специально под конкретный проект, поэтому учитывает всю специфику проекта. Данный чек-лист не может быть использован в другом проекте. В подобном чек-листе могут быть такие пункты: при наведении кнопка должна поменять цвет на синий, на странице «Товары» должно всплыть определенное уведомление и др.

2. Универсальный чек-лист. Такой чек-лист можно использовать на проектах разного рода. В нем указаны пункты проверки, которые не привязаны к графическим или функциональным элементам проекта. В таком чек-листе могут быть следующие пункты: страница «Магазин» должна открыться, оплата должна пройти, при нажатии на кнопку открывается форма, при нажатии на пункт «Меню» осуществляется переход на соответствующую страницу и др.

Чек-лист и тестирование: как составить

Обычно чек-лист тестировщик составляет самостоятельно. Для этого пригодятся следующие рекомендации:

• один пункт в чек-листе — это один вид проверки или проверка одного элемента;

• в составе чек-листа должны отражаться требования к программе, и ничего лишнего;

• сложные тестовые задачи нужно разбивать на небольшие пункты в чек-листе;

• чек-лист может быть вложенным в другой чек-лист, если задача очень сложная;

• должен легко читаться и быть понятным.

Пример чек-листа в тестировании

Как выглядят пункты чек-листа функционального тестирования веб-сайта:

• проверить открытие и доступность сайта;

• проверить открытие и доступность сайта повторно после его закрытия;

• проконтролировать, чтобы работали все пункты в меню;

• проконтролировать, чтобы нажимались кнопки на сайте;

• проверить, чтобы открывались все ссылки;

• посмотреть, чтобы не было битых ссылок;

• заполнить и проверить все формы на сайте;

• проверить работоспособность основных элементов сайта;

• загрузить документы и проверить корректность загрузки;

• и др.

Примерные пункты чек-листа при тестировании верстки:

• проверить кодировку сайта, чтобы была UTF-8;

• проконтролировать загрузку и работоспособность шрифтов;

• проверить наличие ошибок HTML и CSS;

• посмотреть корректность работы сайта на разных размерах экрана;

• проверить верстку в разных браузерах;

• проверить наличие тегов H1 на страницах;

• проверить наличие фавикона;

• и др.

Примерные пункты чек-листа формы регистрации:

• проверить, можно ли заполнить все поля формы;

• отправляется ли форма после нажатия кнопки «Отправить»;

• приходит ли ответное письмо на электронный адрес, указанный при регистрации;

• проверить, как поля передаются в запросе;

• и др.

Примерные пункты чек-листа при проверке интернет-магазина:

• есть ли кнопки «Заказать», «Купить», «Добавить в корзину» в карточке товара;

• проверить возможность положить товар в корзину;

• приходит ли оповещение о заказе на электронную почту;

• проверить работу фильтров для товаров;

• проверить работоспособность формы обратной связи;

• проверить наличие страницы «Контакты» и контактов на ней;

• проконтролировать работоспособность ссылок на соцсети интернет-магазина;

• проверить наличие «хлебных крошек»;

• и др.

Заключение

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

Нужен ли чек-лист при тестировании? Безусловно, нужен, потому что на его составление не уходит много времени, а качество теста он выводит на новый уровень.

Оригинал статьи: http://www.guru99.com/complete-web-application-testing-checklist.html

Автор: Guru99.com

Перевод: Ольга Алифанова

Во время тестирования веб-приложения нужно обращать внимание на нижеперечисленные пункты. Этот чеклист применим практически к любому типу веб-приложений в зависимости от бизнес-требований.

Чек-лист для тестирования веб-приложений состоит из:

• Тестирования удобства использования.
• Функционального тестирования.
• Тестирования совместимости.
• Тестирования баз данных.
• Тестирования безопасности.
• Тестирования производительности.

Теперь давайте рассмотрим каждый пункт по отдельности.

Тестирование удобства использования

Что это такое?

• Это не что иное, как тестирование дружелюбности приложения для пользователя.
• При тестировании удобства использования проверяется, легко ли новому пользователю разобраться в приложении.
• В целом при тестировании удобства использования тестируется системная навигация.

Какова цель этого тестирования?

Тест удобства использования удостоверяется в простоте и эффективности использования продукта при использовании стандартных практик тестирования удобства использования.

Сценарии тестирования удобства использования:

• Содержание веб-страницы верное, без грамматических и орфографических ошибок.
• Все шрифты соответствуют требованиям.
• Все тексты правильно выровнены.
• Все сообщения об ошибках верные, без орфографических и грамматических ошибок, и соответствуют заголовку окна.
• Подсказки существуют для всех полей.
• Все поля правильно выровнены.
• Между полями, колонками, рядами и сообщениями об ошибках оставлено достаточно свободного места.
• Все кнопки должны иметь стандартный формат и размер.
• Ссылка на домашнюю страницу должна быть на каждой странице сайта.
• Неактивные поля должны быть серыми.
• Проверьте, что на сайте нет битых ссылок и изображений.
• Подтверждающие сообщения должны отображаться для всех операций обновления и удаления.
• Проверьте сайт при разных разрешениях экрана ((640 x 480, 600×800 и т. д.)
• Проверьте, что пользователь может пользоваться системой без раздражения.
• Проверьте, что TAB правильно работает.
• Панель скролла должна появляться только тогда, когда она требуется.
• Если при отправке формы есть сообщения об ошибке, в нем должна содержаться информация, переданная пользователем.
• Заголовок должен отображаться на каждой странице.
• Все поля (текстовые, выпадающие меню, радио-кнопки и т. д.) и кнопки должны быть доступны с клавиатуры, и пользователь должен быть в состоянии пользоваться сайтом, используя только клавиатуру.
• Убедитесь, что данные в выпадающих списках не обрезаются из-за размеров поля, и проверьте, зашиты ли данные в код или управляются администратором.

Функциональное тестирование

Что это?

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

Какова цель функционального тестирования?

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

Сценарии функционального тестирования:

• Протестируйте валидацию всех обязательных полей
• Убедитесь, что знак звездочки отображается у всех обязательных полей
• Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
• Убедитесь, что високосные коды корректно валидируются и не вызывают ошибок в расчетах.
• Протестируйте числовые поля: они не должны принимать буквы, в этом случае должно отображаться соответствующее сообщение об ошибке.
• Протестируйте отрицательные значения в числовых полях, если они разрешены.
• Протестируйте, что деление на ноль верно обсчитывается.
• Протестируйте максимальную длину каждого поля, чтобы убедиться, что данные не обрезаются.
• Протестируйте всплывающее сообщение («Это поле ограничено 500 знаками»), которое должно отобразиться, если введенные данные превышают разрешенный размер поля.
• Убедитесь, что подтверждающее сообщение отображается для операций обновления и удаления.
• Убедитесь, что значения стоимости отображаются в нужной валюте.
• Протестируйте все поля ввода на спецсимволы.
• Протестируйте функциональность тайм-аута.
• Протестируйте функциональность сортировки.
• Протестируйте функциональность доступных кнопок.
• Протестируйте условия использования и часто задаваемые вопросы: они должны быть внятными и доступными пользователю.
• Протестируйте, что при отказе функциональности пользователь перенаправляется на специальную страницу ошибки.
• Протестируйте, что все загруженные документы правильно открываются.
• Протестируйте, что пользователь может скачать загруженные файлы.
• Протестируйте почтовую функциональность системы.
• Протестируйте, что Java Script верно работает в разных браузерах (IE, Firefox, Chrome, Safari, Opera).
• Посмотрите, что будет, если пользователь удалит куки, находясь на сайте.
• Посмотрите, что будет, если пользователь удалит куки после посещения сайта.
• Протестируйте все данные в выпадающих списках: они должны быть расположены в хронологическом порядке.

Тестирование совместимости

Что это?

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

Какова цель тестирования совместимости?

• Цель тестирования совместимости – оценка того, насколько хорошо ПО работает в определенном браузере, под определенной ОС, с другим ПО или железом.

Сценарии тестирования совместимости:

• Протестируйте сайт в различных браузерах (IE, Firefox, Chrome, Safari, Opera) и убедитесь, что сайт правильно отображается.
• Убедитесь, что используемая версия HTML совместима с соответствующими версиями браузеров.
• Убедитесь, что картинки корректно отображаются в разных браузерах.
• Убедитесь, что шрифты верно отображаются в разных браузерах.
• Убедитесь, что Java Script код работает в разных браузерах.
• Проверьте анимированные GIF в разных браузерах.

Инструмент для тестирования совместимости

Spoon.net: Spoon.net предоставляет доступ к тысячам приложений (браузеров), не требующих установки. Этот инструмент помогает вам тестировать приложение в разных браузерах на одной и той же машине.

Тестирование баз данных

Что это?

• При тестировании баз данных проверяются бэкэнд-записи, введенные через веб или десктоп-приложение. Данные, которые отображаются в приложении, должны совпадать с данными, хранящимися в базе данных.

Чтобы тестировать базы данных, тестировщик должен знать следующее:

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

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

Сценарии тестирования баз данных:

• Проверьте название базы данных: оно должно совпадать со спецификацией.
• Проверьте таблицы, колонки, типы колонок и значения по умолчанию: все это должно совпадать со спецификацией.
• Проверьте, позволяет ли колонка значение null.
• Проверьте первичный и внешний ключ каждой таблицы.
• Проверьте процедуры хранения.
• Протестируйте, установлена ли процедура хранения.
• Проверьте название процедуры хранения.
• Проверьте названия параметров, их типы и количество.
• Проверьте, обязательны параметры или нет.
• Проверьте процедуру хранения, удалив некоторые параметры.
• Проверьте базу данных, если на выходе ноль – записи с нулем должны быть задействованы.
• Проверьте процедуру хранения, задав простые SQL-запросы.
• Убедитесь, что процедура возвращает значения.
• Проверьте процедуру вводом тестовых данных.
• Проверьте поведение каждого флага в таблице.
• Убедитесь, что данные правильно сохраняются в базе данных после каждого ввода.
• Проверьте данные при каждой операции обновления, удаления и вставки.
• Проверьте длину каждого поля. Длина на бэкэнде и фронтэнде должны совпадать.
• Проверьте названия баз данных QA, UAT и прода. Имена должны быть уникальными.
• Проверьте зашифрованные данные в базе.
• Проверьте размер базы и время отклика на каждый запрос.
• Проверьте данные, отображающиеся на фронтэнде, и убедитесь, что они совпадают с бэкэндом.
• Проверьте целостность данных, вводя невалидные значения в базу.
• Проверьте триггеры.

Что такое тестирование безопасности?

Тестирование безопасности нацелено на поиск недостатков и пробелов с точки зрения безопасности приложения.

Сценарии тестирования безопасности:

1. Убедитесь, что страницы, содержащие важные данные (пароль, номер кредитной карты, ответы на секретные вопросы и т. п.) открываются через HTTPS (SSL).
2. Убедитесь, что важная информация (пароль, номер кредитной карты) отображается в зашифрованном виде.
3. Убедитесь, что правила создания паролей внедрены на всех страницах авторизации (регистрация, страница «забыли пароль», смена пароля).
4. Убедитесь, что если пароль изменен, пользователь не может зайти под старым.
5. Убедитесь, что сообщения об ошибках не содержат никакой секретной информации.
6. Убедитесь, что если пользователь вышел из системы или сессия завершена, он не может пользоваться сайтом.
7. Проверьте доступ к закрытым и открытым страницам сайта напрямую без авторизации.
8. Убедитесь, что опция «Просмотр исходного кода» отключена и не видна пользователю.
9. Убедитесь, что учетная запись пользователя блокируется, если он несколько раз ввел пароль неверно.
10. Убедитесь, что пароль не хранится в куки.
11. Убедитесь, что если какая-либо функциональность не работает, система не отображает информацию о приложении, сервере или базе данных. Вместо этого отображается соответствующее сообщение об ошибке.
12. Проверьте сайт на SQL-инъекции.
13. Проверьте права пользователей и их роли. К примеру, кандидат не должен быть способен получить доступ к странице администратора.
14. Убедитесь, что важные операции пишутся в логи, и информацию можно отследить.
15. Убедитесь, что значения сессий отображаются в адресной строке в зашифрованном виде.
16. Убедитесь, что куки хранятся в зашифрованном виде.
17. Проверьте приложение на устойчивость к брутфорс-атакам.

Что такое тестирование производительности?

Тестирование производительности проводится для оценки соответствия системы или компонента специфичным требованиям к производительности.

Общие тестовые сценарии:

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

Как проводится тестирование производительности? Вручную или автоматически?

В целом невозможно проводить тестирование производительности вручную по ряду причин:

• Понадобится большое количество ресурсов.
• Невозможно одновременно осуществлять ряд действий.
• Отсутствует подходящий способ отслеживания поведения системы.
• Сложность выполнения повторяющихся задач.

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

• Apache JMeter
• Load Runner
• Borland Silk Performer.
• Rational Performance Tester
• WAPT
• NEO LOAD

Скачать чек-лист в pdf

Обсудить в форуме

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

• Проверки допустимого количества символов в поле. Например, в поле можно ввести только 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 шт.
• Буквы, специальные символы.

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

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

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

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

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

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

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

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

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

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

Никогда не останавливайтесь:
В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях