Отличие чек листа от тест кейса

Обновлено: 05.10.2024

Друзья, всем доброго времени суток!
Тема такая: откликнулась на вакансию джуна, прислали тестовое задание, в котором была задача написать чек-лист и оформить баг репорты (если найдешь). Тестировала мобильное приложение. Так вот, сделала чек-лист (как я понимаю): список проверок, которые нужно осуществить (то есть 1. Нажать кнопку такую итд, очень подробно, углубляясь в каждый раздел тестируемого продукта.
Мне пришел отказ, причина отказа в том, что работодатель хотел увидеть тестирование по схеме: шаг, ожидаемый результат, статус теста. На мой чек-лист он сказал, что это больше похоже на план тестирования, но разве план тестирования может ограничиться пунктами 1,2,3 нажать то/се/пятое/десятое? Шаг, ожидаемый результат, статус теста - ведь это не чек-лист получается, а тест-кейс?
Читала много форумов, общалась со знакомыми тестерами, у меня предоставление - чек-лист кратко, тест-кейс подробно.
Внесите ясность - Ху из Ху :)
И справедливы ли требования работодателя? Или же он сам неверно сформулировал задание?
Нужна ясность для себя, заранее спасибо за ответы!

P.S. ищу работу без недели 2 месяца, результаты пока отрицательные)

Доброе время года!

Вы попали на несогласованность внутри работодательной фирмы. Это норм, и это не лечится.

Возражать не надо, учить их терминологии не надо, искать справедливости не надо. Смиренно попросите фидбэк (без уточнений и возражений) и продолжайте искать.

В будущем будете заранее уточнять, что от вас хотят, а не полагаться на своё понимание и воображаемые эталоны в индустрии.

Software Testing Glossary - простыми словами о непростых словах.

В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.

Этот этап опционален. На некоторых проектах нет задокументированных требований, и тогда зачастую поддержка тестовой документации является единственным разумным способом хранения и передачи знаний о продукте. Иногда тестовую документацию требует заказчик, иногда мы пишем ее для себя. Иногда, если у нас есть хорошо написанные требования, мы отказываемся от документирования тестов в пользу экономии ресурсов.

Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

Чек-листы vs Тест-кейсы

Чек-лист отличается от тест-кейса степенью подробности. В чек-листе вы не встретите подробных шагов кейса, для использования чек-листа при тестировании очень много информации нужно держать в голове в момент прогона тестов и знать логику работы приложения на отлично.

В нашей компании всегда использовались чек-листы, поскольку на написание тест-кейсов уходит неоправданно много времени, и они тяжеловесны — на прочтение кейса и его осознание тоже уходит время. Кроме того, не стоит забывать про эффект пестицида — баги кода имеют свойство приспосабливаться к тестам. При использовании чек-листа сохраняется некоторая свобода действий, а тест-кейсы этой свободы полностью лишают, увеличивая упомянутый выше эффект. Однако, при прогоне чек-листа в седьмой раз за последние сутки перед релизом часть функциональности, заложенной под одним пунктом чек-листа, теряется по причине человеческого фактора.

Плюсы такого подхода:

чек-лист подразумевает непрерывное выполнение его тестировщиком. Соответственно, все кейсы расположены в порядке, удобном для прогона, и времени на переход к следующему кейсу не тратится
чек-лист покрывает большое количество пользовательских сценариев
чек-лист содержит как позитивные, так и негативные кейсы. Проверяет восстановление после ошибок и прерываний, что в случае мобильных приложений очень важно
чек-лист подразумевает длинные сессии, что повышает вероятность обнаружения утечек памяти и навигационных проблем
информация о требованиях поступает тестировщику последовательно, что дает лучшее понимание логики работы приложения

чек-лист подразумевает декомпозицию по экранам приложения и сильно завязан на дизайн. Соответственно, все изменения в дизайне подразумевают изменения в чек-листе
с учетом, что кейсы такого чек-листа должны быть связаны в единую стори, а кейсов в одном чек-листе может быть до двух сотен, поддерживать его сложно
эффект пестицида значительно повышается
чек-лист не может заменить требования для разработчиков — разрабатывать по таким требованиям неудобно
чек-лист довольно долго писать и из-за его громоздкости его не всегда удобно использовать — по факту он пригождается только в финале перед релизом

Таблицы vs Деревья

