Что такое радиобаттон в тестировании

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

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

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

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

  • Форму вообще невозможно заполнить, потому что данные в поля не вводятся
  • При отправке уже заполненной формы появляется непонятное сообщение об ошибке
  • При вводе пробела и нажатии на 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 шт.
  • Буквы, специальные символы.

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

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

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

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

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

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

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

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

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

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

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

Радиобаттон в CSS: что это, для чего используется и как применять

Lorem ipsum dolor

Радиобаттон — это свое го рода «переключатель» между элементами. Устанавливается в местах, где пользователю необходимо выбрать один элемент из нескольких предложенных. Как правило, это блоки из нескольких вариантов выбора. К данному блоку можно применить вопросы: «Что именно?», «Какой точно выбрать?»

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

Радиобаттон: правила размещения

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

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

Делаем радиобаттон заметнее при помощи CSS

  1. Превратите радиобаттон в блок полноценных кнопок. Для этого блок значений можно выделить «border», а фон заполнить каким-либо цветом. И организовать таким образом, чтобы при наведении цвет менялся .
  2. Добавьте иконку. Перед или после значений радиобаттон можно добавить тематическую иконку, возможно , даже цветную, чтобы она быстрее бросалась в глаза.
  3. Добавьте псевдоссылку. Можно организовать стиль , как у ссылок на странице. То есть выделить только значения одним цветом, а при наведении на значение сделать так, что бы цвет менялся.
  4. Полноценный переключатель между 2-мя значениями. Тут можно расположить 2 значения горизонтально и сделать их в виде полноценных кнопок. Сделать так, чтобы выбранный элемент выделялся как минимум цветом.

Помогаем сделать выбор

  • Мужчина
  • Женщина
  • Не указан
  • Мужчина
  • Женщина

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Структура, содержание и процесс написания проверок

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

Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает мобильные приложения с 2011 года. За это время мы создали структуру и содержание проверок, которые помогли улучшить процесс тестирования приложений.

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

Польза собственной структуры проверок

Очень важный инструмент при тестировании — тест-кейсы и чек-листы (далее — проверки), покрывающие приложение. Без них невозможно поддерживать качество на необходимом уровне.

1. Понятна и информативна

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

2. Единообразна для любого проекта: имеет общую структуру внутри одной компании

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

3. Покрывает необходимый процент фич

Чтобы обеспечивать определенный процент покрытия фичи, нужно:

знать, как посчитать этот процент,

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

При хаотичном написании проверок это ресурсозатратно и сложно.

4. Обеспечивает прозрачность работы QA

Разработчики имеют доступ к проверкам, могут заранее просмотреть фичу на этапе разработки: очевидные баги не попадут в сборку.

5. Обеспечивает возможность быстро и удобно модифицировать проверки

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

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

Эти критерии побудили нас организовать одну общую структуру, чтобы писать в прямом смысле одинаково. Но, что важно, одинаково только в рамках общей структуры: свобода «творчества» внутри каждой проверки остаётся.

Почему важно делать проверки одинаковыми по структуре

Осталось ответить на вопрос: почему писать «одинаково» настолько важно?

1. Большое количество проектов

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

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

2. Мы разные

У каждого своё мировоззрение, опыт и видение «как правильно»: это делает нас сильнее, но придаёт свои особенности в работе. Каждый из нас говорит на своем языке. Чтобы успешно взаимодействовать, нужно знать ещё один — общий.

3. Высокий темп разработки

Быстрая скорость разработки проектов не позволяет тратить много времени на онбординги и активности по написанию. Общая структура написания помогает уменьшить время на понимание проекта.

4. Стремление делать качественно

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

Всё это делает необходимым переход к единообразному написанию проверок с долей свободы.

Содержание структуры

Приложения состоят из экранов, шторок, попапов, полей ввода, кнопок, чек-боксов, свитчеров и так далее…

