чит лист для тестирования кнопок
Где брать идеи для тестов (подборка полезных ссылок)
Вот выдали нам (тестировщикам) функционал и сказали:
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Где брать идеи
Статьи
Они обычно называются «классы эквивалентности для. », или «чек-лист для. », или «чит-лист для. », или как-то так. Вот вам мои подборки:
Классы эквивалентности для стандартного грида — то есть для шапки отчета, по которой можно сортировать
Это еще не конец! — в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню…
Юлия → Iuliia. Схемы транслитерации — если ваша система что-то транслитерирует, то будет полезно.
Чит-листы в Ситечке
В системе «Ситечко» есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).
Чтобы их увидеть, нужно:
Ну и всё, дальше уже выбираете нужный вам.
Работы студентов
Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:
Плагины для автозаполнения полей
Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:
Исследовательские туры
Туры из книги James A. Whittaker — это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.
Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять — можно найти там вдохновение!
Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
Наш чек-лист для форм на сайтах
Это вторая часть наших чек-листов. В первой мы подробно разобрали требования к фильтрам. В отличие от фильтров, требования к пользовательским формам более универсальны. Однако нам потребовалось несколько жарких дискуссий, чтобы выработать более-менее единый формат. Видео с HolyWarModeOn рассказывает о типовых ошибках юзабилити в проектах. Сразу под роликом ищите подробный чек-лист для форм на сайте.
Важность: Extra High
□ Сохранение формы.
□ Форма сохраняется в веб-формах (админ-панели) или SQL-таблицах.
□ Изменение адреса отправки.
□ E-mail, на который приходят данные из веб-формы, можно менять в административной панели.
Важность: High
□ Актуальность адреса отправки.
□ Прописан реальный e-mail лица, отвечающего за обработку заявок.
Почему именно так. Ситуация из типичных будней техподдержки: владелец
интернет-магазина рвет и мечет — нет заявок от клиентов. Открываем админку, смотрим: внесен адрес svetochek1988@mail.ru, куда и попадают все запросы. Дальше объяснять нет смысла.
□ Отправка формы.
□ Данные из заполненной формы отправляются администратору на e-mail.
□ Отправка уведомления пользователю.
□ Опционально. Пользователь получает уведомление на свой e-mail об успешно полученной заявке и последующих действиях, которые от него требуются.
Навигация
□ Предусмотрены плейсхолдеры (placeholder) для полей.
□ Если названия полей не подписаны, то внутри полей выводится подсказка, которая исчезает при внесении текста.
Почему именно так. Пользователям нужны инструкции, а проектировщикам и дизайнерам — компактный способ предоставления информации.
□ Прописан атрибут autocomplete для полей, поддерживающих это значение.
Атрибут autocomplete подставляет ранее введенные пользователем данные в поле, если функция не отключена в браузере.
Почему именно так. Чем быстрее пользователь заполнит форму, тем выше вероятность, что он ее отправит.
□ Правильная работа многошаговых форм.
□ Навигация рядом с формой показывает текущий этап и количество оставшихся шагов.
Почему именно так. Неизвестность пугает посетителей и снижает вероятность полного заполнения объемной формы. Положительный пример — Asos. В форме указано пять шагов, но по факту регистрация проходит в пять раз быстрее — основные функции сайта доступны сразу после заполнения первого экрана регистрации.
Замечание. На некоторых проектах мы отказались от стандартной регистрации в пользу авторизации через социальные сети.
Пример: Restlook.
□ Многошаговые формы корректно работают при навигации посредством кнопок «Вперед» и «Назад» в браузере.
Валидация
□ Для числовых значений из определенного диапазона прописаны ограничители минимального и максимального количества символов.
□ Проверьте это для дат, времени и прочих подобных характеристик.
Почему именно так. Простая подстраховка от ввода откровенного вранья или появления ошибок по невнимательности — даты рождения в будущем или времени доставки раньше времени заявки.
□ Для полей, предполагающих загрузку файлов, прописан атрибут accept, определяющий тип загружаемых документов.
Почему именно так. Если прописан атрибут accept, при выборе с жесткого диска пользователь видит только подходящие типы файлов для загрузки — например, doc и txt. Это исключает отправку документов в формате, не подходящем для обработки.
□ Для полей, валидация которых проходит через регулярное выражение, прописан атрибут pattern.
Валидация — это проверка введенных пользователем данных на соответствие требованиям системы. Информация проверяется путем сверки с регулярным выражением, заданном в специальном формате.
Например, регулярное выражение 1 <5,10>для пароля означает, что он может состоять только из цифр, а его длина колеблется от пяти до десяти символов. Если для поля прописан атрибут pattern, то форма не отправляется, пока данные не будут введены верно.
□ Требуемый формат данных, которые должен ввести пользователь, очевиден для него.
Почему именно так. Пользователь должен понимать, чего от него ждут при вводе данных. Для этого предназначены краткие пояснения вроде «Пароль состоит не менее чем из 8 символов и включает цифры и латинские буквы».
□ Доступна инструкция по формату вводимых данных на человеческом языке.
Почему именно так. Очевидная и понятная подсказка позволяет быстро разобраться в причинах ошибки и не чувствовать себя тупым при заполнении полей формы.
□ Пользователь не видит регулярного выражения как подсказки к действию.
Почему именно так. Подсказка у поля индекса, представляющая собой регулярное выражение 5, малоинформативна. Фраза «Индекс состоит из цифр от 0 до 9» намного понятнее пользователю.
□ Сообщения об ошибках понятны обычным пользователям и логичны.
Важно. Типовая ошибка — регулярное выражение в сообщении о неверном заполнении формы.
Прочее
□ Форма запрашивает у пользователя только необходимые данные.
Откройте форму, визуально убедитесь, что требуется внести только необходимый минимум информации.
Почему это важно. Объемные формы убивают конверсии. Регистрация, покупка или обратная связь должны быть максимально простыми, чтобы не путать пользователей.
□ Если все поля обязательны для заполнения, рядом с их названиями не выводятся звездочки — символ *.
Откройте форму и убедитесь в этом визуально. Желательно наличие поясняющего текста об обязательном заполнении всех полей.
□ Для авторизованного пользователя в поля формы автоматически подставляются все известные о посетителе данные.
Убедитесь визуально, что указанная пользователем в профиле информация автоматически выводится в полях форм, запрашивающих эти данные.
□ Текстовое многострочное поле при вводе объемного сообщения изменяет высоту либо в правой части появляется скроллбар для просмотра всего содержимого.
Откройте форму с текстовым многострочным полем, введите в него максимально большое количество символов.
Почему именно так. Многие пользователи перечитывают написанное перед отправкой. Нужно дать им возможность воспользоваться скролл-баром или просмотреть все сообщение в расширенном поле вместо перемещения по тексту с помощью стрелок клавиатуры.
□ В полях формы прописан корректный атрибут TYPE, сообщающий браузеру тип элементов формы.
□ Правильно указаны типы дат, времени, телефонов, диапазонов, url, e-mail, чисел.
□ Во время отправки формы на медленном канале пользователь не может менять в ней данные.
Важно. Действительно для ajax-форм.
Почему именно так. При невысокой скорости соединения форма ajax отправляется не сразу, некоторое время оставаясь на экране со всей внесенной информацией. Пользователь не должен в этот момент передумать и поменять все данные. Точнее, передумать он как раз может, но реализовать свою задумку — уже нет: необходима блокировка от изменений до момента получения ответа от сервера.
При этом желательно визуально показать, что форма заблокирована. Один из вариантов — прелоадер:
Важность: Low
□ Вывод подсказок и ошибок сделан с анимационным эффектом.
Замечание. Этот параметр зависит от дизайна и не является обязательным.
Далее — три спорных истории, которые нужно решать с менеджером на этапе проектирования.
□ Кнопка отправки данных неактивна, пока не активирован чекбокс «Согласиться с правилами», «Пользовательское соглашение».
□ Кнопка отправки данных неактивна, пока все введенные данные не прошли положительную валидацию.
Откройте форму с полями для ввода, введите некорректные данные, проверьте, активна ли кнопка.
Это важно. В некоторых случаях некорректность — понятие относительное. Подстава подстав — валидация номеров телефонов в форме обратной связи. Если вкратце — отключайте ее.
□ Если данные не прошли положительную валидацию, при наведении курсора на кнопку для отправки данных выводится информационное сообщение.
Откройте форму, введите некорректные данные, наведите курсор на кнопку отправки данных, проверьте, выводится ли сообщение.
Список можно распечатать — пользуйтесь для тестирования юзабилити. То же самое — в документе Google.
Чит лист для тестирования кнопок
Что пишут в блогах
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/01/testing-buttons.html
http://thethinkingtester.blogspot.com/2018/02/testing-back-buttons.html
Перевод: Ольга Алифанова
Про кнопки, как правило, легко забыть. Кнопка «Сохранить» настолько универсальна, что кажется, что она просто не может не сработать. Однако игнорирование тестирования кнопок на странице может привести к игнорированию багов. Недавно мне рассказали о тестировании функциональности существующей веб-страницы. Новая фича отлично работала, но команда забыла проверить кнопку «Удалить». Оказалось, что разработчики забыли добавить действие удаления, и кнопка делала ничего!
Вот о чем стоит помнить, тестируя кнопки!
Если вы никогда не редактировали html веб-страницы во время тестирования, вот небольшая инструкция для Chrome:
Кнопки – один из самых важных элементов для тестирования. Представьте, как взбесится пользователь, если кнопка, которой он пытается воспользоваться, неактивна, или не делает того, что должна. Внимательно тестируя, мы убедимся, что пользователям захочется продолжать работу с нашим приложением.
Тестирование кнопки «Назад»
Эта кнопка встречается так часто, что про нее легко забыть, тестируя приложения. Первое, что нужно знать, приступая к тестированию такой кнопки – это то, что они бывают разных типов. Две основные категории – это нативные кнопки и кнопки приложения.
Нативные кнопки – это кнопки, встроенные в браузер, мобильную операционную систему, и в мобильный телефон физически. На фотографии выше стрелочка «назад» – это кнопка Хрома. В Андроиде, как правило, есть кнопка «назад» внизу экрана, которую можно использовать в любом приложении. У iPhone эта кнопка находится наверху страницы.
Тестируя сайты и приложения, важно проверить поведение ВСЕХ кнопок «Назад», даже тех, которые добавлены не вашей командой. Первое, что стоит сделать – это подумать, куда эти кнопки должны вести. Это кажется очевидным, но иногда простой переход на предыдущую страницу – не самая удачная мысль. К примеру, пользователь редактирует свои данные на странице редактирования. Закончив редактировать и перейдя к сохраненной информации, пользователь не должен попадать на окно редактирования по кнопке «Назад» – он может решить, что ему нужно заново редактировать данные. Вместо этого лучше направлять его на страницу, которая была до страницы редактирования.
Еще нужно разобраться, как эти кнопки должны себя вести, если пользователь разлогинился. В этом случае пользователь не должен возвращаться к авторизованному состоянию, потому что это уязвимость безопасности. Что, если он пользуется публичным компьютером? Следующий пользователь может получить доступ к защищенной информации.
Что касается кнопок мобильных устройств, подумайте, как они должны работать в вашем приложении. Пользователь будет раздражаться в случае, когда он ожидает, что кнопка вернет его в какой-то раздел приложения, а на самом деле она полностью это приложение закрывает.
Если в ваше приложение встроены свои кнопки перехода назад, проверьте их, создав максимально длинную последовательность переходов. Ищите проблемы логики, когда приложение переправляет вас в неожиданное место, и ошибки памяти, вызванные сохранением большого количества страниц в пути приложения.
Можно также проверить, что кнопка «назад» активна и заблокирована в правильных ситуациях. Мы же не хотим, чтобы пользователь нажимал на активную кнопку «Назад», которая никуда не ведет?
Если вкратце, то при тестировании веб-сайта или приложения отмечайте все кнопки «назад» и все сценарии, соответствующие им. Затем проверьте эти сценарии и убедитесь, что эти кнопки понятны и полезны вашим пользователям.
Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести:
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:
Как мы тестируем frontend (html-верстку). Чек-лист
Меня зовут Павел, я со-основатель 100UP (разработка сайтов и рекламное агентство в одном лице). Мы занимаемся дизайном и разработкой технически сложных веб-проектов. В основном это e-commerce и b2b-порталы (личные кабинеты дилеров, производителей и др.).
В этой статье мы бы хотели поделиться своим опытом как мы в своей команде тестируем html-верстку, так как качественная верстка является неотъемлемой частью успешного запуска проекта.
Есть масса примеров, когда компании в спешке с желанием как можно скорее представить новый сайт клиентам, решали, что не стоит тратить “лишнее” время на качественное тестирование, выпускали очень “сырой” проект. Конечно, для простых корпоративных сайтов упущенная прибыль минимальна при запуске проекта с кривой версткой, а вот для коммерческих проектов стоимость ошибок слишком высока, особенно для интернет-магазинов, когда посетитель не может подобрать товар или даже оформить заказ.
1. Два вида тестирования: ручное и автоматизированное. Автоматизация: юнит-тесты и интеграционные тесты.
2. Чек-лист по тестированию верстки: что в себя включает проверка; проверяемые параметры.
3. В каких браузерах и на каких устройствах мы тестируем.
4. Разработка сайта и тестирование. Схема.
5. Сервисы, которые используются для тестирования верстки сайта.
Тестирование верстки сайта осуществляется двумя способами — вручную и с помощью автоматизированных тестов.
Для того, чтобы выполнить ручное тестирование, разработчику и тестировщику необходимо “пройтись” по всем пунктам разработанного заранее чек-листа (представлен в пункте статьи №2).
Преимущество ручного тестирование заключается в его “гибкости” и детальности. Тестировщик может увидеть сценарии, которые не прописаны в скрипте, и тут же протестировать их. Однако есть и существенный минус — приходится все “делать своими руками”, а это значит, что затрачивается значительное количество времени. Сократить время проверки помогает автоматическое тестирование.
Автоматическое тестирование осуществляется с помощью тестов, которые пишутся разработчиками, для выполнения повторяющихся монотонных действий, а также для поиска неочевидных ошибок. Разработчик один раз пишет тест, затем в последующем использует его для проверки похожих компонентов на разных сайтах.
Самые низкоуровневые (простые) тесты — это юнит-тесты. В широком смысле юнит-тесты — это код, который тестирует юниты (части) кода: функции, модули и классы. В рамках frontend-разработки юнит-тесты — это тесты javascript. Обычно каждый javascript-компонент сайта имеет большое количество мелких юнит-тестов. Каждый такой тест проверяет только одно взаимодействие с тестируемым компонентом.
Основным преимуществом юнит-тестов является их независимость от других частей приложения — часто корректировки в скрипты можно вносить точечно, не изменяя весь код теста. Кроме того эти тесты небольшие, и во многих случаях их написание не занимает много времени.
Для написания и воспроизведения юнит-тестов мы используем фреймворк jest. Тесты производятся в виртуальной среде, где взаимодействие с сервером эмулируется.
Кроме юнит-тестов также для автоматического тестирование верстки мы используем приемочные тесты или интеграционные тесты. В интеграционных тестах производится тестирование как и целых компонентов, так и взаимодействие разных компонентов друг с другом. Такие тесты позволяют проверить, как frontend будет вести себя на готовом сайте на CMS-движке. В первую очередь данными тестами проверяется взаимодействие различных javascript-компонентов между собой.
Приемочные тесты в отличие от юнит-тестов не проверяют мельчайшие детали компонентов, а тестируют их основные функции. Внутри этих тестов мы пытаемся максимально имитировать действия пользователей: тесты нажимают кнопки, ждут отклика, заполняют поля, переходят по ссылкам.
Для написания приемочных тестов мы используем Selenium.
Кроме того к автоматическим тестам мы относим мониторинг сайта и логирование javascript-ошибок, найденных при взаимодействии с этим сайтом. На наших сайтах мы логируем javascript-ошибки с помощью Sentry.
Данный чек-лист постоянно нами обновляется и каждый его пункт содержит описание, которое мы решили не вставлять в эту статью, так как она была получилась “километровая”. Актуальный чек-лист с комментариями можно посмотреть на нашем сайте.
Мы пришли к тому, что проверяемые параметры можно разделить на несколько групп:
1. Соответствие макету
2. Работа в разных окружениях
3. Проверка на разных разрешениях экрана (проверка десктопной и адаптивных версий)