Проверка по чек листу что это
Зачем нужны проверочные листы и какую пользу они могут принести компании
Чек-лист — инструмент для проверки деятельности коммерческих объектов на предмет их соответствия сетевым стандартам. Представляет собой список, каждый пункт которого содержит лишь один критерий, действие или состояние — таким образом, двоякое истолкование результатов исключено.
В любом из направлений коммерческой деятельности использование проверочных листов поможет повысить эффективность бизнеса, сделать его более прибыльным и конкурентным. Их применяют для аудита крупных торговых центров и небольших магазинов, салонов красоты и спортивных комплексов, АЗС и СТО, заведений общественного питания и не только.
Последовательный план действий
Контролирующий сотрудник точно ничего не пропустит — он проводит проверку в соответствии с заданным алгоритмом.
Сокращение сроков проверки, качественное выполнение работы с первого раза — без ошибок.
Данные хранятся в электронном формате. Их можно сравнивать с результатами предыдущих проверок, а также проверок, проведенных на других точках.
Сегодня на смену бумажным чек-листам пришли электронные — существенно упрощен анализ результатов, повышена достоверность данных, сокращено время обмена информацией между подразделениями бизнес-структур.
Задачи чек-листа
Давайте обсудим перспективы использования чек-листов для увеличения прибыли и эффективности коммерческих компаний. Основные направления:
Возможности современных онлайн-сервисов по составлению и обработке чек-листов позволяют адаптировать их под любое коммерческое направление: начиная от проверки розничных магазинов и заканчивая предоставлением медицинских услуг. Форму проверочного листа можно дополнять вопросами (пунктами проверки) и редактировать в соответствии со спецификой бизнеса.
Пример
Давайте оценим, насколько полезным может быть базовый чек-лист проверки магазина. Если здание имеет презентабельный, ухоженный вид, везде убрано, а сотрудники опрятные, со вкусом одеты и производят приятное впечатление, вероятность, что клиент его посетит, гораздо выше. Грязный фасад с потеками на стенах и мусором у крыльца отталкивает – прохожие ускоряют шаг, чтобы скорее очутиться в зоне комфорта. А значит, магазин теряет не просто посетителей, он теряет доход!
Выше мы привели утрированный пример. На самом деле причиной отказа от посещения может стать неопрятная прическа кассира или запах плесени в торговом зале. Именно чек-лист помогает эффективнее бороться с подобными недостатками – менеджеры часто не замечают их в поисках более серьезных нарушений.
Проверкой торговых точек обычно занимаются руководители среднего звена, реже – сотрудники магазинов. Лучше всего, если составлением проверочного листа занимается руководитель или его заместитель, то есть человек, который в совершенстве разбирается в бизнесе и способен учесть абсолютно все. Это работает примерно так:
Подготовка проверочного листа.
Запуск проверки с заданной периодичностью – раз в неделю, месяц или квартал.
Планировка задач по устранению обнаруженных недостатков. В сервисе Chek Office это происходит автоматически.
В стандартном варианте сотрудники распечатывают чек-лист, делают в нем пометки, после чего вручную составляют план «работы над ошибками». С помощью Chek Office все проходит гораздо проще и быстрее: проверочный лист – в электронном формате, все данные вносятся прямо с планшета (смартфона), результаты отчета направляются руководству в режиме реального времени.
В нашем примере проверка магазина начинается с прилегающей территории. Сотрудник оценивает:
Внешний вид магазина.
Функциональность вывески – корректная работа подсветки, наличие и целостность всех элементов.
Степень заполнения урны.
Отсутствие несанкционированно размещенной рекламы.
Отсутствие наледи или других препятствий для посещения заведения.
Это первый блок чек-листа. После его заполнения проверяющий сотрудник переходит к оценке состояния входной группы:
стекла и витражные вставки, декоративные элементы (если они есть);
режим работы магазина – наличие, оформление в соответствии с корпоративным стилем;
состояние грязеудерживающего коврика;
Далее последует проверка состояния торгового зала: чистота пола и стен, отсутствие неприятного запаха, достаточность освещения и прочие характеристики, ведь лояльность покупателя зависит не только от внешнего состояния магазина, но и от того, насколько ему комфортно находиться внутри. Ну и, конечно, важнейшей составляющей является главное лицо магазина – продавец-консультант: его внешний вид, прическа, запах, улыбка и то, как он работает с клиентом. Но это уже другой чек-лист, назовем его «Проверка работы продавца с клиентом», об этом мы расскажем в следующих статьях.
Образец чек-листа — проверяющий лишь выбирает нужный ответ, добавляет фото и комментарий:
Выгода от внедрения чек-листов
В России так сложилось, что за ошибки сотрудников обычно расплачивается компания. Из ее бюджета клиент получает компенсацию за просроченный товар, организация тратит деньги, чтобы замять скандал из-за недостойного поведения работника или в случае причинения ущерба здоровью. Ключевое преимущество проверочных листов — сведение таких ошибок к минимуму. Основные выгоды от внедрения Чек-листов:
· Сокращение времени на подготовку сотрудников. Специалист видит задачи в определенной последовательности и выполняет их в соответствии с планом.
· Повышение эффективности труда — меньше ошибок, выше продуктивность работы.
· Соблюдение мер безопасности — снижение рисков для жизни и здоровья сотрудников, а значит, не придется платить компенсацию, к примеру, за полученные увечья.
· Соответствие стандартам и нормам — успешное прохождение любых инспекций и проверок со стороны надзорных органов.
· Довольные клиенты, как результат — увеличение прибыли, улучшение имиджа заведения.
Checklist помогает оперативно выявлять уязвимости компании и быстро их ликвидировать, улучшать сервис и обходить конкурентов.
Что дает использование сервиса
Все привыкли к бумажным чек-листам, но это уже даже не вчерашний, а позавчерашний день. Было бы глупо вручную тратить несколько часов на обработку огромных массивов информации, когда с помощью приложения это можно сделать за несколько минут. Преимущества онлайн-сервиса:
· Экономия времени: анализ статистики, планирование проверок и задач, а также многие другие операции и действия автоматизированы.
· Мгновенная фиксация недостатков – не надо куда-то загружать фото, перекидывать их или совершать иные действия, они поступают в сервис непосредственно с камеры планшета или смартфона.
· Моментальные отчеты. Автоматическое формирование, представление информации в виде таблиц, диаграмм, графиков.
· Гарантия достоверности данных: «живые» фото загружаются непосредственно с камеры смартфона — их нельзя подделать или отредактировать.
· Удобный, максимально информативный отчет – данные представлены наглядно, недостатки не надо выискивать – они заметны с первого взгляда.
· Постановка задач сотрудникам и контроль их состояния.
· Оцифровка данных проверки — реализована путем выставления оценок в баллах непосредственно в планшете или смартфоне, данные сразу же становятся доступными ответственным сотрудникам.
Внедрение проверочных листов избавляет сотрудников от рутинной работы, в результате выше достоверность полученной информации, меньше вероятность ошибок, проще выявить уязвимые места и недостатки.
Что такое хороший чек-лист и как его составить
Работа, дом, кружок по фото — правильный чек-лист поможет разложить всё по полочкам. А мы разложим по полочкам, что он из себя представляет.
А я уже слышал про чек-листы. Это ведь
что-то вроде списка дел?
Почти. Дословно «чек-лист» переводится как «проверочный/контрольный список». Стандартно это перечень пунктов, напротив которых ставятся галочки — когда тот или иной будет выполнен. Так легко отследить, что и в каком объёме осталось сделать.
Сначала чек-листы использовались только в технических отраслях, чтобы проверить выполнение сложных задач — например, готовность самолёта к взлёту. Сейчас этот простой и удобный инструмент проник буквально во все сферы жизни. В интернете можно найти чек-лист хорошего сайта, настройки таргета или подготовки к свадьбе. Но чек-листами всё-таки нельзя назвать запись из ежедневника или пошаговый план по захвату мира.
Автор статей по SMM и копирайтингу. Чуть не стала кинокритиком, но решила перейти на сторону маркетинга. Учится на медиапродюсера и отлично понимает, как выглядит digital в глазах начинающего.
Тогда я не понимаю. Чем они отличаются?
Пошаговый план — это инструкция. В этом формате важен порядок действий: одно должно в точности следовать за другим. В чек-листе последовательность не имеет значения, главное — выполнить все пункты (или, по крайней мере, большинство).
От записи в ежедневнике чек-лист отличается универсальностью. Он не требует постоянных обновлений или дополнений, так как создаётся для проверок повторяющихся процессов. А планы на день могут меняться от раза к разу. Но вот список полезной рутины или ежедневных обязанностей уже можно превратить в чек-лист. Например, сделать трекер привычек.
Трекер? То есть бывают разные виды чек-листов?
Да, хотя различия незначительные.
Трекеры — инструменты для внедрения полезных привычек или избавления от вредных. Они позволяют отслеживать, насколько регулярно выполняются одни и те же действия на протяжении длительного времени. Например, если мы хотим ежедневно «выпивать 1,5 литра воды» или «читать книги в течение 30 минут минимум».
Есть чек-листы из разряда «не забыть», или памятки. Список покупок в магазине — типичная памятка.
Некоторые списки работают по принципу «прочитай — сделай». Например, это может быть чек-лист по составлению резюме. Пункты там больше похожи на советы, а цель такого списка — рассказать читателю о возможных способах и лайфхаках.
Ещё один вариант — чек-листы «прочитай — соотнеси с собой». Обычно это списки признаков, по которым можно определить то или иное явление. Например, распознать манипулятора или заметить надвигающуюся депрессию.
Отдельно стоит выделить развлекательные чек-листы. Они несут не практическую или информационную ценность, а скорее удовольствие от чтения и проставления галочек (часто мысленного). К ним можно отнести списки различных идей: от «осенних дел» и новых сериалов до шутливого чек-листа студента.
Даже популярные буллшит-бинго можно приписать к чек-листам. У них другая форма, но тот же принцип: услышал фразу — ставишь галочку.
А если я не найду нужный чек-лист и захочу свой? Придётся обращаться к особому специалисту?
Вовсе нет — создавать чек-листы может кто угодно. Можно составить памятку в обычном Word и даже от руки нарисовать трекер привычек. Главное, чтобы чек-лист эффективно применялся на практике, а для этого автор должен достаточно хорошо разбираться в теме.
Однако оформление — тоже важная часть. Работать с красивым документом гораздо приятнее, грамотный дизайн помогает быстрее сориентироваться. Но необязательно нанимать дизайнера, — есть бесплатные конструкторы, например:
Я часто вижу чек-листы у брендов и блогеров. Зачем все их создают и предлагают, если можно сделать самому?
Чек-лист удобен не только как прикладной инструмент проверки каких-либо процессов, но и как инфопродукт. Он достаточно быстро создаётся, красиво выглядит, легко распространяется. Такой формат контента привлекает аудиторию не хуже, чем подборка или инструкция.
К тому же, в отличие от статьи в блоге или поста в соцсети, чек-лист легко «отдать» пользователю в виде файла, а за его скачивание попросить контакты (то есть использовать чек-лист как лид-магнит). Когда пользователь сообщит свою почту и/или телефон, ему можно отправлять рассылки с выгодными предложениями, персональными скидками, подробными рассказами о продуктах компании. И тем самым подталкивать к покупке.
Иногда чек-лист идёт как дополнение, когда человек уже выполнил целевое действие: например, сделал заказ или зарегистрировался. Тогда он не основная мотивация клиента, а приятный бонус.
А развлекательные чек-листы хороши в соцсетях: могут стимулировать сохранения и шеры, становиться вирусными.
Теперь всё понятно. А чек-лист по составлению чек-листа будет? 🙂
Конечно! Итак, если вы составляете свой чек-лист, то убедитесь, что:
Шуточная разновидность игры в бинго. Это одна картинка, разделённая на несколько квадратных полей, в каждом — расхожая для определённых ситуаций или групп людей фраза. Игра высмеивает шаблонность и однотипность.
Облачная SaaS-платформа РИТЕЙЛИКА. Блог компании.
Эффективный чек-лист проверок, инспекций и аудитов в торговле. Использование электронных чек-листов на примере сервиса РИТЕЙЛИКА.
Например, при проверках соблюдения стандартов мерчендайзинга, в чек-листе как правило прописывается проведение следующих мероприятий:
Чек-лист проверки магазина
При проведении проверок и торговых аудитов магазинов, стандартный чек-лист обычно разбивается на категории (зоны) проверки и критерии (области) проверки. В случае проверки магазина (супермаркета, гипермаркета), чек-лист может быть сформирован по следующим категориям:
Внутри каждой категории (зоны) чек-листа должен располагаться перечень критериев (областей) проверки. Критериев может быть любое количество, начиная от нескольких, заканчивая десятками и даже в отдельных случаях – сотнями. К примеру, в категорию «прилегающая территория и входная зона» могут входить следующие критерии:
Чек-лист проверки продавца
В качестве объекта проверки может выступать не только магазин, но и определенный сотрудник (менеджер, продавец). В этом случае, по чек-листу оценивается работа сотрудника, его внешний вид, знание корпоративных стандартов, умение играть «в ролевую игру» с потенциальными покупателями, выводя их на совершение покупки и допродажу. К примеру, подобным образом может выглядеть чек-лист для оценки работы продавца в магазине или салоне:
Категория: внешний вид
Категория: первичный контакт
Категория: выявление потребностей
Категория: презентация товара
Категория: допродажа сопутствующих товаров
Категория: отработка возражений
Категория: выход на сделку
Бумажный или электронный чек-лист?
В самом простом варианте чек-лист может составляться в таблицах Word или Excel и распечатываться, либо сразу записываться на бумажный носитель. Однако данный вариант использования чек-листов морально устарел, и с развитием современных мобильных технологий уходит в прошлое. Кроме того, информация на бумаге часто теряется, случайно уничтожается и имеет нехорошую тенденцию «оседать в столах», не позволяя накапливать исторические данные с целью сравнительного анализа, оценки динамики и эффективности проверок за разные периоды времени.
Именно по этой причине, многие компании уходят от чек-листов на бумажных носителях, переключаясь на использование электронных чек-листов в специальных облачных сервисах, где работа с чек-листами осуществляется на мобильных устройствах через мобильное приложение. Преимущество таких сервисов состоит не только в более удобном и быстром сборе данных, включая фотографии, но и в предоставлении руководителю отчетности и аналитики, которая в динамике покажет эффективность проведения проверок, инспекций и аудитов, позволит выявить самых «злостных нарушителей», аутсайдеров и самые «проблемные зоны». Одним из лидеров среди таких решений является сервис Ритейлика.
Облачный сервис Ритейлика представляет собой единое, централизованное хранилище данных по проверкам и состоит из веб-сайта и мобильного приложения. В сервисе, помимо стандартных справочников, имеется мощный конструктор чек-листов, позволяющий легко создавать неограниченное количество чек-листов любой сложности и любого размера для разных типов оценок (да/нет, баллы, выбор из списка, числовая/количественная оценка).
Также имеются развитые механизмы создания, планирования и распределения проверок по проверяющим (аудиторам, инспекторам). Сервис позволяет не только осуществлять внутренние, перекрестные и внеплановые проверки силами собственного отдела контроля качества, но и привлекать к этому сторонние агентства и тайных покупателей (mystery shopping), организуя их совместную работу в едином информационном пространстве вместе с остальными подразделениями и службами компании.
Проверяющий (инспектор) выполняет проверку по электронному чек-листу на своем мобильном устройстве, фиксируя нарушения, выставляя по каждому критерию оценки и прикладывая сопутствующие фотографии со своими комментариями. После завершения, проверка может быть передана дальше по цепочке для подписания ответственным лицом (директором магазина), устранения замечаний, создания претензий сервисным службам и передачи куратору.
Внутри проводимой проверки, в каждом критерии чек-листа, участники цепочки в зависимости от своих ролей и прав могут добавлять собственные комментарии, указывать способы и сроки устранения нарушений, объяснять причины их возникновения, формировать претензии сервисным службам и т.д., тем самым формируя некий «чат», который наглядно демонстрирует весь расклад и сопутствующую реакцию вовлеченных в данную проверку лиц и подразделений. Вся собранная в результате проверки информация быстро становится доступна руководителю и прочим ответственным лицам в отчетах на веб-сайте и уведомлениях, присылаемых на электронную почту вовлеченным в проверку лицам.
Конструктор чек-листов в Ритейлике позволяет создавать чек-листы, задающие маршрут движения проверяющего по инспектируемому объекту таким образом, чтобы не посещать одну и ту же зону проверки несколько раз. Это делается специально для того, чтобы проверяющий выполнял работу по чек-листу в «один заход», не возвращаясь повторно в уже проверенные места и зоны. Организация маршрутов в чек-листе позволяет существенно сократить общее время выполнения проверки, упорядочить, упростить работу проверяющего и увеличить общее количество проверяемых критериев (позиций).
Для оценки качества работ по мерчендайзингу, в чек-лист необходимо на периодической основе добавлять товарные позиции, подлежащие тем или иным проверкам (наличие товара, сроки годности, ценники, промоакции и т.д.). Каждый раз вручную делать это долго и неэффективно, поэтому в сервисе предусмотрены механизмы интеграции с учетной системой заказчика. Учетная система периодически выгружает перечень товаров, подлежащих проверкам, сервис в свою очередь автоматически подгружает данные товары в электронный чек-лист при создании проверки, учитывая при этом ситуацию, когда в разных магазинах (филиалах) будет проверяться «свой» перечень товаров, отличающийся от перечня товаров для другого магазина.
Накопленный опыт разработчиков сервиса Ритейлика по автоматизации проведения проверок и торговых аудитов в крупных торговых сетях, позволяет сделать вывод, что использование чек-листов без привязки к специализированным программным решениям малоэффективно и дает небольшую отдачу. Будущее остается за электронными чек-листами и специализированными решениями, аккумулирующими в себе полученные данные и дающие руководителям требуемую отчетность в любых разрезах по эффективности работы филиалов, торговых точек и других подразделений. Ведь чем меньше в компании допускается нарушений и отклонений от принятых стандартов, тем выше будет лояльность клиентов и тем ниже будет вероятность получения драконовских штрафов от надзорных органов.
Структура, содержание и процесс написания проверок
Фундаментальной базы по тестированию много: есть информация, что такое проверки и какие они бывают, когда лучше использовать чек-листы, когда тест-кейсы, а когда не обойтись без обоих видов. Но всё это не отвечает на вопрос: как писать правильно, чтобы извлечь из проверок максимум пользы?
Меня зовут Мария Лещинская, я 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 тестированием, нет смысла тратить время на детальную проверку каждого элемента. Нужны сценарные проверки, которые покроют целиком путь пользователя. О том, как работать со сценарными проверками, поговорим в следующей статье.
А как вы решаете вопрос с организацией проверок? Придерживаетесь хаотичного или системного подхода? Поделитесь в комментариях!