Мы решили разбить все составляющие на элементы и места, где они находятся. А далее — углубиться в клиент-серверную архитектуру приложения (без неё сегодня никуда). Данные на экране почти всегда берутся из запроса: он может отдать корректный и некорректный ответы. Поэтому стоит проверять и экран отдельно, и в прямом взаимодействии с запросом. Аналогично работает и с элементом.

1. Проверки, связанные с экраном (в том числе шторка/popup и так далее)

→ Инициализация
→ PTR/КЭШ
→ Навигация: Закрытие/Возврат
→ Логика взаимодействия между экранами в стеке и МП
→ Компоновка
→ Работа с запросами

2. Проверки, относящиеся к элементу (поле, карусель, чек-бокс, радиобаттон и так далее)

→ Позитивные проверки
→ Негативные проверки
→ Логика работы элемента
→ Работа с запросами

3. Проверки, относящиеся целиком к фиче

→ Точки входа в тестируемую фичу
→ Взаимодействие текущей тестируемой фичи с другими

4. Чек-листы, помогающие в регрессионном тестировании

Визуализация написания проверок по фиче

Визуализация написания проверок по фиче

Экран (в том числе шторка/popup)

Визуализация написания проверок по экрану

Визуализация написания проверок по экрану

→ Инициализация или Отправка данных

Фича. Экран — инициализация

Фича — главное действие фичи (: если фича одноэкранная)

Фича. Экран — главное действие фичи/экрана (: если фича многоэкранная)

→ Обратная связь. Экран обратной связи — инициализация

→ Обратная связь — отправить обращение

→ Оформление — создать заказ

Данные на экране отображаются в соответствии с полученным ответом на запрос

Данные из ответа запроса для формирования экрана берутся из нужных параметров

Отображение Empty State (если данные не пришли).
Непосредственно данный экран рассматривается отдельно: компоновка, работа элементов и запросов.

Корректный запрос сформирован и отправлен

Данные в запросе отправляются в нужных параметрах (согласно сваггеру и ТЗ)

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

Негативный по бизнесу кейс: запрос возвращает в ответе ошибку 502. Редко встречается, сложно воспроизводить (по крайней мере, так ожидается).

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

→ Инициализация или Отправка данных — ошибка на запрос

Фича. Экран — инициализация, ошибка на запрос

Фича — главное действие фичи, ошибка на запрос (: если фича одноэкранная)

Фича. Экран — главное действие фичи/экрана, ошибка на запрос (: если фича многоэкранная)

→ Обратная связь. Экран обратной связи — инициализация, ошибка на запрос

→ Обратная связь — отправить обращение, ошибка на запрос

→ Оформление — cоздать заказ, ошибка на запрос

Ответ на запрос получен с ошибкой

Таймаут (проверить ограничение ожидания ответа на запрос в МП)

Основные ошибки от сервера (индивидуально для проектов)

Отображение Error State
Непосредственно данный экран рассматривается отдельно: компоновка, работа элементов и запросов.

→ Инициализация или Отправка данных — отсутствие интернета

Фича. Экран — инициализация, без интернета

Фича — главное действие фичи, без интернета (: если фича одноэкранная)

Фича. Экран — главное действие фичи/экрана, без интернета (: если фича многоэкранная)

→ Обратная связь. Экран обратной связи — инициализация, без интернета

→ Обратная связь — отправить обращение, без интернета

→ Оформление — создать заказ, без интернета

Отображение соответствующего уведомления (например, snackbar на экране)

Отображение экрана (индивидуально для проектов)

Отображение Error State в случае отсутствия сети (актуально при инициализации экрана)

Отображение состояния load-state (актуально при инициализации экрана)

Отсутствие изменений на UI или наоборот явное изменение в состоянии отсутствия сети (актуально при PTR или изменении фильтра/сортировки, выбора значений с запросами)

Обновление Error State (PTR или кнопка)

→ PTR и КЭШ, если есть

→ PTR, если есть

Фича. Экран — PTR

→ Обратная связь. Экран обратной связи — PTR

В этом случае аналогично текущей структуре лучше создать три разных проверки:

