для чего нужен чек лист в тестировании
Как составить Чек-лист? Для начинающего тестировщика.
Все очень часто слышат про Тест-кейсы и как их оформлять, но не так много времени уделяется Чек-листам, что это такое? Зачем это нужно? И как с этим жить?
Начнем с того, что назначения у тест-кейсов и чек-листов одинаковое, это проверка продукта. Однако есть два основных отличия:
1 Чек-лист описывает кратко, что нам нужно протестировать и результат, Тест-кейс наоборот старается более детально рассказать о тестировании данного функционала.
2 Объем проверяемого функционала, за короткий промежуток, мы можем быстрее проверить продукт, чем Тест-кейсами.
Название функционала, отдельного элемента продукта (Например: Поле поиска)
3 Краткое описание теста
Буквально небольшое описание действия или пункта.
Например: Ввести пароль латиницей
Я выделил основные 3 пункта, можно добавить еще увеличить уровень подзаголовков, для полного удобства и понимания архитектуры проекта, но это уже зависит от вас и вашего объекта тестирования.
Пример Чек листа в XLSX формате
Давайте вместе взглянем на сайт lensgo.ru
И попробуем составить чек-лист с помощью Excel.
Закиньте что-нибудь в корзину и перейдите в нее, а далее к оформлению товара.
У вас должна отобразится страница по адресу https://lensgo.ru/basket/order/
Писать Чек-лист мы будем по форме “Данные о покупателе”
1 Напишем в шапке Чек-листа, Название и описание.
Чтобы другие тестировщики и ты сам смог быстро понять о чем этот Чек-лист.
2 Далее по каждому полю составляем краткий список проверок, результатов и еще проставляем приоритет. Каждая проверка проверяет один пункт, но может проверять и комбинации нескольких пунктов. Составлять список проверок нужно с помощью техник тест-дизайна, без них может получится огромный список тестов:
1 Граничные значения
2 Классы эквивалентности
можно прочитать про это в этих статьях:
Возьмем поле ФИО и составим группы проверок, а в них уже напишем списки проверок с помощью техник тест-дизайна. Немного подумав вычисляем, что можно создать три группы ( Проверка длины поля, Проверка поля на кириллице “ФИО”, Проверка поля на английском “ФИО”) учитываем также, что интернет-магазин ориентирован на Россию.
Вот загруженный пример, но попробуйте без скаченного примера составить проверки для поля “Телефон” и потом сравнить ваши тесты с моими.
Пример Чек листа в Sitechco
Есть огромное количество онлайн сервисов для составления чек-листов, но один из наиболее подходящий для тестировщиков это sitechco.ru
Где вы удобно можете расположить свои проверки, радует еще то, что интерфейс интуитивно понятен и можно быстро редактировать тесты. Еще имеется запуск тестов, отчеты по их прохождению и тест планы, все это очень облегчит вам жизнь при тестировании проекта.
И так вы узнали как можно составить чек-листы для тестирования вашего продукта, надеюсь, что моя статья вам помогла.
Для чего нужен чек лист в тестировании
Допустим, вы имеете общее представление о тестировании, ознакомились с основными терминами и примерами. Но, когда дело доходит до конкретного случая, не знаете, с чего начать и за что взяться. Как вообще проверять продукт, пусть даже и вручную? Как не забыть что-то важное? Для этого существуют чек-листы. Сегодня мы о них и поговорим.
Что такое чек-лист?
Чек-лист – это базовый инструмент тестирования, который поможет вам не забыть о важных тестах, отслеживать прогресс и результат работы. Обычно он выглядит как таблица-список возможных проверок составляющих продукта: страниц, блоков и прочих элементов. Пункты такого списка должны быть минималистичными и предельно понятными. Обязательными столбцами являются версии операционных систем и браузеров, так как в них продукт будет вести себя по-разному. Также стоит отметить, что чек-лист – это уникальный список, создаваемый под конкретный продукт. Под другой продукт применять его будет уже неверно.
Одна строка чек-листа должна отражать одно действие, описанное глаголом в начальной форме. Например:
Смешивать и соединять две операции (действия) в один пункт нельзя.
Каждый пункт должен описываться с помощью глагола, а не существительного. Так будет понятно конкретное, а не абстрактное действие для проверки.
При выполнении пункта чек-листа в столбце статуса отмечается этап проверки, например, Passed (пройден) или Failed (не пройден). В последнем случае можно добавить комментарий о багах. Также суествуют статусы Not run (тест пока не проводился) и Blocked (проверка заблокирована).
Ниже представлен один из базовых примеров чек-листа:
Статус Passed зеленым цветом показывает, что проверка успешно пройдена.
Если же статус – Failed, желательно добавлять в примечания ссылку на баг-репорт.
Плюсы чек-листов:
Насколько детальным будет чеклист, зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Подробнее о чек-листах мы рассказываем на курсе ПОИНТ, который стартует 16.11. Присоединяйтесь, чтобы попрактиковаться в составлении чек-листов и получить множество других полезных знаний о тестировании, которые помогут вам быстро найти работу в индустрии. Курс ПОИНТ ориентирован на практику: вас ждет 17 вебинаров и 17 практических заданий, за время которых вы освоите все нюансы профессии!
Отзывы наших студентов о ПОИНТ:
Прекрасный курс для тех, кто желает освоить специальность тестировщика. В рамках курса дано представление о том что такое тестирование и достаточно заданий для закрепления практических навыков. Преподаватели на связи и всегда готовы объяснить непонятные или вызвавшие затруднение моменты.
Вход в портал мира тестирования ПО! 😅 Подробный, структурированный курс. Построен от простого к сложному (и очень сложному). Постепенное овладение теоритическими знаниями, навыками работы с различными инструментами и техниками тестирования. Хороший фундамент для освоения специальности тестировщика.
Чек-листы в тестировании: что нужно знать тестировщику!
Из этого материала вы узнаете что такое чек-листы, зачем они нужны, как их составлять, когда применять. Поговорим мы и об их преимуществах и недостатках.
Что такое чек-лист?
Важность чек листов трудно переоценить. Каким бы опытным ни был сотрудник, в спешке он может легко забыть важную деталь.
В тестировании чек-лист — это список проверок для тестирования продукта. Чек-листы устроены предельно просто. Любой из них содержит перечень блоков, секций, страниц, других элементов, которые следует протестировать, например:
Выполненные пункты отмечаются статусами, например: “Passed”, “Failed”, “Blocked”, “Skipped”, “Not run”. Эти статусы также могут иметь свой цвет:
Преимущества использования чек-листов:
Разновидности чек-листов
Можно выделить два вида чек-листов: специальные и универсальные.
Специальные чек-листы создаются и используются для конкретных проектов, поэтому пункты такого чек-листа соответствуют специфики проекта. Тестировщик по специальному чек-листу проверяет возможность выполнить уникальное действие, предусмотренное требованиями. Вот примеры пунктов специального чек-листа:
Такие чек-листы не подходят к использованию на других проектах.
Универсальные чек-листы подходят для тестирования проектов одного типа. Проверка по универсальному чек-листу не привязывается к графическим элементам или конкретной реализации, а проверяется сама возможность пользователя выполнить действие. Для универсального чек-листа составляется абстрактный список проверок. Пункты универсального чек-листа могут быть такими:
Универсальные чек-листы можно использовать повторно на проектах одного типа. У многих агентств есть такие универсальные чек-листы, по ним определяется общий уровень качества продукта.
Как составлять работающие чек-листы
Чтобы составить работающий чек-лист, обратите внимание на эти рекомендации:
Преимущества и недостатки чек-листов
Чек-листы лучше применять на ранних этапах, когда софт быстро меняется, потому что тест-кейсы дорого поддерживать.
Чек-лист тестирования требований
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Конечно, их может быть и больше. Кто-то использует мнемонику CIRCUS MATTA, кто-то расширяет список под себя и команду. Но эти шесть характеристик — основные. О них и в книгах по тестированию пишут, и в самых разных статьях.
В этой статье я расскажу о каждой из них поподробнее, с картиночками и примерами из жизни.
1. Полнота
Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?
Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
Как-то раз мне прислали на проверку ТЗ на новый функционал. Да, по хорошему надо сразу прикинуть тесты, которые буду писать. А это надо взять ручку, блокнот и начать тест-дизайнить. Но я занималась другой задачей, а ТЗ надо проверить «сегодня», чтобы отправить оценку заказчику.
Поэтому решила проверить «мысленно». Читаю пункт ТЗ, прикидываю, какие могут быть тесты. В итоге задала парочку уточняющих вопросов:
У Заказчика уточнили, документацию пополнили! В остальном меня всё устроило, вроде нормально описано, всё учтено.
Заказчик согласовал ТЗ, разработчик сделал. Пришло время тестировать. Начинаю писать автотесты и. Да, разумеется, сразу получаю еще 5-10 дополнительных вопросов. В ТЗ не были предусмотрены все сценарии, и я о них тоже не подумала, пока прикидывала тесты мысленно.
А как только стала расписывать план автотестов, сразу увидела «белые пятна». При этом у меня 10 лет опыта в тестировании. Не полагайтесь на память и «быстренько мысленно прикину», выделите полчаса и распишите чек-лист проверок подробно.
Чем плохо отложить вопросы на потом? Не слишком профессионально согласовать требования, которые написала твоя команда, а через пару недель задавать уточняющие вопросы. Заказчик подумает: а чего сразу не спросили?
Плюс иногда можно пропустить очень важный вопрос, который трудозатратно делать. А ТЗ, напомню, уже согласовано. Так что всё, что продолбали на этапе согласования, делаем за свой счет.
Да, написать тесты — это дольше, чем просто прочитать документацию. Но зато вы экономите время потом, ведь чек-лист уже готов, бери да проверяй!
2. Однозначность
Требования должны трактоваться всеми одинаково.
«Отчет должен загружаться быстро» → что значит «быстро»?
пользователь будет уверен, что страница будет грузиться доли секунды, даже если это сложный отчет на многомиллионных данных;
разработчик прикинет, что в таких объемах 5 секунд нормальное время отклика, даже быстрое.
Налицо конфликт интересов. И ведь каждый будет тыкать в ТЗ для отстаивания своей позиции. Лучше конкретизировать:
Отчет за год должен загружаться не более секунды.
Отчет за весь период времени должен загружаться не более 5 секунд.
Если в требованиях не указано, что у нового поля с суммой дохода должно быть значение по умолчанию:
Аналитик будет думать, что там будет значение 0. Деньги же, цифра!
Разработчик сделает пустое поле, не указано ведь ничего! А это что-то сломает.
Если в требованиях не указано, как обработать ошибочный сценарий, разработчик может:
Не подумать о нем и никак не обработать — пользователь может огрести страшную ошибку.
Подумать о нем и обработать так, как считает правильным — а тестировщик потом будет доказывать, что надо было делать по другому. Пойдут к аналитику, потратят и его время тоже, а потом еще код переделывать.
Все, что можно прочитать двояко, лучше исправить. Это не значит, что нужно описывать каждую мелочь, но всё зависит от читателей документа.
Если это внутренний документ, а у вас сильная команда — можно не расписывать подробно.
Если этот документ отправят заказчику, надо расписать вообще всё — потому что у заказчика свои тестировщики, и они обязательно зададут кучу «а что, если. ». Если они хорошие тестировщики, разумеется. Это вы знаете свою программу и представляете, как она реагирует на ошибки или что-то такое. Тестировщик заказчика этого не знает, он будет уточнять.
3. Непротиворечивость
Требования не должны противоречить сами себе. Такое обычно бывает, когда требований много. Аналитик просто забывает, что уже писал про параметр и снова придумывает его поведение. Иногда придумывает немного по другому.
Например, есть страница нефункциональных требований, где написано, что любая страница должна грузится не более 3 секунд. Аналитик пишет ТЗ на новый модуль отчетности, который использует много данных и сложные формулы. И он пишет, что отчет может грузиться вплоть до минуты. Явное противоречие!
Если заказчик найдет первый раздел документации, он будет требовать именно такую скорость. И будет прав, кто же хочет ждать?)
4. Необходимость
Помните главный принцип: «Кратко, но емко»? Он действует и в документации тоже.
Круто, когда документация полная. Но это не значит, что простой функционал надо растечь на 10 листов А4. Когда документации много, сложно проверить полноту, сложно удержать в голове, о чем уже говорил, не повторяться и не противоречить самому себе.
Подумайте, так ли уж нужно описывать каждую кнопочку интерфейса? Это правда актуально? Пользователи правда не догадаются, что фильтры по строковым колонкам работают одинаково?
Пишите только то, что необходимо:
В ТЗ — функционал, основной сценарий и альтернативы, типы ошибок.
В пользовательской документации — то, как пользоваться системой. Но не доходя до крайностей и обучения включению компьютера.
5. Осуществимость
А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
Этот пункт обычно проверяют разработчики. Они остужают буйные фантазии из серии «загружать миллионы данных за 0,1 секунду» или что-то архитектурно сложное. Бывает такое, что на бумаге всё звучит просто, а вот сделать это займет человеко-месяц в лучшем случае.
В одной из систем, с которыми я работала, был точечный поиск. Не просто «найди мне все данные, где встречается «Ленина», а именно «найди мне адреса, у которых улица Ленина». Это отсеет фамилию Ленина, комментарий к телефону и другие нерелевантные данные.
Но вот беда — нельзя поискать по двум параметрам ОДНОГО атрибута. Если сказать «Найди мне домашний адрес с улицей Ленина», система вернет:
1. Васю: домашний адрес с улицей Ленина.
2. Петю: домашний адрес с переулком Турчанинов и рабочий с улицей Ленина.
Это баг в системе? Или просто нельзя сделать такой поиск, это неосуществимо? Нужно смотреть по коду.
В той системе для поиска использовали Lucene. Его можно настроить по-разному:
o поиск по любому полю;
o поиск по конкретному полю;
o множественный поиск по конкретному атрибуту (в одном адресе проверить и тип, и улицу);
Но! Чем сложнее сценарий поиска, тем медленнее он работает. Дольше сохраняет данные (потому что структура внутри усложняется), дольше ищет — или потребляет больше ресурсов для той же скорости.
Когда данных с гулькин нос, это неважно. А когда их миллионы, нужно искать баланс. И такой выбор возможностей поиска — это именно компромис для скорости и потребляемых ресурсов под сценарии использования.
Осуществимо желание отсеять Петю? Да. Но это просто не нужно. Потому что вреда принесет больше, чем пользы. Ради того, чтобы в выборку из 1000 человек не попали 10 лишних, платить несколько миллионов за дополнительные мощности серверов смысла просто нет.
6. Тестируемость
Можно ли протестировать этот функционал?
Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новый функционал не заточен.
Если в компании принято все покрывать автотестами, то это станет проблемой. Может, разработчик прочитает ТЗ и сам поймет, что ещё фреймворк тестов дорабатывать надо. А может, он не вспомнит об этом. И тогда ваша задача — вспомнить. Чтобы сразу заложить время на доработки.
У меня бывали ситуации, когда мы делали задачу в текущем релизе, а потом ставили новую «Доработать фреймворк автоматизации, чтобы поддержать изменения» в следующий. Иногда забывали про фреймворк, а потом времени в релизе уже не оставалось. А иногда сразу понимали, что всё сразу сделать не успеем.
Иногда про тесты не думаешь, так как уже есть похожие. Например, у нас давно были автотесты на обратный поток в JMS-очередь. А потом для одного из заказчиков мы сделали обратный поток в две JMS-очереди.
Сначала я не подумала о доработке автотестов — ведь возможность проверить «что ушло» есть! А когда добралась до тестирования, пошла к разработчику:
— А как мне указать вторую очередь? Или папка jms — это то, что в обе уйдет?
— Хм, нет, погоди, это только в старую. Надо доделывать фреймворк, поддержать разные очереди.
Ну и ничего, доделали, написала тестов!
Хотя лучше об этом помнить сразу, иначе велик шанс, что тестировать за вас придется разработчику. Или половину проверок переносить на следующую итерацию, что тоже не очень хорошо.
При этом бывает и так, что тестировать все равно придется разработчику. Скажем, когда делают рефакторинг, что может проверить тестировщик? Только регресс провести, посмотреть, что ничего не отломалось. А если есть автотесты, то это проверят они =)
Однако если тесты (авто или ручные) прошли успешно, это ещё не значит, что рефакторинг прошел хорошо. Сама суть рефакторинга — переписать код, чтобы он был более оптимален и читабелен. Чтобы его было легче поддерживать в дальнейшем и интегрировать с другими частями системы.
И именно это и надо проверить! А проверить это может только разработчик. Он и выполняет тестирование в данном случае.
Бонус: мнемоника CIRCUS MATTA и другие доп материалы
CIRCUS MATTA — мнемоника для ревью пользовательских историй. Это как раз про тестирование требований! Истории должны обладать качествами:
Completeness — полнота
Independent — независимость
Realisable — реализуемость
Consistency — консистентность
Unambiguity — однозначность
Specific — специфика заказчика
Measurable — измеримая
Acceptable — приемлемая
Testable — тестируемая
Traceable — трассируемая (можно проставить взаимосвязи)
Achievable — достижимая
Вон сколько пунктов получилось! Мне особенно импонируют пункты «специфика заказчика» и «трассируемость». Это и правда важно. Если у вас коробочный продукт, который кастомизируется под заказчика, обязательно смотрите на пункт «Specific». А трассируемость — очень хороший бонус, облегчающий поддержку документации в актуальном состоянии!
Чеклисты в помощь QA
Привет, Хабр! Анастасия Асеева-Нгуен (эксперт по инженерным практикам в Tinkoff Group) приглашает специалистов по тестированию на бесплатный Demo-урок «Метрики», который пройдёт в рамках нового профессионального курса OTUS — «QA Lead». А мы публикуем статью Анастасии Шариковой — руководителя отделом тестирования в Bookmate.
Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.
Сегодня речь пойдет о чек-листах — отличном универсальном инструменте, который может помочь в повседневных задачах QA специалистам любых уровней. Обратимся к теории и вспомним, что есть и особый вид тестирования, который их использует:
Тестирование на основе чек-листов — метод создания тестов, основанный на опыте, при котором опытный тестировщик использует высокоуровневые списки.
К сожалению, многие забывают, что чек-листы можно использовать не только как подготовительный этап к дальнейшему написанию тест-кейсов, но и сами по себе. Зачастую они даже могут их заменить целиком, и о вариантах их использования и плюсах и минусах будет написано далее.
Варианты использования чек-листов
Как верно было написано у С. Куликова в «Тестирование программного обеспечения. Базовый курс»
… тестировщику приходится работать с огромным количеством информации, выбирать из множества вариантов решения задач и изобретать новые.
— и во многих случаях действительно прекрасным инструментом и для разработки, структурирования проверок и для многих других задач QA специалист может использовать чек-листы. Давайте рассмотрим поподробнее некоторые варианты:
Ad-hoc/Исследовательское тестирование — структуризация идей и задач в случае проведения таких видов тестирования+ отметка для себя о том, что уже проверено.
Тестирование на основе чек-листов — довольно популярный метод создания тестов, основанный на опыте, при котором опытный тестировщик использует высокоуровневые списки. Список в данном случае содержит пункты, которые нужно отметить или запомнить, или состоит из набора правил или критериев, согласно которым верифицируется нужный программный продукт.
Mind Maps — несмотря на то, что чаще всего чек-лист выглядит как перечень блоков, секций, страниц, других элементов, которые следует протестировать, он может быть и визуализирован в виде майнд карт. А еще их можно не только составлять самим, но и находить уже готовые, что позволит сэкономить время и посмотреть на задачи проверок свежим взглядом.
«Групповое» тестирование — фичи, сложные задачи, командная работа, во всех этих случаях можно использовать списки для синхронизации проверок в группе, работающей над одной задачей.
Информирование менеджмента — зачастую проще выслать ссылку на постоянно обновляемый чеклист, который покажет процент выполнения, чем ежечасно отвечать на вопросы в духе “А когда? А сейчас уже проверили?”
Помощь коллегам — конечно, TDD и прочие крутые практики это хорошо, но иногда может быть достаточно и просто отправить разработчику список проверок, которые предварительно составили по конкретной задаче, чтобы он проверил, ничего ли не упущено. Особенно хорошо работает, если разработчик на проекте недавно или джуниор уровня.
Конечно, это не весь список возможностей, но уверена, что-то из этого многие смогут применить у себя на проекте, особенно в небольших командах.
Способы составления чек-листов
Преимущества и сложности в использовании
Рассмотрим основные преимущества и сложности, которые могут появиться при использовании чек-листов для различных кейсов и задач:
Плюсы:
Минусы:
Инструменты
Как итог, перечислю одни из самых популярных инструментов для составления чек-листов:
Trello — тоже имеет функционал составления чек-листов в рамках задач.
Google.Sheets — этот инструмент в представлении не нуждается. Тем не менее это, конечно, не единственное решение с таблицами, Exсel тоже подойдет!
To Do — перерождение Wunderlist и отличное решение для чек-листов, особенно для личного использования.
Miro — а вот тут будет удобно создавать уже Mind Maps.
Jira — в этом случае есть много вариантов встраивания под разные задачи + доп. Инструменты, такие как этот.
Знаете еще крутые инструменты и кейсы использования? Пишите в комментариях!
Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок «Метрики», а также приходите на другие Demo-уроки для QA-специалистов:
«Основы puppeteer» — трансляция в рамках курса «Автоматизация тестирования на JavaScript»