Чек-листы в тестировании: что нужно знать тестировщику!
Из этого материала вы узнаете что такое чек-листы, зачем они нужны, как их составлять, когда применять. Поговорим мы и об их преимуществах и недостатках.
Что такое чек-лист?
Важность чек листов трудно переоценить. Каким бы опытным ни был сотрудник, в спешке он может легко забыть важную деталь.
В тестировании чек-лист — это список проверок для тестирования продукта. Чек-листы устроены предельно просто. Любой из них содержит перечень блоков, секций, страниц, других элементов, которые следует протестировать, например:
Выполненные пункты отмечаются статусами, например: “Passed”, “Failed”, “Blocked”, “Skipped”, “Not run”. Эти статусы также могут иметь свой цвет:
Преимущества использования чек-листов:
Разновидности чек-листов
Можно выделить два вида чек-листов: специальные и универсальные.
Специальные чек-листы создаются и используются для конкретных проектов, поэтому пункты такого чек-листа соответствуют специфики проекта. Тестировщик по специальному чек-листу проверяет возможность выполнить уникальное действие, предусмотренное требованиями. Вот примеры пунктов специального чек-листа:
Такие чек-листы не подходят к использованию на других проектах.
Универсальные чек-листы подходят для тестирования проектов одного типа. Проверка по универсальному чек-листу не привязывается к графическим элементам или конкретной реализации, а проверяется сама возможность пользователя выполнить действие. Для универсального чек-листа составляется абстрактный список проверок. Пункты универсального чек-листа могут быть такими:
Универсальные чек-листы можно использовать повторно на проектах одного типа. У многих агентств есть такие универсальные чек-листы, по ним определяется общий уровень качества продукта.
Как составлять работающие чек-листы
Чтобы составить работающий чек-лист, обратите внимание на эти рекомендации:
Преимущества и недостатки чек-листов
Чек-листы лучше применять на ранних этапах, когда софт быстро меняется, потому что тест-кейсы дорого поддерживать.
Чек-лист тестирования WEB приложений
Привет! После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования WEB приложений состоит из шести разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Что проверяем?
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Что проверяем?
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
Чек-лист тестирования требований
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Конечно, их может быть и больше. Кто-то использует мнемонику 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»
Как составлять чек-лист для тестирования программы
Кто-то в процессе своей трудовой деятельности составляет чек-листы, а кто-то этим не занимается и пишет только тест-кейсы. Я считаю, что чек-лист и тест-кейсы неотделимы по своей сути. Сюда же можно добавить и интеллектуальную (функциональную) карту приложений. Поясню почему они неотделимы, а потом перейдём непосредственно к чек-листам.
О принципах правильного написания тест-кейсов и создания карт приложений я рассказывал в отдельных статьях, ссылки на которые приведу в конце данной статьи.
Какая взаимосвязь существует между тремя озвученными сущностями? Когда я обучаю специалистов по тестированию, то обучение мы начинаем с карт приложения. Картами мы охватываем весь возможный функционал программы. После того как карта полностью создана мы на основании конечных проверок, зафиксированных на карте, создаём чек-лист. Создав чек-лист, мы начинаем создание тест-кейсов.
Для чего мы так делаем? Для того чтобы не упустить какой-либо функциональный блок программы при создании тест-кейсов. По опыту знаю, что когда пишешь тест-кейсы и нет ни карты приложения, ни чек-листа, то после пятидесяти или сотни написанных тест-кейсов становится трудно удерживать в голове информацию, что описано тест-кейсами, а что ещё надо описать тест-кейсами, а впереди ещё надо написать несколько тысяч тест-кейсов. В этом случае чек-листы нам помогают и нам не надо в голове держать большие объёмы информации по тому, что мы описали тест-кейсами, а что ещё надо описать.
Поэтому примите на вооружение правило написания тест-кейсов:
Теперь рассмотрим, как правильно составлять чек-лист на основании карты приложения. Сейчас мы не будем рассматривать создание чек-листов без карт приложений, так как это делается аналогично, только не используются карты приложений и в таком случае можно часть функционала приложения забыть зафиксировать в чек-листе.
Для начала у нас должна быть составлена карта приложения:
На карте приложения у нас имеются конечные проверки, обозначенные галочками в зелёных кружочках. Эти проверки мы и будем переносить в чек-лист.
Чек-лист
Раздел «Содержимое окна»:
Раздел «Строка меню» мы не вносили в чек-лист так как карта приложения в данном разделе ещё не завершена и нет конечных проверок. Когда карта приложения будет завершена, тогда и внесём в чек-лист проверки из данного раздела.
Если внимательно присмотреться в чек-лист и глянуть на функционал программы, то мы увидим, что после того, как программа сворачивается она скрывает свою форму и отображается на панели задач операционной системы, а значит нам надо проверить, что программа может разворачиваться из панели задач и снова отображать свою форму. Для этого мы вносим в чек-лист дополнительную проверку:
У нас получился следующий чек-лист:
Принцип создания понятен. Важно всегда помнить, что одна конечная проверка из карты приложения, может разделиться на несколько проверок в чек-листе, т.е. в чек-листе будет больше проверок.
Приведём пример. В карте приложения имеется конечная проверка:
Мы знаем, что в личный кабинет на сайте мы можем войти несколькими способами, поэтому все эти способы должны быть зафиксированы в чек-листе:
Как видите из одного пункта проверки карты приложения у нас появилось четыре пункта в чек-листе. Эти проверки могли быть зафиксированы и в карте приложения, тогда у нас одна проверка из карты приложения перешла бы в одну проверку в чек-листе.
Имея полностью созданный чек-лист, мы можем дальше создавать тест-кейсы. Опытные тестировщики знающие хорошо функционал тестируемого приложения могут тестировать приложение по чек-листу без тест-кейсов. Тестировщикам плохо знающим функционал приложения тестировать по чек-листам будет затруднительно.
В видео рассказываю как создавать чек-лист:
О принципах правильного написания тест-кейсов я рассказывал в статье «Правильно пишем тест-кейсы». О создании карт приложений я рассказывал в статье «Облегчаем тестировщику жизнь при написании тест-кейсов». В статьях имеются подробные видеоматериалы по данным темам.
Если хотите научиться создавать карты приложений, чек-листы, тест-кейсы и узнать многое другое, то пройдите обучающий курс «Тестирование ПО. Начальный уровень».