Тестирование веб-сервисов * Привет! После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения. 
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению. Чек-лист для тестирования WEB приложений состоит из шести разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
- Тестирование форм
- Регистрация
- Пользователь с данными существует в системе.
- Пользователь с данными не существует в системе.
- Пользователь, заблокированный в системе, не может пройти повторную регистрацию.
- Авторизация
- Пользователь существует в системе с введенным логином и паролем.
- Пользователь с введенным логином не существует в системе.
- Пользователь с введенным логином существует в системе, но пароль неверный.
- Пользователь с введенным логином и паролем существует в системе, но заблокирован модерацией (страница заморожена).
- Валидация полей ввода.
- Протестируйте валидацию всех обязательных полей
- Максимальная и минимальная длина.
- Диапазон допустимых символов, спецсимволы.
- Обязательность к заполнению.
- Убедитесь, что астериск (знак звездочки) отображается у всех обязательных полей.
- Убедитесь, что система не отображает окно ошибки при незаполненных необязательных полях.
- Формы обратной связи
- Регистрация
- Поиск
- Результаты существуют/не существуют.
- Корректное сообщение о пустом результате.
- Пустой поисковой запрос.
- Поиск по эмодзи.
- Поля
- Числовые поля: они не должны принимать буквы, в этом случае должно отображаться соответствующее сообщение об ошибке.
- Дробные значения, например, как система валидирует 1.1 и 1,1.
- Отрицательные значения в числовых полях, если они разрешены.
- Деление на ноль корректно обрабатывается.
- Протестируйте максимальную длину каждого поля, чтобы убедиться, что данные не обрезаются или скрываются под многоточие.
- Протестируйте все поля ввода на спецсимволы.
- Проверить что текст не выезжает за границы поля.
- Всплывающие сообщения
- Протестируйте всплывающие сообщения («Это поле ограничено N знаками»).
- Подтверждающие сообщения отображается для операций обновления и удаления.
- Сообщения об ошибках ввода.
- Фильтры
- Протестируйте функциональность сортировки (по возрастанию, по убыванию, по новизне).
- Задать фильтры с выдачей.
- Задать фильтры, по которым нет выдачи.
- Фильтры по категориям/подкатегориям.
- Фильтры с радиусом поиска.
- Данные в выпадающих списках.
- Протестируйте функциональность доступных кнопок.
- Наличие favicon.
- Проверка обработки различных ошибок (страница не найдена, тайм-аут, ошибка сервера и т.д.).
- Протестируйте, что все загруженные документы правильно открываются.
- Пользователь может скачать/прикрепить/загрузить файлы/медиа (картинки, видео и т.д.). А также удалить эти файлы из вложений. Убедитесь, что файлы уходят на сервер только после нажатия соответствующей кнопки
- Протестируйте почтовую функциональность системы.
- Кеш, cookie и сессии
- Пользователь очистил кэш браузера
- Посмотрите, что будет, если пользователь удалит куки, находясь на сайте.
- Посмотрите, что будет, если пользователь удалит куки после посещения сайта.
- DevTools
- Ошибки в Console.
- Все стили загружаются.
- Картинки загружаются.
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
- Проверяем работу сторонних модулей: оплата, шаринг, карты.
- Реклама (просмотр, переходы по рекламе, аналитика).
- Метрики (переходы по страницам, показы элементов, клики).
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Что проверяем?
- Пользователь не может авторизоваться: под старым паролем, заблочен в сервисе, достиг лимита авторизаций, ввел чужой код верификации.
- Страницы, содержащие важные данные (пароль, номер кредитной карты и CVC, ответы на секретные вопросы и т. п.) открываются через HTTPS (SSL).
- Пароль скрыт астерисками на страницах: регистрация, «забыли пароль», «смена пароля».
- Корректное отображение сообщений об ошибках.
- Завершение сесcии после разлогина.
- Доступ к закрытым разделам сайта.
- SQL-инъекции.
- Cross-Site Scripting (XSS) уязвимости.
- HTML-инъекции.
- Cookie должны храниться в зашифрованном виде.
- Роли пользователей и доступ к контенту.
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
- Дата и время. Например отображение времени, даты в соответствии с часовым поясом пользователя.
- Смена языка и проверка перевода всех элементов WEB приложения исходя из выбранного языка.
- Выбор номера телефона с разными кодами стран.
- Определение местоположения пользователя и отображение соответствующего пермишена ГЕО.
- Отображение соответствующих символов валюты.
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Что проверяем?
- Отсутствие орфографических и грамматических ошибок, все страницы имеют корректные заголовки.
- Выравнивание картинок, шрифтов, текстов.
- Информативные ошибки, подсказки.
- Подсказки существуют для всех полей.
- Отступы между полями, колонками, рядами и сообщениями об ошибках.
- Кнопки имеют стандартный размер, цвет.
- На сайте нет битых ссылок и изображений.
- Неактивные поля отображаются серым цветом.
- Проверьте сайт при разных разрешениях экрана.
- Скролл должен появляться только тогда, когда он требуется.
- Отображение чекбоксов и радио-кнопок, кнопки должны быть доступны с клавиатуры, и пользователь должен быть в состоянии пользоваться сайтом, используя только клавиатуру.
- Отображение выпадающих списков.
- Длинный текст скрывается под многоточие.
- Корректный выбор даты.
- Наличие плейсхолдеров в полях.
- Логотип ведет на главную страницу сайта.
- Переходы и навигация между страницами и разделами меню.
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
Что проверяем?
- Тестирование в различных браузерах (Firefox, Chrome, Safari — это минимальный набор): анимация, верстка, шрифты, уведомления и т.д.
- Тестирование в различных версиях ОС: Windows, Mac, Linux.
- Java Script код работает в разных браузерах.
- Просмотр на мобильных устройствах.
Резюме
Мы ознакомились с универсальной шпаргалкой по тестированию WEB приложений. Не забывайте читать документацию и дополнять чек-лист проверками, характерными для вашего сервиса. А если остались вопросы — скорее пишите в телеграм-канал @qa_chillout.
Что подразумевается под чек листами в тестировании? Чек-лист тестирования сайта — это список проверок, которые выполняет тестировщик при тестировании веб-сайта. В данной статье рассмотрим, как составить чек лист тестирования, а также приведем список готовых чек листов тестирования.
В статье будут рассмотрены чек листы, связанные только с веб-тестированием (чек листы для тестирования АПИ или чек листы для тестирования мобильных приложений здесь рассматриваться не будут).
Многие тестировщики (и не только) задаются вопросами: как выглядит чек лист тестирования? Как написать чек лист для тестирования веб-сайта? Как писать чек-лист тестирования сайта? Как правильно его составить? В этой статье мы постараемся ответить на все эти вопросы и дадим примеры (образцы, шаблоны) готовых чек-листов тестирования сайта с готовым оформлением и структурой.
➀ Составление чек листа
Давайте поговорим о том, как правильно составить чек лист для тестирования сайта. Сначала нужно определиться с объектом тестирования. Например, у нас объектом тестирования может быть сам сайт. Разделяем сайт на несколько областей. К примеру, разделить можно следующим образом: меню, основная часть сайта и подвал сайта. И начинаем писать чек лист. После того, как мы написали чек лист, можно его оформить в виде списка, таблицы, определить структуру, нумерацию, как он будет выглядеть. Таким образом мы можем составить чек лист тестирования сайта. Ниже мы рассмотрим на шаблоны (образцы), как могут выглядеть чек листы тестирования сайта на разные случаи жизни, иногда даже пробуют проводить тестирование на основе чек листов.
➁ Готовые чек листы тестирования
➁.➀ Чек лист функционального тестирования
➁.➁ Чек лист тестирования верстки
➁.➂ Чек лист смоук тестирования
➁.➃ Чек лист формы регистрации (логина, пароля)
➁.➄ Чек лист интернет магазина
➁.⑥ Тестирование мобильной версии
☑ Сайт открывается в мобильной версии сайта. ☑ Пройтись по пунктам «Чек лист функционального тестирования». ☑ Пройтись по пунктам «Чек лист тестирования верстки». ☑ Пройтись по пунктам «Чек лист смоук тестирования». ☑ Пройтись по пунктам «Чек лист формы регистрации». ☑ Если интернет-магазин: пройтись по пунктам «Чек лист интернет-магазина». ☑ Проверить мобильную версию с поворотом экрана (горизонтальный и вертикальный вид экрана). ☑ Проверить в разных браузерах телефона. ☑ Проверить на разных телефонах.
➁.⑦ SEO чек лист
Список чек листов представлен в ознакомительных целях. Готовые чек листы могут помочь при тестировании сайтов, а также служить источником вдохновения для новых идей.
См. также чек-лист тестирования мобильного приложения.
09.05.2021
Кто-то в процессе своей трудовой деятельности составляет чек-листы, а кто-то этим не занимается и пишет только тест-кейсы. Я считаю, что чек-лист и тест-кейсы неотделимы по своей сути. Сюда же можно добавить и интеллектуальную (функциональную) карту приложений. Поясню почему они неотделимы, а потом перейдём непосредственно к чек-листам.
О принципах правильного написания тест-кейсов и создания карт приложений я рассказывал в отдельных статьях, ссылки на которые приведу в конце данной статьи.
Какая взаимосвязь существует между тремя озвученными сущностями? Когда я обучаю специалистов по тестированию, то обучение мы начинаем с карт приложения. Картами мы охватываем весь возможный функционал программы. После того как карта полностью создана мы на основании конечных проверок, зафиксированных на карте, создаём чек-лист. Создав чек-лист, мы начинаем создание тест-кейсов.
Для чего мы так делаем? Для того чтобы не упустить какой-либо функциональный блок программы при создании тест-кейсов. По опыту знаю, что когда пишешь тест-кейсы и нет ни карты приложения, ни чек-листа, то после пятидесяти или сотни написанных тест-кейсов становится трудно удерживать в голове информацию, что описано тест-кейсами, а что ещё надо описать тест-кейсами, а впереди ещё надо написать несколько тысяч тест-кейсов. В этом случае чек-листы нам помогают и нам не надо в голове держать большие объёмы информации по тому, что мы описали тест-кейсами, а что ещё надо описать.
Поэтому примите на вооружение правило написания тест-кейсов:
- Создаём карту приложения или функционального блока приложения.
- Создаём чек-лист опираясь на карту приложения.
- Создаём тест-кейсы опираясь на чек-лист.
Теперь рассмотрим, как правильно составлять чек-лист на основании карты приложения. Сейчас мы не будем рассматривать создание чек-листов без карт приложений, так как это делается аналогично, только не используются карты приложений и в таком случае можно часть функционала приложения забыть зафиксировать в чек-листе.
Для начала у нас должна быть составлена карта приложения:
На карте приложения у нас имеются конечные проверки, обозначенные галочками в зелёных кружочках. Эти проверки мы и будем переносить в чек-лист.
Чек-лист
Раздел «Заголовок»:
- Проверка работы кнопки «Свернуть приложение».
- Проверка работы кнопки «Развернуть приложение».
- Проверка работы кнопки «Закрыть приложение».
Раздел «Содержимое окна»:
- Проверка ввода текста в поле ввода текста (числа, буквы, спецсимволы).
- Проверка работы вертикального скролла (полосы прокрутки).
Раздел «Строка меню» мы не вносили в чек-лист так как карта приложения в данном разделе ещё не завершена и нет конечных проверок. Когда карта приложения будет завершена, тогда и внесём в чек-лист проверки из данного раздела.
Читайте также:
Если внимательно присмотреться в чек-лист и глянуть на функционал программы, то мы увидим, что после того, как программа сворачивается она скрывает свою форму и отображается на панели задач операционной системы, а значит нам надо проверить, что программа может разворачиваться из панели задач и снова отображать свою форму. Для этого мы вносим в чек-лист дополнительную проверку:
- Проверка работы кнопки «Свернуть приложение».
- Проверка работы функционала разворачивания приложения из панели задач.
- Проверка работы кнопки «Развернуть приложение».
- Проверка работы кнопки «Закрыть приложение».
У нас получился следующий чек-лист:
Принцип создания понятен. Важно всегда помнить, что одна конечная проверка из карты приложения, может разделиться на несколько проверок в чек-листе, т.е. в чек-листе будет больше проверок.
Приведём пример. В карте приложения имеется конечная проверка:
- Проверка входа в личный кабинет на сайте.
Мы знаем, что в личный кабинет на сайте мы можем войти несколькими способами, поэтому все эти способы должны быть зафиксированы в чек-листе:
- Проверка входа в личный кабинет на сайте с помощью логина;
- Проверка входа в личный кабинет на сайте с помощью email;
- Проверка входа в личный кабинет на сайте с помощью номера телефона;
- Проверка входа в личный кабинет на сайте с помощью сертификата.
Как видите из одного пункта проверки карты приложения у нас появилось четыре пункта в чек-листе. Эти проверки могли быть зафиксированы и в карте приложения, тогда у нас одна проверка из карты приложения перешла бы в одну проверку в чек-листе.
Имея полностью созданный чек-лист, мы можем дальше создавать тест-кейсы. Опытные тестировщики знающие хорошо функционал тестируемого приложения могут тестировать приложение по чек-листу без тест-кейсов. Тестировщикам плохо знающим функционал приложения тестировать по чек-листам будет затруднительно.
В видео рассказываю как создавать чек-лист:
О принципах правильного написания тест-кейсов я рассказывал в статье «Правильно пишем тест-кейсы». О создании карт приложений я рассказывал в статье «Облегчаем тестировщику жизнь при написании тест-кейсов». В статьях имеются подробные видеоматериалы по данным темам.
Если хотите научиться создавать карты приложений, чек-листы, тест-кейсы и узнать многое другое, то пройдите обучающий курс «Тестирование ПО. Начальный уровень».
26 янв в 10:24 7.5K
Память человека не безгранична, поэтому мы периодически что-то да забываем. Чтобы не упустить важное из виду, приходится все записывать. А что делать, если перед вами стоит сложная задача или процесс, который, в свою очередь, состоит из множества небольших этапов? Конечно же, воспользоваться чек-листом!
Чек-лист – это…
…список, позволяющий разбить сложную работу на небольшие задачи и по которому можно проверить их выполнение. Как только что-то из перечня завершается, напротив соответствующего пункта ставится галочка. Основная цель – воплотить все или хотя бы большинство пунктов. При этом использовать подобный лист можно многократно при повторяющихся процессах.
Считается, что чек-листы пошли из авиации – пилоты с их помощью проверяли готовность ко взлету. Сейчас этот инструмент активно распространился во все сферы нашей жизни.
Основные преимущества составления чек-листов
- Геймификация. Некоторые люди при выполнении какой-то работы очень любят ставить галочки или крестики, таким образом отмечая завершение процедуры. Это превращается в своеобразную игру – чем больше отметок, тем лучше.
- Делегирование полномочий. Если подробно разбивать некоторые рабочие этапы, становится очевидно, какие задачи можно выполнить самостоятельно, а какие – поручить другим. В результате и контролировать другого человека становится в разы проще.
- Исключение или предупреждение ошибок. Порой даже крохотные ошибки могут приводить к глобальным последствиям, а в случае с чек-листами можно устранить вероятность возникновения огромного количества сбоев или несостыковок.
- Мотивация. Когда человек наблюдает за процессом выполнения работы через чек-лист, он наглядно видит прогресс. Это дает чувство удовлетворения и мощный толчок для более быстрого завершения дел.
- Организация – это значит, что ни один этап на пути к достижению цели не будет упущен. В результате обеспечивается прямое выполнение задач, люди становятся в разы более организованными.
- Повышение продуктивности. Как говорилось выше, этот инструмент позволяет снизить вероятность возникновения ошибок, при этом рутинные процессы будут проводиться максимально быстро. Такие действия исключают возникновение авралов и повышают уровень продуктивности людей.
- Получение аналитических данных. Всю информацию потом можно собрать и построить на ее основе графики, гистограммы или диаграммы. Такие действия наглядно покажут повышение продуктивности.
- Совершенствование процессов. Чек-лист считается базовым средством для установления дисциплинированности и последовательности действий сотрудников. Они гарантируют, что ни один сотрудник не забудет ничего важного и все сделает так, как необходимо.
- Экономия времени. Использование шаблона – это экономия времени на ежедневное составление и структурирование списка дел. Человеку не придется долго сидеть и думать, что же делать дальше, ведь самое главное всегда будет под рукой.
Для чего пригодится
Прежде всего, чек-листы нужны для наведения порядка в расписании. Но если смотреть точнее, можно использовать их для решения следующих задач:
- Оптимизация процессов. Если в каких-то делах есть повторяющиеся пункты, можно зафиксировать их и таким образом не пропускать. С помощью чек-листа можно легко делегировать работу другим и осуществлять дальнейший контроль.
- Отслеживание прогресса или результата. С его помощью ярко демонстрируется то, сколько уже пройдено и сколько осталось до достижения цели. Тут хорошо отражается одно из вышеперечисленных преимуществ – при наглядном отображении продвижения к цели повышается мотивация.
- Оценка качества. В этом случае он помогает проверить, соответствует ли созданный продукт/услуга установленным требованиям.
Комьюнити теперь в Телеграм Подпишитесь и будьте в курсе последних IT-новостей
Процессы в чек-листах
Процессы – это определенные последовательности шагов для выполнения задачи, которые могут быть разовыми или же повторяться периодически. Так, подобный инструмент может быть рассчитан на каждый день, на неделю, месяц или даже квартал. Основная цель процессов – определить лучший способ выполнения поставленных задач с согласованными действиями.
Особенности оформления
Если вы решили создать собственный чек-лист, обязательно проверьте финальный вариант на соответствие следующим критериям:
- Четкая постановка цели и целевой аудитории. С одной стороны, если при его создании у вас в голове нет четко поставленной цели, пункты, скорее всего, выйдут несколько размытыми.
- Отражение темы в заголовке. У чек-листа есть конкретная цель.
- Наличие четкой структуры и логики. Пункты должны располагаться либо по хронологии, либо по приоритету, но никак не вразброс.
- Разбор сложных задач на подпункты. Суть чек-листа – напомнить что-то сделать, а когда процесс многоэтапный, не сразу понятно, как к нему подступиться. Чем проще, тем лучше!
- Объединение тематических разделов. Если тема списка достаточно обширна и включает несколько подтем, лучше поделить их в соответствии с ними. Однако тут важно не переборщить, ведь, как говорится, краткость – сестра таланта, особенно в отношении чек-листов.
- Простота и понятность во всем. Прочитав его, человек не должен думать о том, что автор имел в виду. Один пункт должен содержать одно действие. Пусть формулировка будет чересчур простой, но понятной каждому. То же касается и дизайна – не используете плохо читаемые шрифты или неконтрастные цветовые комбинации. И золотое правило – не больше двух ярких цветов, чтобы документ не пестрил и внимание было приковано исключительно к тексту.
- Выдержка формата. Не превращайте список в гайд или инструкцию, не создавайте его чрезмерно объемным. Оптимально будет от 5 до 20 пунктов, если выходит больше – поделите на два вида.
- Охват всех ключевых вопросов по теме. Список получился слишком емким и разнородным? Тему стоит сузить.
- Опущение личных предпочтений или деталей. Это вовсе не гайд, поэтому рекомендовать что-то конкретное автор в нем не может. И чем более универсальными пункты будут в итоге, тем лучше.
Виды чек-листов
- Трекеры – это инструменты, с помощью которых можно внедрять в повседневный образ жизни или рабочий процесс какие-то полезные привычки. Или избавляться от вредных. Главное, что они рассчитаны на определенное количество дней. Пример: пить определенное количество стаканов воды в день или же отказаться от вредной привычки.
- Памятки – они работают по принципу «прочитай – сделай». Этот тип больше ориентирован на новичков, и пункты в нем более походят на советы. Так, если пошагово выполнять перечисленные простые действия, можно прийти к результату. Например, составить резюме или собрать мебель. Сюда же можно записывать план рабочих задач на день (позвонить клиенту, отправить торговое предложение компании N, найти исполнителя для создания логотипа).
- «Прочитай – соотнеси». Этот вид предполагает определение того или иного явления. И чем больше галочек напротив указанных пунктов отмечено, тем больше вероятность соответствия. Такие чек-листы мы часто встречаем в различных тестах.
- Развлекательные чек-листы. Это списки дел, которые нужно сделать за тот или иной период, например за лето, осень или отпуск. Они приносят удовольствие от выполнения задач и проставления галочек.
Есть еще один развлекательный вид подобного списка, его называют буллшит-бинго. В нем изображение поделено на квадраты и в каждом из них прописаны какие-то фразы или действия, которые чаще встречаются и совершаются представителями тех или иных групп или ситуаций. В соцсетях, кстати, они очень часто встречаются – пользователи пересылают их себе в ленту или истории и отмечают совпавшие пункты.
Примеры чек-листов
Подобные списки выполняются в текстовом или визуальном формате, хотя второе встречается куда чаще. Например, у Timeweb есть чек-лист для запуска сайта наподобие памятки, а еще «Кто ваш клиент?» для определения целевой аудитории. А вот из изображений под тип памятки очень подходит следующий, взятый из свободного доступа:
Теперь к трекерам, позволяющим отслеживать те или иные привычки. В интернете можно найти огромное количество интересных вариантов:
Следующий у нас на очереди – «Прочитай – соотнеси»:
Теперь переходим к формату развлекательного списка. Здесь выбор значительно шире, поэтому я выбрала наиболее часто встречаемые типы – один относится ко психологии, а второй касается книг:
Под конец идет самое интересное – это буллшит бинго. Простор для творчества тут огромный. Из самых примечательных отмечу следующие примеры:
Теперь перейдем к сервисам, в которых удобно создавать чек-листы на все случаи жизни. Сначала поговорим о сервисах, в которых можно оформить красивый чек-лист (для презентации, инфографики, памятки, сайта и т.п.), а затем рассмотрим популярные планировщики задач, которые подойдут для мониторинга ежедневных дел и ведения рабочих задач.
Сервисы для оформления чек-листов
Canva
Куда же без нее?! Это универсальный сервис, в котором можно и самому нехилый дизайн разработать, и ярким шаблоном воспользоваться. По соответствующему тегу в сервисе представлено более 15 тысяч шаблонов, поэтому выбрать есть из чего. При желании можно поменять некоторые цвета или элементы местами, добавить что-то свое. Сервис доступен для использования как на платной, так и бесплатной основе.
Adobe Creative Cloud Express
Недавно запущенный инструмент активно набирает обороты, причем вполне заслуженно. Он аналогичен первому сервису, однако тут есть пара нюансов. Первый – он англоязычный, и русский язык в интерфейсе, как и в большинстве шаблонов, недоступен. Второй – если вы захотите выбрать шрифт из обширной библиотеки, за это придется доплатить. Но базовые вещи тут выходят очень даже неплохо. И, несмотря на небольшой «ассортимент» шаблонов, выбора тут все-таки больше по сравнению с Canva.
365Done
А вот это уже отдельный сайт, приспособленный под создание чек-листов. Он русскоязычный, поэтому практически все представленные шаблоны или готовые списки идут на русском языке. Пользоваться им можно как бесплатно, так и платно – для этого есть возможность денежной поддержки проекта или покупка тетрадей, дневников и книг в магазине.
Планировщики задач с опцией чек-листа
Google Keep
Это абсолютно бесплатный сервис… Для ведения заметок. Однако для создания личного чек-листа он тоже вполне сгодится, ведь в нем есть возможность формирования простого списка и отправки его друзьям или коллегам. Что еще удобно, к одной записи крепятся теги и метки по определенной теме, еще есть напоминания, функция добавления фотографий или голосовых записей, а также многое другое. Это отличное решение для тех, кто не хочет заморачиваться и любит делать все самостоятельно.
Microsoft To Do (ранее Wunderlist)
Тоже неплохой планировщик, который можно приспособить под ведение чек-листов. В нем предусмотрена генерация задач из электронной почты, также интеграция с Dropbox, Slack и Zapier. Приложение будет вести учет текущих задач и покажет, какие действия нужно выполнить далее. Некоторые пункты можно установить на повтор и установить для них напоминание. Пользоваться всем этим «бохатством» можно абсолютно бесплатно.
Any.Do
Приложение позволяет вести учет ежедневных дел и составлять красивые, аккуратные чек-листы. В нем можно создавать планы в зависимости от времени или местоположения, а еще делиться задачами с друзьями или коллегами. При этом есть синхронизация с календарем Google и хранилищем iCloud, поэтому данные можно будет синхронизировать для сохранения в одном месте. Плюс тут есть расширенные возможности, позволяющие следить за процентом заполнения списка, устанавливать напоминания пользователям, а также следить за теми, кто формы еще не заполнил. Пользоваться можно бесплатно и платно.
WorkFlowy
Еще один планировщик, только более продвинутый. Бесплатно в нем можно разрабатывать до 100 списков, а за $50 в год это ограничение будет снято, еще будет открыт доступ к неограниченному числу шаблонов и элементов. Функционал обширен – тут можно подбирать разные форматы и делиться ими с коллегами, вписывать задачи в свое или чужое расписание, добавлять заметки.
Упомяну еще пару сервисов для управления бизнес-задачами – Trello и Planfix. В них можно составлять объемный план работ, разделять задачи в списке на подзадачи для детализации прогресса и назначать исполнителей.
Даже самые простые подобные сервисы можно приспособить под составление и ведение чек-листов. Обычные заметки в телефоне для кого-то станут простым и эффективным решением. Хотя это дело вкуса, некоторые все дела ведут с помощью записей в тетрадке. Как всегда, выбирать надо исходя из субъективных предпочтений, лишь бы было удобно.
Наши постоянные авторы и читатели делятся лайфхаками, основанными на личном опыте. Полная свобода самовыражения.
Ошибки в веб-формах могут стать серьезной проблемой для пользователя и бизнеса. В этой статье рассмотрим точную последовательность тестирования форм: позитивные и негативные тесты, текстовые и числовые поля, чек-боксы и радиокнопки.
Веб-формы есть почти на каждом сайте. Они нужны для регистрации на сайте, подачи заявления о кредите в банк, заказа товаров, обращения в службу поддержки. В идеальном мире заполнение форм проходит просто и удобно. Но в реальности в них постоянно случаются ошибки.
Например:
- Форму вообще невозможно заполнить, потому что данные в поля не вводятся
- При отправке уже заполненной формы появляется непонятное сообщение об ошибке
- При вводе пробела и нажатии на Enter приложение зависает, пользователь получает сообщение, что форма отправлена, но информация никуда не отправляется.
Бывают и такие ошибки, о которых пользователь не подозревает, потому что они возникают внутри приложения. Например, в заявке на кредит пользователь вместо номера телефона указал адрес регистрации, и банковские службы с ним не смогли связаться. Или вместо русских букв написал фамилию латинскими, и его заявка не была рассмотрена. Такие ошибки могут иметь серьезные негативные последствия как для пользователя, так и для бизнеса. Чтобы не допустить этого, веб-формы необходимо тестировать.
Задача тестировщика — найти возможные ошибки в работе приложения или сервиса. Хороший тестировщик не просто проверяет все подряд, а полагается на определенную логику и последовательность.
С чего начать тестирование веб-формы
Сначала необходимо определить, с какой именно формой мы имеем дело. Формы могут состоять как из двух-трех полей, так и из нескольких десятков, с разными форматами ввода данных.
Рассмотрим стандартную веб-форму. Там почти наверняка будут поля для ввода информации: имени, фамилии, адреса почты. Такие поля называются текстовыми. Пользователь может ввести буквы, цифры и символы. Какими конкретно данными может быть заполнено поле, решают на этапе разработки.
Например, разрешено использовать только русские буквы или только латинские. Такие детали, как правило, фиксируются в специальных документах. В зависимости от проекта, документы могут называться: технические задания, спецификации, функциональные требования и т. п. Тестировщики обращаются к ним в процессе своей работы, чтобы проверить, насколько функционал соответствует ожиданиям заказчика. В нашей статье мы будем называть их обобщенно — требования.
Позитивное тестирование
Первые тесты проверяют, что поле работает корректно: так, как описано в требованиях. Это позитивные тесты. Они проверяют сценарии, в которых пользователь делает, то, что от него ожидается. Это правило работает не только для тестирования полей, но и для тестирования функций и поведения системы в целом: сначала проверяем, что все работает правильно.
Как правило, текстовые поля подразумевают ввод следующих данных: фамилия, имя, адрес, логин, комментарий. В нашем поле будет фамилия.
Проверки для текстового поля разделим на две категории:
- Проверки допустимого количества символов в поле. Например, в поле можно ввести только 30 букв
- Проверки ввода допустимых символов, то есть букв, цифр, специальных символов.
Для тестирования количества символов в текстовом поле проводятся следующие тесты:
- Среднее количество символов в поле: Иванов
- Минимальное количество символов в поле: И
- Максимальное количество символов в поле: Ивановпертровсидоргончаровпушкинлермонтов
- Ноль символов: если поле необязательно для заполнения.
Для проверки ввода допустимых символов применяют следующие тесты:
- Буквы, цифры, специальные символы
- Текст с пробелом: в начале строки, в середине и в конце
- Можно вставить в поле скопированный текст
- Перенос строки внутри поля через 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 шт.
- Буквы, специальные символы.
Самые частые ошибки в числовых полях:
- Обязательные поля можно оставить пустыми
- Нет сообщения об ошибке, если пользователь вводит некорректные данные
- Можно вводить буквы и специальные символы в поле «Номер телефона» и другие подобные поля
- Нет ограничения на количество символов в полях: можно ввести несколько тысяч знаков и повредить работу приложения.
На скриншоте пример одного из дефектов: отсутствует сообщение об ошибке, когда поле «Номер телефона» заполнено буквами и символами.
Чек-боксы и радиокнопки
Часто, помимо заполнения текстовых или числовых полей, пользователю нужно выбрать один или несколько готовых вариантов ответа. Это делается с помощью чек-боксов. Также они используются для подтверждения каких-либо действий или согласий.
Еще один вариант выбора готового ответа — радиокнопки. Они используются для переключения между вариантами и позволяют выбрать только один вариант из нескольких.
Подведем итоги
Мы рассмотрели четыре типа самых распространенных полей в веб-формах: текстовые, числовые, чек-боксы и радиокнопки. Но это далеко не все проверки, которые могут потребоваться от тестировщика в зависимости от требований заказчика, целевой аудитории и здравого смысла.
- В тестировании важна последовательность и логика, так как проверок может быть много, и важно выбрать из них самые эффективные — те, которые помогут быстро найти самые серьезные дефекты.
- Тестирование начинается с позитивных сценариев и базовых проверок — убедиться, что поле или функция работают правильно и выполняет свои основные задачи. Дальше можно делать более детальные позитивные проверки с использованием разных техник.
- После позитивных проверок нужно переходить к негативным — проверить, что если пользователь введет в поле неправильные данные, то приложение покажет ему сообщение об ошибке.
При этом работа тестировщика не ограничивается только проверкой полей ввода, а предполагает разные задачи. Сложность задач зависит от проекта, над которым работает тестировщик, а также от его опыта, знаний и навыков. Для выполнения большинства задач специалисту по тестированию, помимо технических знаний, потребуются аналитические способности, внимательность и любопытство.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
Anastasia 24 июня 2022
ли со статьей или есть что добавить?