Фича. Название экрана — PTR

Фича. Название экрана — PTR, ошибка на запрос

Фича. Название экрана — PTR, без интернета

→ КЭШ, если есть (работы с ним/без него)

Фича. Экран — PTR, без кэша

Фича — инициализация, с кэшем, без интернета

→ Обратная связь. Экран обратной связи — PTR, с кэшем

→ Обратная связь — инициализация, с кэшем, без интернета

В этом случае аналогично текущей структуре лучше создать несколько разных проверок:

Фича. Название экрана — инициализация, с/без кэша

Фича. Название экрана — инициализация, с/без кэша, ошибка на запрос

Фича. Название экрана — инициализация, с/без кэша, без интернета

→ PTR и кэш, если есть (и используются на одном экране)

В этом случае, согласно текущей структуре, лучше создать несколько разных проверок:

Фича. Название экрана — PTR, с/без кэша

Фича. Название экрана — PTR, с/без кэша, ошибка на запрос

Фича. Название экрана — PTR, с/без кэша, без интернета

Навигация: Закрытие экрана / Возврат назад на предыдущий экран

Фича. Экран — закрытие

Фича. Экран — назад на предыдущий экран

→ Обратная связь. Экран обратной связи — закрытие

→ Обратная связь. Шторка списка тем — закрытие

→ Оплата. Попап Комиссия — закрытие

→ Обратная связь. Экран обратной связи — назад на на предыдущий экран

Если запроса нет, достаточно одной проверки по закрытию экрана. Если запрос используется, лучше создать три разных проверки:

Фича. Название экрана — закрытие

Фича. Название экрана — закрытие, ошибка на запрос

Фича. Название экрана — закрытие, без интернета

Фича. Название экрана — назад на предыдущий экран

Фича. Название экрана — назад на предыдущий экран, ошибка на запрос

Фича. Название экрана — назад на предыдущий экран, без интернета

Со следующими шагами:

Назад по кнопке, если есть

Физическая кнопка «Назад» на Android

Бэксвайп на iOS

→ Логика взаимодействия между экранами в стеке и МП

Такая логика может быть описана в возврате (предыдущий пункт)

Фича — логика работы в стеке экранов

→ Обратная связь — логика работы в стеке экранов

Сохранение данных в стеке экранов одной фичи — если предусмотрено / Очистка данных при переходе и возврате на экраны — если сохранение не предусмотрено

Частный случай: сохранение/очистка в кэше — свернуть и запустить приложение -> отображение данных как и до сворачивания

Сворачивание приложения во время флоу — сохранение положения МП

→ Компоновка

Фича. Экран/шторка/tup фичи — компоновка

(: заполненное состояние, error state, empty state, состояние без интернета (если для этого специфичный экран))

→ Обратная связь. Экран обратной связи — компоновка

→ Обратная связь. Экран обратной связи. Еrror State — компоновка

→ Обратная связь. Экран обратной связи. Empty State — компоновка

→ Обратная связь. Экран обратной связи. Без интернета — компоновка (если отличается от Error State — компоновка)

→ Обратная связь. Шторка списка тем — компоновка

→ Обратная связь. TUP успеха — компоновка

Описание элементов: их наименования + дизайн (скриншот, ссылка на фигму). Если это кнопка, то здесь же проверяется её пресс-стейт

Элемент (поле, карусель, чек-бокс, радиобаттон и тп)

Визуализация написания проверок по элементу

Визуализация написания проверок по элементу

→ Позитивные проверки

Фича. Элемент — позитивные проверки (: если фича одноэкранная)

Фича. Экран/шторка/TUP. Элемент — позитивные проверки (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)

→ Cписок товаров. Фильтр. Поле дата — позитивные проверки

→ Перенос средств. Экран выбора услуг. Поле сумма — позитивные проверки

→ Настройки. Радиобаттон выбора темы — позитивные проверки

→ Обратная связь. Чек-бокс согласия на обработку данных — позитивные проверки

