Главная
Кейс лист: Тест кейс VS чек лист — Тестирование и обеспечение качества | Тестировщик | Radar4site.ru

Кейс лист: Тест кейс VS чек лист — Тестирование и обеспечение качества | Тестировщик | Radar4site.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 вводим, какой неправильный пароль и так далее
________________________________

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

***

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

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

Что такое тест кейс: пример и чек-лист тест кейсов для начинающих тестировщиков, которые подойдут каждому

В этом материале о тест кейсах вы узнаете:

  1. Что такое тест кейс
  2. Из чего состоит тест кейс и какая у тест кейсов форма
  3. Правила написания хорошего тест кейса
  4. Типичные ошибки в тест кейсах

Что такое тест кейс

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

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

Хотите научиться писать правильные тест кейсы? Научиться писать тест кейсы вам помогут наши менторы-тестировщики!

Форма тест кейса: из чего состоит тест кейс и поля в тест кейсах

У стандартного тест кейса есть 5 частей, то есть 5 атрибутов тест кейса:

  1. Порядковый номер тест кейса
  2. Название тест кейса. Из него должно быть понятно, в чем суть тест кейса
  3. Предусловия тест кейса. Это условия, которые необходимы для проведения тест кейса. Они должны быть выполнены еще до запуска тест кейса.
    Допустим: компания сдает самокаты в поминутную аренду. Нужно провести тест кейс функции, которая уведомляет пользователя о том, что заряд аккумулятора самоката. Предусловием тест кейса будет то, что самокат должен находиться в состоянии аренды
  4. Порядок действий в тест кейсе и описания действий в тест кейсе
  5. Ожидаемый результат тест кейса.

Вот пример тест кейса:

Тест кейс №1
Название тест кейса: Уведомление пользователя о снижении заряда аккумулятора вручную
Предусловия тест кейса: статус самоката: в аренде
Шаги тест кейса:

  1. Шаг тест кейс №1: Зайти на сайт samokat.admin

    Логин — test, пароль — test

  2. Шаг тест кейса №2: Перейти на вкладку «Самокаты в аренде»
  3. Шаг тест кейса №3: Нажать…
  4. Шаг тест кейса №4: Включить…
  5. Шаг тест кейса №5: …
  6. Ожидаемый результат тест кейса

    Появляется сообщение об успешном выполнении тест кейса «Пользователь уведомлен о снижении заряда»

Как написать хороший тест кейс: правила и форма хороших тест кейсов

У тест кейса может быть 3 вида результатов:

  1. Положительный результат тест кейса. Фактический результат тест кейса совпадает с ожидаемым.
  2. Отрицательный результат тест кейса. Фактический результат тест кейса отличается от ожидаемого.
  3. Тест кейс не завершен. В процессе проверки тест кейса происходит ошибка.

Существуют 6 правил проведения тест кейсов:

  1. Один тест кейс должен проверять только одну конкретную вещь.
  2. Тест кейс не должен зависеть от других тест кейсов.
  3. Шаги и ожидаемый результат тест кейса должны быть сформулированы четко и однозначно.
  4. В тест кейсе должна быть вся информация. необходимая для его проведения.
  5. В тест кейсе не должно быть лишних деталей.
  6. Для каждого шага тест кейса нужно указывать тип вводимых данных: валидный или невалидный.

Прочитайте статью Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила!

Типичные ошибки при написании тест кейсов

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

Плохо: Уведомление пользователя о заряде
Хорошо: Уведомление пользователя о снижении заряда аккумулятора вручную

Повелительное наклонение в тест кейсе
Это правило этикета тестировщиков.

Плохо: зайди на сайт; нажми на кнопку
Хорошо: зайти на сайт, нажать на кнопку

Не кликабельные ссылки
Не важно, это гиперссылки внутри вашей площадки или ссылки на какие-то внешние ресурсы. Вставили ссылку — нажмите «Ctrl + K». Добавьте тексту кликабельности.

Плохо: yandex.ru
Хорошо: yandex.ru

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

Плохо: нажмите на красную кнопку с надписью «Войти» в верхнем правом углу экрана, под меню.
Хорошо: нажмите на кнопку «Войти»

Недостаток деталей для проведения тест кейса
Ошибка, обратная предыдущей. Хороший тест кейс — это тест кейс, все действия которого можно выполнить, основываясь только на тексте самого тест кейса.

Плохо: перейти в режим разработчика
Хорошо:
1) Открыть меню
2) Перейти во вкладку «Дополнительные возможности»
3) Нажать на кнопку «Включить режим разработчика»

Хотите избежать типичных ошибок в тест кейсах? Вам помогут наши менторы-тестировщики!

Единая судебная система Пенсильвании

Внимание! В вашем браузере отключен JavaScript. Пожалуйста, включите JavaScript, чтобы в полной мере использовать этот сайт.

Наша навигация по меню изменилась. Кликните сюда, чтобы узнать больше.


AOPC будет проводить техническое обслуживание системы с 17:00 до 20:00 в воскресенье, 16 апреля, в результате чего многие функции портала будут недоступны. Отключение затронет как общедоступных, так и защищенных пользователей сайта. Благодарим вас за терпение и приносим извинения за возможные неудобства.

Справка

Судебное дело
Листы регистрации
Общедоступные веб-листы

Опция Public Web Docket Sheets обеспечивает доступ к поиску, просмотру и печати ведомостей для Пенсильвании. Апелляционные суды, уголовные суды общей юрисдикции, Мировые окружные суды и Муниципальный суд Филадельфии. Кроме того, для уголовных судов по общим делам и дел муниципального суда Филадельфии доступен сводной информационный отчет о суде.

Защищенные веб-листы

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

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

Полный список судебных округов и округов Пенсильвании.

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

Календари
Расписание общедоступного календаря

Параметр Расписание общедоступного календаря обеспечивает доступ к поиску, просмотру и печати событий дела, запланированных в расписании. Уголовные суды по общим делам и Мировые районные суды. Эта функция полезна, чтобы узнать, когда и где будет слушаться дело, без необходимости звонить или посещать здание суда.

Расписание защищенного календаря

Опция Secure Calendar Schedule обеспечивает доступ к поиску, просмотру и печати дел, запланированных в уголовных судах по общим делам и окружных мировых судах. Защищенная версия предоставляет дополнительные параметры поиска, недоступные для общественности, для поиска информации о расписании дел. В расписании безопасного календаря также перечислены все участники дела и указано, требуется ли присутствие на событии дела. Для доступа к этой услуге требуется безопасный вход в систему.

Титульный лист земельных книг и заявление на предварительный расчет платы

  1. Дом