Однажды я выпила поливитаминов, и меня осенило, что вместо того, чтобы хранить тесты в табличных форматах, куда удобнее использовать деревья, а точнее, вложенные списки. Ведь при написании той самой большой юзер-стори мы так часто сталкиваемся с проблемой, что не знаем, где расположить альтернативные действия. Например, когда у нас несколько кнопок на алерте. Чтобы проверить каждую из них, нам приходится прописывать вызов этого алерта несколько раз. Вместо этого мы могли бы подвесить проверку каждой из кнопок к вызову алерта.

В целом идея была в том, чтобы прописывать те же самые пользовательские сценарии в виде дерева, в котором переход — это действие, а узел — это состояние, в котором оказывается приложение после этого действия. По факту диаграмма состояний-переходов, только объектами выступают экраны приложения. Каждая ветвь такого дерева — тест-кейс.

Когда стали пробовать, столкнулись с проблемами. Оказалось, что привычная нам декомпозиция по экранам приложения не работает: опираться на дизайн при проектировании тестов неудобно. Ветки дерева росли далеко в глубину, и это было неудобно визуально. В погоне за сценарием мы воротили циклы. А еще стало понятно, что отказаться от таблиц нельзя.

В целом, плюсы использования древовидной структуры:

структура такой документации в итоге очень гибкая и позволяет вести как чек-листы, так и тест-кейсы в зависимости от нужд проекта
дерево представляется в виде вложенных списков: у узлов дерева есть некоторый порядок, что сохраняет возможность последовательной и структурированной передачи информации о требованиях тестировщику в случае отсутствия на проекте задокументированного ТЗ
такая структура позволяет спроектировать тестовую документацию, которую можно передать разработчикам вместо ТЗ
временные затраты на написание чек-листов и тест-кейсов снижаются, поскольку структура позволяет избежать копипасты

такая структура тестовой документации требует тщательного проектирования и предварительной аналитики — при плохом проектировании все упомянутые выше плюсы теряются

Итоговые паттерны

Экраны приложения

Источником знаний является навсхема. Первый уровень дерева составляет список кейсов навсхемы, который обычно соответствует разделам приложения. Далее к ним подвешивается список экранов каждого раздела, к каждому экрану — список его состояний. В каждом узле дерева, начиная с третьего уровня, может содержаться чек-лист в табличном формате, описывающий каждый элемент дизайна и способы взаимодействия с ним. Если элементы дизайна сложные и имеют много состояний или на экране есть повторяющиеся элементы, можно декомпозировать еще глубже. Таким образом, одна ветвь дерева описывает жизненный цикл одного экрана.

Ниже в качестве примера приведена общая схема рассуждений при декомпозиции раздела заказов агрегатора авиабилетов.

Критерии для выбора такого паттерна следующие:

UI является приоритетным для заказчика
минимум бизнес-логики на клиенте
для приложения характерны кастомные элементы дизайна и анимации, сложные жесты
на проекте нет других задокументированных требований кроме навсхемы

Объекты/действия

При таком подходе ориентируемся не на навсхему, а на документацию АПИ и клиентскую бизнес-логику. Негативные и позитивные кейсы разбиваем по разным веткам. Желательно, чтобы элементы одного уровня дерева отвечали на один вопрос, но можно оставить это ограничение только для одного уровня иерархии.

Такая схема крайне удобна в тех случаях, когда у нас есть активное влияние пользователей друг на друга, что порождает сложные сценарные цепочки. Примером может служить чат. Относительно предыдущего подхода такую документацию легче поддерживать, поскольку изменения в логике случаются реже, чем в дизайне.

Ниже приведен пример общей схемы рассуждений при декомпозиции по принципу объект/действие.

В такой схеме дополнительным бонусом является возможность использовать ее как карту для исследовательского тестирования и для смоук-теста. Степень подробности тестирования можно регулировать, отсекая при прогоне уровни дерева, поскольку каждый следующий уровень уточняет предыдущий. При углублении в ветвь дерева — углубляешься в функциональность.

Например, для уже упомянутого чата схема документации будет выглядеть примерно так:

Критерии выбора такого паттерна:

цель — протестировать функциональность
сложная бизнес-логика
частые правки дизайна
стратегия тестирования на проекте подразумевает сочетание скриптового и исследовательского тестирования

На базе Use cases

Бывают ситуации, в которых нерентабельно декомпозировать функциональность и проектировать тесты по двум описанным ранее схемам. Например, если мы хотим покрыть тестами длительную работу с приложением – как в случае с лентой соцсети или прослушиванием музыки в бекграунде. Или когда фича завязана на сценарии с малым количеством альтернатив – например, оформление подписки на контент. В таком случае пользуемся третьим паттерном, основанном на пользовательских сценариях.