Заполнение поля корректными значениями

Вставка в поле корректных значений

Для текстового поля без ограничений вставка или заполнение поля смайликами — позитивная проверка: она очевидно возможная.

Для поля ввода суммы с цифровой клавиатурой вставка смайликов — негативная проверка: она очевидно неожиданная для текущей логики поля.

Ограничение на размер поля

Техника классов эквивалентности и граничных значений (позитивные проверки)

Заполнение поля максимально возможной длиной, если длина большая и текст может зайти на границу экрана (проверка на корректное расширение/скролл поля и отображение в нём значения)

Пустое поле (если заполнять его необязательно)

→ Негативные проверки

Фича. Элемент — негативные проверки (: если фича одноэкранная)

Фича. Экран. Элемент — негативные проверки (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)

→ Cписок товаров. Фильтр. Поле дата — негативные проверки

→ Перенос средств. Экран выбора услуг. Поле сумма — негативные проверки

→ Настройки. Радиобаттон выбор темы — негативные проверки

→ Обратная связь. Чек-бокс согласия на обработку данных — негативные проверки

Заполнение поля некорректными значениями

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

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

Эти поля или элементы валидируются по кнопке

Вставка в поле некорректных значений

Ограничение на размер поля

Техника классов эквивалентности и граничных значений

Пустое поле (если заполнять его обязательно)

→ Логика работы элемента

Фича. Элемент — логика работы (: если фича одноэкранная)

Фича. Экран. Элемент — логика работы (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)

→ Cписок товаров. Фильтр. Поле дата — логика работы

→ Перенос средств. Поле сумма — логика работы

→ Настройки. Радиобаттон выбор темы — логика работы

→ Обратная связь. Чек-бокса согласия на обработку данных — логика работы

Общие действия с элементом и его реакция на них

Примеры:

→ Открытие определенного вида клавиатуры при активации поля

→ Расширение поля при заполнении

→ Выставление курсора в конец заполненной строки при активации поля

→ Валидация поля при снятии фокуса

→ Валидация поля при нажатии кнопки

→ Маска (для номера телефона, например)

→ Корректная активация/деактивация чек-бокса/радиобаттона

→ Зацикленная карусель / Незацикленная карусель

→ Точки входа в тестируемую фичу

Фича — точки входа

→ Обратная связь — точки входа

Указываются проверки покрывающие все места, откуда можно попасть к тестируемой фиче с других экранов

→ Взаимодействие текущей тестируемой фичи с другими

Фича. Взаимодействие с другими фичами — другая фича

→ Обратная связь. Взаимодействие фичи с другими фичами — темная тема

Примеры:

→ Темная тема (если поддерживается)
Смена темы и работа с тестируемой фичей

→ Пуш-уведомления + диплинки (если поддерживаются)
Переход по диплинку во флоу тестируемой фичи

→ Планшет (если поддерживается)
Компоновка, режим сплит-вью (если поддерживается)

— Huawei (если поддерживается)
Специфичные проверки (см. Особенности тестирования Android без Google-сервисов)

Готовые чек-листы

→ Обязательный чек-лист проверок

Добавляется в каждый прогон по фиче и регресс-прогон. Он может быть расширен индивидуально на проекте.

Изменение размера шрифтов из настроек устройства

Смена темы из настроек устройства

Изменение языка из настроек устройства

Смена времени из настроек устройства

Использование кастомной клавиатуры Android (в частности, для полей и поисковой строки)

Входящий звонок/смс во время прохождения флоу фичи

Выход из приложения двойным «Назад» на Android

Свернуть приложение и запустить снова

Свернуть приложение во время ожидания ответа на запрос

Отключить интернет во время ожидания ответа на запрос

→ Дополнительный чек-лист проверок

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

Запустить приложение без доступа к интернету вообще

Нажатие кнопки блокирования при отображении сплеша

Запуск и сразу же сворачивание приложения

Сворачивание приложения во время отображения системного окна оплаты Apple/Google/Samsung/Huawei Pay

