Что такое чек лист и тест кейс
Как составить Чек-лист? Для начинающего тестировщика.
Все очень часто слышат про Тест-кейсы и как их оформлять, но не так много времени уделяется Чек-листам, что это такое? Зачем это нужно? И как с этим жить?
Начнем с того, что назначения у тест-кейсов и чек-листов одинаковое, это проверка продукта. Однако есть два основных отличия:
1 Чек-лист описывает кратко, что нам нужно протестировать и результат, Тест-кейс наоборот старается более детально рассказать о тестировании данного функционала.
2 Объем проверяемого функционала, за короткий промежуток, мы можем быстрее проверить продукт, чем Тест-кейсами.
Название функционала, отдельного элемента продукта (Например: Поле поиска)
3 Краткое описание теста
Буквально небольшое описание действия или пункта.
Например: Ввести пароль латиницей
Я выделил основные 3 пункта, можно добавить еще увеличить уровень подзаголовков, для полного удобства и понимания архитектуры проекта, но это уже зависит от вас и вашего объекта тестирования.
Пример Чек листа в XLSX формате
Давайте вместе взглянем на сайт lensgo.ru
И попробуем составить чек-лист с помощью Excel.
Закиньте что-нибудь в корзину и перейдите в нее, а далее к оформлению товара.
У вас должна отобразится страница по адресу https://lensgo.ru/basket/order/
Писать Чек-лист мы будем по форме “Данные о покупателе”
1 Напишем в шапке Чек-листа, Название и описание.
Чтобы другие тестировщики и ты сам смог быстро понять о чем этот Чек-лист.
2 Далее по каждому полю составляем краткий список проверок, результатов и еще проставляем приоритет. Каждая проверка проверяет один пункт, но может проверять и комбинации нескольких пунктов. Составлять список проверок нужно с помощью техник тест-дизайна, без них может получится огромный список тестов:
1 Граничные значения
2 Классы эквивалентности
можно прочитать про это в этих статьях:
Возьмем поле ФИО и составим группы проверок, а в них уже напишем списки проверок с помощью техник тест-дизайна. Немного подумав вычисляем, что можно создать три группы ( Проверка длины поля, Проверка поля на кириллице “ФИО”, Проверка поля на английском “ФИО”) учитываем также, что интернет-магазин ориентирован на Россию.
Вот загруженный пример, но попробуйте без скаченного примера составить проверки для поля “Телефон” и потом сравнить ваши тесты с моими.
Пример Чек листа в Sitechco
Есть огромное количество онлайн сервисов для составления чек-листов, но один из наиболее подходящий для тестировщиков это sitechco.ru
Где вы удобно можете расположить свои проверки, радует еще то, что интерфейс интуитивно понятен и можно быстро редактировать тесты. Еще имеется запуск тестов, отчеты по их прохождению и тест планы, все это очень облегчит вам жизнь при тестировании проекта.
И так вы узнали как можно составить чек-листы для тестирования вашего продукта, надеюсь, что моя статья вам помогла.
Основы тестирования. Тест-кейсы и чек-листы
Тестирование — это процесс, который нуждается в документировании. Думаю, что даже противники бумажной волокиты не будут отрицать, что описанный план проверки значительно упрощает процесс тестирования и экономит в последующем кучу времени.
Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.
Тест-кейсы и чек-листы относятся к документации тестирования. Их задача — систематизировать и упростить процесс тестирования, сделать его более прозрачным и структурированным. А еще их использование может очень сильно экономить время.
Тест-кейс
Тестовый случай, тестовый сценарий (test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Иными словами, это артефакт или документ, который описывает наши тесты. Говорит, как их выполнить, при каких условиях и что должно получиться после выполнения тех шагов, которые заложены в тест-кейсе, то есть каков ожидаемый результат.
Тест-кейс имеет определенный шаблон, разработанный для того, чтобы стандартизировать и упростить создание и дальнейшее чтение тест-кейсов. Шаблон условно стандартизированный, потому что может меняться в зависимости от компаний и процессов.
2. Краткое описание тест-кейса (Name).
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны.
Если мы сделаем название только коротким, то в таких кейсах будет очень сложно ориентироваться.
Например, мы проверяем регистрацию и называем тест-кейс: “Проверить успешную регистрацию”. Вроде логично, но такое название включает в себя проверку регистрации по нескольким полям. И получается, что название не информативно.
Если делать название тест-кейса слишком длинным, то его будет очень сложно читать, например: “Проверить правильную регистрацию, когда вводим логин латинскими буквами без цифр и пробелов с паролем из цифр”.
Такое название неудобно читать. Плюс некоторые инструменты хранения тест-кейсов могут обрезать длинные названия.
Что делать? Немного сократить название, убрать “Проверить” и слова, которые не несут важного смысла и получим следующее: “Регистрация с латинским логином”, “Регистрация с логином из цифр” и так далее.
3. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.
4. Автор тест-кейсы (Author) — тестировщик, который написал тест-кейс.
5. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять.
6. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс.
7. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу.
8. Шаги (steps) — точная последовательно действий для выполнения проверки.
Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект. Скажу даже больше: иногда вы сами спустя какое-то время с трудом разбираете, что имели ввиду написав тот или иной шаг.
9. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов.
10. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.
Тест-кейс для авторизации на сайте
Рассмотрим составление тест-кейса на примере тестирования формы авторизации на сайте. Предположим, что нам необходимо проверить Авторизацию существующего пользователя:
1.ID
Пусть будет №1, так как это наш первый тест-кейс
2. Краткое описание тест-кейса (Name)
Авторизация существующего пользователя.
Если бы нам на выбор было предложено несколько способов регистрации (Телефон, E-mail, ВКонтакте, Фейсбук и т.п.), то название могла бы выглядеть вот так “Авторизация существующего пользователя через ВКонтакте”.
3. Ссылка на требования
В нашем случае требований нет. Значит поле оставляем пустым
4. Автор тест-кейсы (Author)
Иванов И.
5. Приоритет (Priority)
Высокий, так как функциональность важная. В двух словах, чем важнее объект тестирования и проверки, тем выше приоритет.
6. Название/модуль/версия продукта (Component/Version)
Кейс относится напрямую к авторизации, следовательно этот модуль и укажем.
7. Предварительные условия (pre-condition)
Во-первых, нужно зайти на сайт по адресу https://msk.farfor.ru. Во-вторых, пользователь должен существовать и быть не залогинен.
8. Шаги (steps)
1) Вводим в поле телефона “+7 900 000-00-00”,
2) Вводим в поле password пароль “123”,
3) Нажимаем кнопку “Вход”.
9. Ожидаемый результат (expected result)
Авторизация прошла успешна, пользователь остался на странице https://msk.farfor.ru
10. Приложения (attachments)
В этот раз файлы нам не нужны, поэтому обойдемся без них.
Для наглядности соберем все это в таблицу.
Обратите внимание, что все тестовые данные, такие как почта или пароль лучше указывать явно, так как это убережет вас от лишних действий и поиска того, каким должен быть правильный аккаунт.
В рассмотренном примере все шаги приводят к одному результату. Но также есть ситуации, когда на каждый шаг будет свой ожидаемый результат.
Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.
Теперь давайте немного поговорим о чек-листах в тестировании.
Чек-лист
Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта.
Можно сказать, что чек-лист — это упрощенный тест-кейс без шагов и прочего описания. Просто список того, что необходимо проверить. Более того, иногда список тест-кейсов является своего рода чек-листом, если смотреть просто на названия тест-кейсов. Например, чек лист «Авторизация пользователя» может выглядеть следующим образом:
1. Авторизация пользователя через E-mail
2. Авторизация пользователя через ВКонтакте
3. Авторизация пользователя с пустым E-mail
4. Авторизация пользователя с неверным паролем и так далее
Чек-лист экономит время тестировщика и упрощает поддержку тестовой документации, но, с другой стороны, многие вещи при проверки остаются на совести тестировщика. Например, какой е-mail вводим, какой неправильный пароль и так далее
Следовательно, если с чек-листом работают уже опытные тестировщики, то особых проблем не возникает. Если приходят новички и видят чек-листы, то они могут запутаться и неправильно проверить функциональность, потому что не будут с точностью знать, как правильно протестировать и какие данные вводить.
Как видите, чек-листы и тест-кейсы сильно упрощают процесс тестирования. Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.
При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить. Достаточно один раз уделить немного больше времени на проверку и написать по ней тест-кейсы и чек-листы, чтобы потом экономить время при следующих проверках.
понедельник, 13 июля 2015 г.
Тест-кейс VS чек-лист в картинках.
Чем же они различаются?
Но моим студентам все равно тяжело. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?
Идея 1
Я предложила им такое пояснение:
Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, «Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом. «, а не просто «Ну вот загрузили и все получилось«.
Ну а чек-листы — это когда не нужны все эти подробности, как именно мы загружаем файлы, на какие кнопочки нажимаем. Нужна просто напоминалка — «Проверить загрузку Excel, CSV, JPG. »
Идея 2
Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.
А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!
Но разница «Простая инструкция — инструкция из ИКЕА» === «Чек-листы — Тест-кейсы». Когда будете писать тест-кейс, помните об этом и о том, что очевидное вам — темный лес для кого-то другого.
PS — блог-пост добавлен на Testbase в раздел «Теория в картинках», где вы всегда его сможете найти! 🙂
Структура, содержание и процесс написания проверок
Фундаментальной базы по тестированию много: есть информация, что такое проверки и какие они бывают, когда лучше использовать чек-листы, когда тест-кейсы, а когда не обойтись без обоих видов. Но всё это не отвечает на вопрос: как писать правильно, чтобы извлечь из проверок максимум пользы?
Меня зовут Мария Лещинская, я 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, с/без кэша, без интернета
Навигация: Закрытие экрана / Возврат назад на предыдущий экран
Фича. Экран — закрытие
Фича. Экран — назад на предыдущий экран
→ Обратная связь. Экран обратной связи — закрытие
→ Обратная связь. Шторка списка тем — закрытие
→ Оплата. Попап Комиссия — закрытие
→ Обратная связь. Экран обратной связи — назад на на предыдущий экран
Если запроса нет, достаточно одной проверки по закрытию экрана. Если запрос используется, лучше создать три разных проверки:
Фича. Название экрана — закрытие
Фича. Название экрана — закрытие, ошибка на запрос
Фича. Название экрана — закрытие, без интернета
Фича. Название экрана — назад на предыдущий экран
Фича. Название экрана — назад на предыдущий экран, ошибка на запрос
Фича. Название экрана — назад на предыдущий экран, без интернета
Со следующими шагами:
Назад по кнопке, если есть
Физическая кнопка «Назад» на Android
→ Логика взаимодействия между экранами в стеке и МП
Такая логика может быть описана в возврате (предыдущий пункт)
Фича — логика работы в стеке экранов
→ Обратная связь — логика работы в стеке экранов
Сохранение данных в стеке экранов одной фичи — если предусмотрено / Очистка данных при переходе и возврате на экраны — если сохранение не предусмотрено
Сворачивание приложения во время флоу — сохранение положения МП
→ Компоновка
Фича. Экран/шторка/tup фичи — компоновка
(: заполненное состояние, error state, empty state, состояние без интернета (если для этого специфичный экран))
→ Обратная связь. Экран обратной связи — компоновка
→ Обратная связь. Экран обратной связи. Еrror State — компоновка
→ Обратная связь. Экран обратной связи. Empty State — компоновка
→ Обратная связь. Экран обратной связи. Без интернета — компоновка (если отличается от Error State — компоновка)
→ Обратная связь. Шторка списка тем — компоновка
→ Обратная связь. TUP успеха — компоновка
Описание элементов: их наименования + дизайн (скриншот, ссылка на фигму). Если это кнопка, то здесь же проверяется её пресс-стейт
Элемент (поле, карусель, чек-бокс, радиобаттон и тп)
→ Позитивные проверки
Фича. Элемент — позитивные проверки (: если фича одноэкранная)
Фича. Экран/шторка/TUP. Элемент — позитивные проверки (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)
→ Cписок товаров. Фильтр. Поле дата — позитивные проверки
→ Перенос средств. Экран выбора услуг. Поле сумма — позитивные проверки
→ Настройки. Радиобаттон выбора темы — позитивные проверки
→ Обратная связь. Чек-бокс согласия на обработку данных — позитивные проверки
Заполнение поля корректными значениями
Вставка в поле корректных значений
Для текстового поля без ограничений вставка или заполнение поля смайликами — позитивная проверка: она очевидно возможная.
Для поля ввода суммы с цифровой клавиатурой вставка смайликов — негативная проверка: она очевидно неожиданная для текущей логики поля.
Ограничение на размер поля
Техника классов эквивалентности и граничных значений (позитивные проверки)
Заполнение поля максимально возможной длиной, если длина большая и текст может зайти на границу экрана (проверка на корректное расширение/скролл поля и отображение в нём значения)
Пустое поле (если заполнять его необязательно)
→ Негативные проверки
Фича. Элемент — негативные проверки (: если фича одноэкранная)
Фича. Экран. Элемент — негативные проверки (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)
→ Cписок товаров. Фильтр. Поле дата — негативные проверки
→ Перенос средств. Экран выбора услуг. Поле сумма — негативные проверки
→ Настройки. Радиобаттон выбор темы — негативные проверки
→ Обратная связь. Чек-бокс согласия на обработку данных — негативные проверки
Заполнение поля некорректными значениями
Не стоит забывать о проверке на подскролл к невалидным полям, если:
Есть нескольких полей или различных элементов на одном экране, которые потенциально могут не помещаться для отображения с ошибкой при неуспехе ввода значения
Эти поля или элементы валидируются по кнопке
Вставка в поле некорректных значений
Ограничение на размер поля
Техника классов эквивалентности и граничных значений
Пустое поле (если заполнять его обязательно)
→ Логика работы элемента
Фича. Элемент — логика работы (: если фича одноэкранная)
Фича. Экран. Элемент — логика работы (: если фича многоэкранная и элементы встречаются несколько раз на разных экранах)
→ Cписок товаров. Фильтр. Поле дата — логика работы
→ Перенос средств. Поле сумма — логика работы
→ Настройки. Радиобаттон выбор темы — логика работы
→ Обратная связь. Чек-бокса согласия на обработку данных — логика работы
Общие действия с элементом и его реакция на них
→ Открытие определенного вида клавиатуры при активации поля
→ Расширение поля при заполнении
→ Выставление курсора в конец заполненной строки при активации поля
→ Валидация поля при снятии фокуса
→ Валидация поля при нажатии кнопки
→ Маска (для номера телефона, например)
→ Корректная активация/деактивация чек-бокса/радиобаттона
→ Зацикленная карусель / Незацикленная карусель
→ Точки входа в тестируемую фичу
→ Обратная связь — точки входа
Указываются проверки покрывающие все места, откуда можно попасть к тестируемой фиче с других экранов
→ Взаимодействие текущей тестируемой фичи с другими
Фича. Взаимодействие с другими фичами — другая фича
→ Обратная связь. Взаимодействие фичи с другими фичами — темная тема
→ Темная тема (если поддерживается)
Смена темы и работа с тестируемой фичей
→ Пуш-уведомления + диплинки (если поддерживаются)
Переход по диплинку во флоу тестируемой фичи
→ Планшет (если поддерживается)
Компоновка, режим сплит-вью (если поддерживается)
Готовые чек-листы
→ Обязательный чек-лист проверок
Добавляется в каждый прогон по фиче и регресс-прогон. Он может быть расширен индивидуально на проекте.
Изменение размера шрифтов из настроек устройства
Смена темы из настроек устройства
Изменение языка из настроек устройства
Смена времени из настроек устройства
Использование кастомной клавиатуры Android (в частности, для полей и поисковой строки)
Входящий звонок/смс во время прохождения флоу фичи
Выход из приложения двойным «Назад» на Android
Свернуть приложение и запустить снова
Свернуть приложение во время ожидания ответа на запрос
Отключить интернет во время ожидания ответа на запрос
→ Дополнительный чек-лист проверок
Добавляется в каждый итоговый прогон. Он может быть расширен индивидуально на проекте.
Запустить приложение без доступа к интернету вообще
Нажатие кнопки блокирования при отображении сплеша
Запуск и сразу же сворачивание приложения
Сворачивание приложения во время отображения системного окна оплаты Apple/Google/Samsung/Huawei Pay
Отображение на планшетах (в режиме совместимости, если нет поддержки планшетов)
Автоподстановка кода из смс (иногда идет по-умолчанию в iOS проектах)
Работа приложения при пуш-уведомлении другого стороннего приложения (сообщение ВКонтакте, Twitter и так далее)
Работа приложения после срабатывания будильника/таймера/смс/другого системного приложения
Работа открытого приложения после разблокировки приложения
Работа свернутого приложения после разблокировки приложения
Работа приложения при сообщении о нехватке заряда
Работа приложения при зарядке
Работа приложения после отключения от зарядки
Работа приложения при воспроизведении музыки
Работа приложения с мобильным интернетом 3G/4G/слабым интернет-соединением
Работа с фичей «картинка в картинке» (если поддерживается)
Что даёт структура проверок
возможность обеспечить необходимое покрытие,
возможность быстрой модификации.
Один из существенных дополнительных плюсов — использование этого подхода в автотестировании. Например, это мастхэв при работе с Flutter внутри widget-тестов. Каждый элемент во Flutter — это виджет (будь то эĸран или элемент): виджет-тесты отлично маппятся с нашими проверками, которые детально покрывают ĸаждый элемент или эĸран.
В статье описаны только компонентные проверки — по каждому элементу. Они пригодятся в начале тестирования: такая структура покрывает больше элементов, обеспечивает уверенность в качестве продукта.
Когда QA работает с sanity или smoke тестированием, нет смысла тратить время на детальную проверку каждого элемента. Нужны сценарные проверки, которые покроют целиком путь пользователя. О том, как работать со сценарными проверками, поговорим в следующей статье.
А как вы решаете вопрос с организацией проверок? Придерживаетесь хаотичного или системного подхода? Поделитесь в комментариях!