Сначала декомпозируем функциональность по use-кейсам. Определяемся с тем, какие действующие лица могут участвовать в процессе работы с приложением и какие цели они могут перед собой ставить. За это будут отвечать первые два уровня нашего дерева. Далее пытаемся найти все возможные входные условия, которые могут повлиять на отработку сценария по достижению текущей цели, и структурируем их в дереве. Их так же удобнее всего делить на позитивные и негативные. Далее к каждому листу подвешиваем сценарный чек-лист на проверку функциональности, отвечающей за достижение цели.

В качестве примера ниже приведена схема для музыкального плеера с функцией загрузки треков для прослушивания офлайн:

Здесь ко всем листьям позитивного сценария подвешиваем чек-лист, который нужно будет прогонять в условиях разных подключений к сети:

Решение второй проблемы менее очевидно. Это в целом ограничение use-кейса — в случае, если поведение системы не определяется действиями пользователя однозначно, возникают проблемы с покрытием и проектированием use-кейсов. Для себя решили, что в таких ситуациях мы стараемся прописать все возможные варианты поведения систем, неподвластных пользователю, как предусловия, и тем самым снижаем неопределенность результата выполнения сценария. Либо используем другую схему проектирования тестовой документации.

Критерии выбора такого паттерна:

для заказчика приоритетом является корректная работа определенных пользовательских сценариев
приложение содержит экраны, на которых пользователь проведет много времени, потребляя контент
приложение содержит фичи, заключающиеся в отработке линейного сценария
стратегия тестирования на проекте подразумевает скриптовое тестирование
простая бизнес-логика, легко покрываемая use-кейсами

Отталкиваемся от цели

Наличие тестовой документации на проекте позволяет зафиксировать информацию о требованиях, заранее продумать и структурировать тесты, снизить порог вхождения в проект нового тестировщика, снизить риски пропуска ошибок из-за человеческого фактора. Однако, написание и поддержка тестовой документации требуют ресурсов, которые не всегда возможно или не всегда оправданно тратить.

Думаю, что даже противники бумажной волокиты не будут отрицать, что описанный план проверки значительно упрощает процесс тестирования и экономит в последующем кучу времени.
Что же это за документы и как их сделать помощниками, а не врагами? Ответ на эти вопросы лежат в статье.

Тест-кейсы и чек-листы относятся к документации тестирования. Их задача — систематизировать и упростить процесс тестирования, сделать его более прозрачным и структурированным. А еще их использование может очень сильно экономить время.

Тест-кейс

Тестовый случай, тестовый сценарий (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)
Кейс относится напрямую к авторизации, следовательно этот модуль и укажем.

10. Приложения (attachments)
В этот раз файлы нам не нужны, поэтому обойдемся без них.

Для наглядности соберем все это в таблицу.

Обратите внимание, что все тестовые данные, такие как почта или пароль лучше указывать явно, так как это убережет вас от лишних действий и поиска того, каким должен быть правильный аккаунт.

В рассмотренном примере все шаги приводят к одному результату. Но также есть ситуации, когда на каждый шаг будет свой ожидаемый результат.

Если будет много проверок на один компонент, то тест-кейсы можно объединить в тестовый набор или по-другому Test Suite.

Теперь давайте немного поговорим о чек-листах в тестировании.

Чек-лист

Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта.

________________________________
Чек-лист экономит время тестировщика и упрощает поддержку тестовой документации, но, с другой стороны, многие вещи при проверки остаются на совести тестировщика. Например, какой е-mail вводим, какой неправильный пароль и так далее
________________________________

Следовательно, если с чек-листом работают уже опытные тестировщики, то особых проблем не возникает. Если приходят новички и видят чек-листы, то они могут запутаться и неправильно проверить функциональность, потому что не будут с точностью знать, как правильно протестировать и какие данные вводить.

Как видите, чек-листы и тест-кейсы сильно упрощают процесс тестирования. Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать.

При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить. Достаточно один раз уделить немного больше времени на проверку и написать по ней тест-кейсы и чек-листы, чтобы потом экономить время при следующих проверках.

Но моим студентам все равно тяжело. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?

Идея 1

Я предложила им такое пояснение:

Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, "Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом. ", а не просто "Ну вот загрузили и все получилось".

Ребятам пояснение очень понравилось
Сказали, что так понятнее, так что заносим в теорию в картинках!

Идея 2

Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.

А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!

Мы, кстати, не осилили, оставили мастеру

Читайте также: