Список дел, или список проверок, — это инструмент, который позволяет не только не пропустить важные проверки, но также структурировать работу и упростить её — в том числе за счёт высвобождения умственных ресурсов, так как список позволяет не держать в памяти много информации. Это актуально для сложных задач, требующих повышенного внимания. Например, пилоты и космонавты перед стартом всегда используют список проверок, чтобы убедиться, что все системы запущены и работают исправно.
В тестировании списки проверок называются чек-листами.
Тестирование на основе чек-листов
Чек-лист (checklist) — набор (список) проверок или идей.
Тестирование на основе чек-листов (checklist-based testing) — метод создания тестов, основанный на опыте использования высокоуровневых списков. Список содержит пункты, которые нужно отметить или запомнить, или из набора правил и критериев, согласно которым верифицируется программный продукт.
Чек-листы создают либо сами тестировщики, либо тест-дизайнеры. Основа для чек-листов — требования, спецификации, опыт тестировщика, данные об ошибках, ранее найденных в приложениях, информация о приоритетах.
Тестировщик с нуля / Урок 8. Тестовая документация. Чек-лист и тест-кейс в тестировании. Примеры
Чек-лист можно написать на листе бумаги или сделать в электронном виде с помощью приложений — в некоторых есть готовые наборы проверок для разных ситуаций. Например, Checkvist: Professional list making tool . Чек-листы можно представить графически — в виде интеллект-карт. Вариантов много — выбор наиболее подходящей формы чек-листа зависит от задач проекта и предпочтений тестировщиков.
Чек-листы могут составляться для единичных проверок, например быстрой проверки новой функциональности, или многократно повторяющихся, например при регрессионном тестировании.
Примеры чек-листов:
- Чек-лист может быть создан в файле Excel (или Google Docs) и содержать четыре колонки — порядковый номер, название проверки, результат проверки (успешно/неуспешно) и комментарий (например, ссылка на дефект при неудачной проверке). Колонки заполняются результатами проверок.
Как правило, чек-листы не содержат описания ожидаемого результата. Но иногда, если это необходимо для проекта, может быть добавлена колонка, в которой будет описано ожидаемое поведение системы.
2. Чек-лист может быть высокоуровневым , то есть содержать общее описание проверок (см. выше), или более детализированным , с перечислением конкретных тестовых данных, которые должны быть использованы.
3. Если нужно провести проверку в нескольких тестовых окружениях , например в разных браузерах или операционных системах, то в чек-лист добавляются колонки с названиями тех тестовых окружений, в которых нужно проводить тестирование.
4. Чек-листы могут быть использованы многократно для тестирования разных версий продукта, поэтому в них могут добавляться колонки с названием тестируемой версии. Это позволяет не только экономить время на создание нового чек-листа, но и прослеживать историю тестирования и фиксировать слабые места приложения.
Чеклисты в тестировании / Урок 15 / Тестировщик с нуля
5. Чек-листы могут содержать краткие инструкции для тестирования : что именно следует выполнить для проведения проверки.
6. Чек-лист может быть выполнен просто в виде списка проверок в специальном веб-приложении.
Как правило, чек-лист — это список проверок, которые должны быть сформулированы кратко, просто и понятно.
Важно, чтобы чек-лист был логичен и последователен. Проверки в нём должны быть взаимосвязаны, понятны специалисту, который их проводит, и, по возможности, объединены в логические группы. Проверки могут быть последовательными, когда каждая следующая зависит от результатов предыдущей, или свободными, когда порядок проведения проверок не имеет значения.
Для чек-листов также актуально правило, которое применяется в тестировании: сначала проводятся позитивные проверки, затем негативные . Для чек-листов применяются классы эквивалентности и граничные значения. Если работа ведётся по детализированным чек-листам, эти техники тест-дизайна должны использоваться при планировании тестовых данных.
Чек-листы применяют, если:
- времени на детальную разработку тест-кейсов недостаточно;
- требования часто меняются, и это делает трудоёмким поддержание тест-кейсов в актуальном состоянии. Вносить изменения в чек-листы быстрее и проще;
- отсутствуют требования — есть готовый продукт, который нужно протестировать, не упустив важных функций, например работу всех элементов меню, валидацию поля по допустимым значениям;
- важно предотвратить «эффект пестицида» — постоянное повторение одних и тех же шагов тест-кейса может приводить к снижению его эффективности. Применение чек-листов позволяет этого избежать, так как предполагает большую вариативность сценариев для проверок;
- тестировщики достаточно опытны и хорошо знают тестируемый продукт — в таком случае им достаточно списка проверок, чтобы просто не упустить тесты;
- нужно быстро познакомить новых сотрудников с особенностями работы приложения и его основными функциями.
На основе чек-листов можно в дальнейшем создать тест-кейсы. Также они помогают вести статистику и составлять отчёты по результатам тестирования.
Чек-листами стоит пользоваться, даже когда документация на проекте отсутствует, — они помогают сделать процесс тестирования более контролируемым и осознанным.
В следующей статье разберём Тест-кейсы и атрибуты тест-кейсов.
Источник: dzen.ru
Чек-листы в тестировании: что нужно знать тестировщику
Из этого материала вы узнаете, что такое чек-листы, зачем они нужны, как их составлять, когда применять. А ещё расскажем о преимуществах и недостатках этих документов.
Преимущества использования чек-листов:
- улучшается представление о системе в целом, виден статус её готовности;
- виден объём проделанной и предстоящей работы по тестированию;
- легче не повторяться в проверках и не упустить ничего важного в процессе тестирования.
Разновидности чек-листов
Можно выделить два вида чек-листов: специальные и универсальные.
Специальные чек-листы создаются и используются для конкретных проектов, поэтому пункты такого чек-листа соответствуют специфике проекта. Тестировщик по специальному чек-листу проверяет возможность выполнения уникального действия, предусмотренного требованиями. Такие чек-листы не подходят к использованию на других проектах.
Вот примеры пунктов специального чек-листа.
- При наведении курсора на пункт меню «Товары», должен меняться цвет на синий, указатель должен менять форму на pointer.
- Если пользователь открыл страницу «Ваша корзина» и в корзине присутствует хотя бы один товар, должно показываться уведомление.
Универсальные чек-листы подходят для тестирования проектов одного типа. Проверка по универсальному чек-листу не привязывается к графическим элементам или конкретной реализации. Проверяется сама возможность пользователя выполнить действие. Для универсального чек-листа составляется абстрактный список проверок.
Пункты универсального чек-листа могут быть такими:
- пользователь может перейти в раздел «Товары»;
- оплата должна совершаться;
- товар должен добавляться в корзину;
- ссылки при наведении подчёркиваются;
- валидатор вёрстки показывает отсутствие ошибок и т.п.
Универсальные чек-листы можно использовать повторно на проектах одного типа. У многих агентств есть такие универсальные чек-листы, по ним определяется общий уровень качества продукта.
Как составлять работающие чек-листы
Чтобы составить работающий чек-лист, обратите внимание на эти рекомендации:
- Один пункт = одна проверка. Минимальная полная операция проводимая тестировщиком при проверке — это один пункт чек-листа.
- При составлении чек-листа нужно опираться на требования, чтобы не тестировать то, что не существенно.
- Давайте пунктам чек-листа названия по форме, общей для всех членов команды, чтобы работа с чек-листом не вызывала неоднозначных толкований. Можно договориться использовать во всех пунктах только глаголы в инфинитиве или существительные: «проверить»/ «добавить»/ «отправить» либо «проверка»/«отправка»/«добавление».
- Детализируйте чек-лист в зависимости от задачи.
- Объединяйте чек-листы в матрицы, где можно отразить не только сами проверки, но и условия проверки (платформа, версия продукта, сотрудник и т.п.) и статус проверки. Матрицы — это компромисс между чек-листами и тест-кейсами. Их легче поддерживать, чем тест-кейсы, так как в такой таблице отсутствуют шаги (steps). В них одна строка = одна проверка.
Преимущества и недостатки чек-листов
Преимущества:
- чек-лист легко читается;
- по чек-листу быстро тестировать: в тест-кейсе нужно отмечать статус каждого шага, в то время как в чек-листе достаточно одной строчки;
- чек-лист — источник результатов для отчёта: можно быстро посчитать сколько проверок выполнено, в каком они статусе, узнать количество открытых репортов;
- в любой момент можно узнать статус — всегда есть то, что нужно проверить в первую очередь, можно упорядочить пункты чек-листа или изменить порядок, когда это требуется.
Недостатки:
- неопределенность тестового набора: каждый тестировщик выполняет пункт чек-листа по-своему;
- неопределенность тестовых данных;
- недостаточность детализации;
- сложнее обучить начинающих сотрудников: пункты чек-листа чаще абстрагируются от конкретных элементов интерфейса и описывают то, что нужно сделать;
- чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.
Таким образом, наилучший вариант для применения чек-листов — ранний этап разработки, когда когда софт быстро меняется и нет необходимости в более сложной документации. Чек-листы удобны в использовании, наглядны и полезны как тестировщикам, так и сторонним наблюдателям.
Источник: qualitica.ru
Основы тестирования. Тест-кейсы и чек-листы
Думаю, что даже противники бумажной волокиты не будут отрицать, что описанный план проверки значительно упрощает процесс тестирования и экономит в последующем кучу времени.
Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.
Тест-кейсы и чек-листы относятся к документации тестирования. Их задача — систематизировать и упростить процесс тестирования, сделать его более прозрачным и структурированным. А еще их использование может очень сильно экономить время.
Тест-кейс
Тестовый случай, тестовый сценарий (test case) — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Иными словами, это артефакт или документ, который описывает наши тесты. Говорит, как их выполнить, при каких условиях и что должно получиться после выполнения тех шагов, которые заложены в тест-кейсе, то есть каков ожидаемый результат.
Тест-кейс имеет определенный шаблон, разработанный для того, чтобы стандартизировать и упростить создание и дальнейшее чтение тест-кейсов. Шаблон условно стандартизированный, потому что может меняться в зависимости от компаний и процессов.
1.ID — уникальный номер.
Обычно проставляется автоматически в системах хранения тест-кейсов.
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 вводим, какой неправильный пароль и так далее
________________________________
Следовательно, если с чек-листом работают уже опытные тестировщики, то особых проблем не возникает. Если приходят новички и видят чек-листы, то они могут запутаться и неправильно проверить функциональность, потому что не будут с точностью знать, как правильно протестировать и какие данные вводить.
Как видите, чек-листы и тест-кейсы сильно упрощают процесс тестирования. Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.
При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить. Достаточно один раз уделить немного больше времени на проверку и написать по ней тест-кейсы и чек-листы, чтобы потом экономить время при следующих проверках.
Источник: sedtest-school.ru