Отображение на планшетах (в режиме совместимости, если нет поддержки планшетов)

Автоподстановка кода из смс (иногда идет по-умолчанию в iOS проектах)

Работа приложения при пуш-уведомлении другого стороннего приложения (сообщение ВКонтакте, Twitter и так далее)

Работа приложения после срабатывания будильника/таймера/смс/другого системного приложения

Работа открытого приложения после разблокировки приложения

Работа свернутого приложения после разблокировки приложения

Работа приложения при сообщении о нехватке заряда

Работа приложения при зарядке

Работа приложения после отключения от зарядки

Работа приложения при воспроизведении музыки

Работа приложения с мобильным интернетом 3G/4G/слабым интернет-соединением

Работа с фичей «картинка в картинке» (если поддерживается)

Что даёт структура проверок

возможность обеспечить необходимое покрытие,

возможность быстрой модификации.

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

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

Когда QA работает с sanity или smoke тестированием, нет смысла тратить время на детальную проверку каждого элемента. Нужны сценарные проверки, которые покроют целиком путь пользователя. О том, как работать со сценарными проверками, поговорим в следующей статье.

А как вы решаете вопрос с организацией проверок? Придерживаетесь хаотичного или системного подхода? Поделитесь в комментариях!

Радиокнопки RadioGroup

Группа радиокнопок используется для выбора одного значения из нескольких.

Радиокнопки (от англ. radiobutton) получили свое название от кнопок в старых радиоприемниках: нажатие на кнопку включало определенную частоту, остальные кнопки отскакивали вверх. Визуально такие кнопки были больше похоже на переключатель, но, почему-то среди дизайнеров такое название не прижилось.

Тем не менее при общении с пользователями мы говорим не «радиокнопка», а «переключатель», см. Глоссарий

Когда использовать

Группу радиокнопок используют, когда вариантов выбора немного — 2–5.

Если названия вариантов короткие, вместо группы радиокнопок можно использовать переключатель, так форма будет выглядеть компактнее:

Если значений 5–25, используйте раскрывающийся список.

Если 25–50, то комбобокс со списком, а если больше 50, то без списка.

Описание работы

Клик по названию или по самой радиокнопке приводит к ее выбору. Повторное нажатие не снимает выбор.

В группе радиокнопок только один пункт может быть выбран. Группа радиокнопок не может состоять из 1 пункта.

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

Выбранный по умолчанию пункт ставьте первым в списке:

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

Название группы

Название группы радиокнопок пишут с заглавной буквы и формулируют так, чтобы:

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

Название радиокнопки

Название радиокнопки пишется с заглавной буквы, и отвечает на вопрос «Как?» или «Какой?».

Если пользователю может быть не очевидно, что произойдет при выборе, объясните это дополнительным текстом или картинкой:

Расположение

Радиокнопки располагают в строку, только если их 2 штуки. Если больше — только в столбец. Не располагайте радиокнопки из одной группы в несколько столбцов. Группы радиокнопок смешиваются, и непонятно, к какой группе относится конкретная радиокнопка:

Работа с клавиатурой

При переходе к группе радиокнопок клавишей Tab , выбранное значение получает фокус — появляется чёрная рамка:

Если до получения фокуса ни одно значение не выбрано, фокус получает первая кнопка в списке.

Рамка фокуса появляется только при переходе табом с клавиатуры. При клике мышью рамка не появляется.

Если радиокнопки располагаются вертикально, переключение фокуса производится клавишами ↓ ↑ , если горизонтально — клавишами ← → :

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

Следующее нажатие клавиши Tab переводит фокус на следющий контрол.

Валидация

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

Если заголовок группы находится слева, текст валидации располагайте под группой радиокнопок.

Если заголовок группы находится над группой радиокнопок, текст ошибки располагайте сразу под заголовком группы:

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

Если заголовок сверху, выводите тултип справа.

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

Дизайн

Выбранная радиокнопка обозначается символом из&nbspшрифта Kontur&nbspIconic .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *