четверг, 7 августа 2014 г.

Что такое тест-кейс и как его писать

Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.

См также: Тест-кейс проверяет, а не доверяет!

Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.
Тест-кейс  это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план   это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)


Стандартные атрибуты тест-кейса
  1. Номер  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
  2. Название  краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
  3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
  4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
  5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").
См также:
Правила написания предварительных шагов в тест-кейсах — подробнее про пред шаги



Пример оформления (один ожидаемый результат)


Есть внутренний сайт компании, которая проводит интернет "Самый_лучший_в_своем_роде" — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru.
Примечание: www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему Smile :). Приводится здесь, чтобы показать ошибки в написании тест-кейсов.


На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди "извне", с логином и паролем test / test.


Тест-кейс № 1. Создание жильца без ФИО.

Шаги
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы".
  4. Нажать на кнопку "Создать карточку жильца".
  5. Нажать на кнопку "Сохранить", не заполняя никакие данные.
Ожидаемый результат
Появляется сообщение об ошибке "Заполните обязательные поля, отмеченные *", карточка не сохраняется.



Преимущества и недостатки тест-кейсов


Преимущества: тест-кейсы можно доверить выполнять новичку или призванному на помощь коллеге из другого отдела, который ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так (должно быть Wink ;) ) понятно!

Недостатки (вытекают один из другого):
  1. Очень много копипасты много копипасты копипасты. В примере выше заполняется поле "ФИО". Тест-кейсы "ввести в поле только символы, только числа, строку нулевой длины и т. д." будут очень похожи друг на друга, первые шаги одинаковые и, положа руку на сердце, будут копипаститься. Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему.
  2. Сложно поддерживать. Представьте, что вкладку "Жильцы" переименовали в "Заказчики". Чтобы актуализировать тест-кейсы, надо внести изменения в сотни сценариев, что утомительно даже в режиме "Ctrl + C, Ctrl + V".
  3. Неактуальное состояние. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.
Последний недостаток перечеркивает достоинства. Тестировщик, который уже год как работает на проекте, поймет и неактуальный кейс, тем более если выполняет их подряд, начиная с первого. А тестировщик, который ничего о проекте не знает и получил пару кейсов из середины тестового набора, не сможет понять, о чем в них идет речь.

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

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

См также:
Тест-кейсы – зло! Или все-таки нет? — перевод статьи John Andrews о преимуществах тест-кейсов.
Когда применять тест-кейсы — а когда они не нужны



Примеры оформления (несколько ожидаемых результатов)



Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле "ФИО" по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).

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


Несколько вариантов вводимых данных



Тест-кейс № 2Создание жильца, проверка поля "ФИО".

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Заполнить поле ФИО (см "Ожидаемый результат")
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат


Вводимое значение
Ожидаемый результат
Киселева Ольга Евгеньевна
Ок, карточка сохраняется
<Оставить поле пустым>
Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется
2*4*6*8*11*14*17*20*23*26*29*32*35*38*41*
Ошибка – «Максимальная длина поля – 40 символов, введено - 41», карточка не сохраняется. (Такую строчку легко сформировать с помощью инструмента perlclip)
&*%#(^$@*&
Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
Kiseleva Olga Evgenievna
Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!


Результаты для нескольких шагов из кейса


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


Тест-кейс № 3Создание жильца с худым полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести полные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой "Войти" и сообщением "Для входа в систему введите, пожалуйста, свои данные".

2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись "Здравствуйте, admin". Открыта главная страница сайта.

4. Открылась страница "Создание нового жильца" с полями "Фамилия", "Имя" и "Отчество" и кнопкой "Сохранить".

6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".


Ну что, приятно читать такой тест-кейс? )) Думаю, что в таком виде не очень. Обычно же читаешь и сразу выполняешь. Выполнил пункты 1,2,3... 10... А потом БАЦ, и в ожидаемом результате читаешь результат для пункта 1! Но подождите, я уже на пункте 6!

Это надо снова повторять тест-кейс, но теперь уже сравнивая результат. И глаза такие прыг-скок туда-сюда. Прочитали пункт 1 — прыг в результаты. Проверили — прыг обратно к шагам, ищем пункт 2. Выполнили — прыг глазами в результаты. Ищем там пункт 2, проверяем... Прыг снова в шаги, ищем пункт 3... Ну вы поняли.

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


В блоггере табличку хрен создашь, поэтому я ее сделала на конфлюенсе


Несколько проверок после одного сценария



Тест-кейс № 4Создание жильца с самым полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести полные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".



Области применения


Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию "чек-листы & тест-кейсы".

В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни "ДЕДЛАЙН!", только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:
  1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
  2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.
Тест-кейсы не нужны:
  1. Простые системы (веб-сайты, мобильные приложения и т. п.).
  2. Ситуации, когда в команде всего один или два тестировщика, знающие свой продукт. Время, потраченное на создание и поддержку тест-кейсов никогда не окупится.
Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее  — творческие чек-листы, формальные тест-кейсы или микс из этих подходов.



Стандартные ошибки при оформлении тест-кейсов


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

Тест-кейс № 01Создание жильца.

Шаги:
  1. Зайди на сайт www.test.ru.
  2. Нажми на кнопку "Войти" в правом верхнем углу экрана.
  3. Залогинься с правами администратора.
  4. Перейди на вкладку "Жильцы".
  5. Нажми на кнопку "Создать карточку жильца".
  6. Введи корректные ФИО, например, "Иванов Иван Иванович" и сохрани карточку.
Ожидаемый результат — карточка создана.








Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя Wink ;)











Разберем ошибки кейса 01.

1. Абстрактное название

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

В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?

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

2. Повелительное наклонение

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

3. PROD

В данном примере идет ссылка на PROD.

Никогда нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы . Тестовый набор для этого создается отдельно и тщательно выверяется.

ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и ... или сломает что-то, или испортит реальные данные.

4. Нет ссылки на сайт

Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить... Гораздо лучше было бы просто нажать на него!

5. Слишком детализировано

Пункт "Нажми на кнопку "Войти" в правом верхнем углу экрана" содержит много подробностей про пользовательский интерфейс. Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс. Чем меньше в документации зависимость от UI (user interface, пользовательский интерфейс), тем лучше.

Перепишем данный шаг: Войти под учетной записью администратора (admin/1)

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

6. Нет нужной информации - непонятно, как авторизоваться

Есть пункт "Залогинься с правами администратора" — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль.

Если такой пользователь присутствует всегда (или создается каждый раз для тестирования), то есть его логин и пароль "статические" (не меняются), то их всегда надо прописывать, чтобы не возникало дополнительных вопросов.

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

Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация.

7. Нет описания проверки

"Карточка создана" — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.

Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?


Поправим тест-кейс по всем замечаниям. Вот что получилось:

Тест-кейс № 02Создание жильца с корректными ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru.
  2. Войти под учетной записью администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести корректные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".








Уже хорошо, но можно ли еще улучшить этот тест-кейс?
Сейчас снова попробуйте, не смотря ответ, найти проблемные зоны в этом тест-кейсе. А потом проверите себя Wink ;)











Итак, ошибки кейса 02:


1. Абстрактное название.

Слова "корректный", "правильный" ит.д. в названии тест-кейса такой же маркер, как "ошибка" в названии бага. Таких слов надо избегать.

Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс.

Поэтому забудьте про слова "корректный", "некорректный" и т.п., пытайтесь писать понятнее. И всегда помните принцип "кратко, но емко". А разделение кейсов на смысловые группы (негативные тесты, позитивные тесты, тесты на особые случаи) сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов.

2. Нет нужной информации

Зайти на сайт www.dev_test.ru

Ок, я открываю этот сайт, а там авторизация. Как мне туда попасть?
Никак! Идти и узнавать логин/пароль. А зачем, если это легко было исправить указанием логина/пароля в скобках или ссылкой на страницу со всеми логинами и паролями (они все же могут меняться и лучше менять в одном месте)?


Исправленная версия тест-кейса:

Тест-кейс № 03Создание жильца с полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учетной записью администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести полные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".




А как вам такой тест-кейс?

Тест-кейс № 04Поиск по ФИО.

Шаги:
  1. Зайти на сайт http://example.com/ 
  2. В строку поиска вбить «Иван»
Ожидаемый результат

Вернулись все Иваны, поиск по ФИО работает.






Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя Wink ;)






Ну что, готовы читать ответ? В нем нам поможет статья «Тест-кейс проверяет, а не доверяет!». Ошибки кейса:

1. Название врет

Мы не проверили поиск по ФИО, мы проверили только поиск по имени. А это не одно и то же, если ФИО хранится в трех разных полях!

2. Нет подготовительных шагов

Что, если мы будем проводить тест на абсолютно пустой, «голой» базе? Я введу в строку поиска «Иван» и получу ничего, ведь искать тупо негде. Надо подготовить данные для проверки!

3. Результат абстрактный

А тест-кейс должен быть конкретным! Что значит «все Иваны»? А если «Иван» — не имя, а часть адреса, или комментарий к телефону, или кличка кота? Надо писать конкретно, про данные, которые мы указали в подготовительных шагах. Иначе получается ожидение в стиле «оно работает хорошо, а что такое хорошо — подумай сам».



Давайте перепишем этот тест:


Тест-кейс № 05Поиск по имени.

Предварительные шаги:

Создать в системе 2 пользователей с именами «Иван» и «Мария» (см тест-кейс «Создание пользователя»).

Шаги:
  1. Зайти на сайт http://example.com/ 
  2. В строку поиска вбить «Иван»
Ожидаемый результат

Нам вернулся «Иван», но не вернулась «Мария».





Определения из книг по тестированию


Ron Patton. Software Testing.
Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.
Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения.

Lee Copeland. A Practitioner's Guide to Software Test Design.
The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:
  • Test case specification identifier - A unique identifier so that this document can be distinguished from all other documents.
  • Test items - Identifies the items and features to be tested by this test case.
  • Input specifications - Specifies each input required by this test case.
  • Output specifications - Specifies each output expected after executing this test case.
  • Environmental needs - Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
  • Special procedural requirements - Defines any special setup, execution, or cleanup procedures unique to this test case.
  • Intercase dependencies - Lists any test cases that must be executed prior to this test case.
Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:
  • Идентификатор тест-кейса — уникальный идентификатор, благодаря которому данный документ может быть отличен от остальных.
  • Элементы теста — идентифицирует элементы и фичи, которые необходимо протестировать по этому кейсу.
  • Входные данные — описывает каждое входное значение, необходимое для выполнения тест-кейса.
  • Выходные данные — описывает каждый результат, ожидаемый после выполнения тест-кейса.
  • Окружение — любое специальное аппаратное, программное обеспечение, аппаратура и т.д., необходимое для выполнения тест-кейса и не перечисленное в документации по тест-дизайну (верхнеуровневая документация).
  • Особые процедурные требования — описывает любые специальные действия по подготовке к тесту, его выполнению или очистке системы после выполнения кейса.
  • Зависимости — список любых тест-кейсов, которые должны быть выполнены перед данным кейсом.

Гленфорд Майерс, Искусство тестирования программ

Любой тест должен включать две составляющие:
  • описание входных данных программы;
  • точное описание корректных выходных данных для каждого набора входных данных.

На этом, пожалуй, все Smile :)

PS - Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!

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

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

74 комментария:

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

    ОтветитьУдалить
    Ответы
    1. Спасибо за отзыв! :)
      Я подумаю о таком варианте, когда статья будет переписана не в этот блог! Хотя сомнительно, ведь исходно предполагается, что читатель попробует сам определить недостатки. Если же рядом будет исправленная версия, то так или иначе читатель ее увидит и прочитает, а значит, не сможет подумать сам...

      Разве что вынести в отдельную табличку ниже ))

      Удалить
  2. Всё никак не получается отправить коммент... каждый раз то инет отваливается, то ноут садится.
    Так вот.
    1. Абстрактные названия тесткейсов - настоящая головная боль, которую я часто сам себе устраиваю... есть такой грешок.
    2. На счет: "Зайти на сайт www.dev_test.ru
    Ок, я открываю этот сайт, а там авторизация. Как мне туда попасть?
    Никак!"
    Тут всё хуже обстоит. Это практически пример из (моей) жизни, когда на лицо не недостаток информации, а ввод в заблуждение. В кейсе сказано: "1. Зайти на сайт www.dev_test.ru. 2. Войти под учетной записью администратора (логин - admin, пароль - 1)"
    Лично я бы честно пытался ввести не test/test, а admin/1, будучи уверен, что форма авторизации сайта и есть та форма, в которую нужно зайти под админскими правами. По опыту скажу, если бы я увидел пустую форму и не знал бы что ввести - через 10 секунд я был бы уже у автора тест-кейса.... а в случае твоего тест-кейса, я бы минут 20 пробовал залогиниться, выяснял бы почему меня не пускает у разработчиков или, если бы у меня было плохое настроение, написал бы репорт об ошибке "Нельзя залогиниться под правами администратора, см. тест-кейс такой-то".

    ОтветитьУдалить
    Ответы
    1. О, кстати, да! Спасибо! :)
      И правда случай из жизни, когда двойная авторизация и написаны данные для входа в систему, а не на тестовый стенд - реально пытаешься их вбить для входа на стенд :)

      Удалить
    2. Можно еще написать http://test:test@www.dev_test.ru
      сработает и вопросов не будет лишних :)

      Удалить
    3. А вот это уже заблуждение :) Про "не возникнет вопросов" ;)

      Удалить
  3. > www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему
    Для примеров можно использовать example.org. Тогда не нужно объяснять, что это просто пример, а не новый сайт для тестировщиков.

    > Преимущества и недостатки тест-кейсов
    Как же так, нет упоминания эффекта пестицида?

    > Чтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — "Выполнить, загрузить"...
    Тут не соглашусь. Повелительное наклонение больше подходит для инструкций. А тест-кейс - это в некотором роде инструкция. Просто нужно использовать вежливый вариант: "Выполните", "Загрузите".

    ОтветитьУдалить
    Ответы
    1. Спасибо за домен для примера!
      Про эффект пестицида вы правы, добавлю)

      Вежливое повелительное наклонение, в принципе, допустимо, но обезличенное все равно лучше, ИМХО

      Удалить
    2. > Просто нужно использовать вежливый вариант: "Выполните", "Загрузите".
      Ничего подобного! В таких случаях дописывайте еще и "пожалуйста" или "будьте так добры" или "я Вас умоляю".
      Никогда не пишите "загрузите", "перейдите" и т.д. Только "загрузить", "перейти", "нажать" и т.д.

      Удалить
  4. Спасибо Ольга статья интересная!

    ОтветитьУдалить
  5. Ольга мне нужно 20 тест кейсов для програмы скайп пожалуйста зделайте!

    ОтветитьУдалить
    Ответы
    1. Тестовое задание кандидат должен делать сам :)

      Удалить
    2. А мне нужен новый ноутбук. Пожалуйста, "З"делай, грамотей...

      Удалить
  6. Мне вот интересно, как обычно пишут тест-кейсы на проектах: по одному тест-кейсу на каждый вид вводимых данных или как в примере "Несколько вариантов вводимых данных" с табличкой?
    Просто меня пугает мысль о том, сколько же вообще пишется тест-кейсов для одного реального проекта - миллион? :)

    ОтветитьУдалить
    Ответы
    1. Пишут так, как принято на проекте :)
      Если пока никак не принято и начальство решило вести документацию — предлагайте вести чек-листы, тогда трудозатрат меньше с тем же результатом :)

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

      Удалить
  7. Добрый день!
    Ольга, в одном тест кейсе шаги могут повторяться?

    ОтветитьУдалить
  8. Сейчас учусь писать тест-кейсы для формы регистрации на сайте, где есть 3 обязательных поля. Правильно ли я понимаю, что надо создать тест кейсы отдельно для правильных и неправильных данных для каждого поля? Или создавать тест кейсы для каждого поля? Например,1. Тест кейс с пустыми полями,2. Тест кейс с проверкой поля имя,2.

    ОтветитьУдалить
    Ответы
    1. Позитивные проверки можно комбинировать, негативные — нет. Иначе как вы узнаете, сообщение об ошибке "нельзя оставить поле пустым" на что среагировало?

      Удалить
    2. Спасибо! У Вас очень интересный и информативный блог)

      Удалить
  9. Добрый день! Как найти статью "про идиотов и ограничения"? Заинтриговали)

    ОтветитьУдалить
    Ответы
    1. Добрый! Что-то типа http://okiseleva.blogspot.ru/2015/07/pretty-roses.html
      Или http://okiseleva.blogspot.ru/2016/04/blog-post.html :)

      Удалить
  10. чем тест кейс отличается от баг репорта и чек листа?

    ОтветитьУдалить
    Ответы
    1. От чек-листа → http://testbase.ru/411
      От баг-репорта... Ну, вначале вам стоит почитать, что такое баг-репорты :)

      Удалить
    2. Обьясните пожалуйста, если Вам не трудно. После прочтения возникают непонятки.

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

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

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

      Удалить
    3. Тест-кейс — это что мы тестируем.
      Баг-репорт — это описание бага. Как описывать баги, можно почитать в соответствующем навыке — http://testbase.ru/?post_type=skill&p=57

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

      Удалить
    4. хорошо, допустим я с помощью тест кейса тестирую программу и нахожу баг, что дальше я с ним должен делать? Описать его в баг-репорте?

      Удалить
    5. Если это действительно баг — то да, перенести в баг-репорт

      Удалить
    6. теперь все стало понятно, большое спасибо за промощь

      Удалить
    7. Появился еще один интересный вопрос:
      1. Я исполнил тест кейс и нашел баг
      2. Занес его в баг-репорт
      3. Программист его исправил и теперь мне как тестировщику надо провести регресивное тестирование этого бага.
      4. Дальше возникает вопрос:
      Мне нужно проводить повторное тестирование по шагам из тест-кейса или из баг-репорта? Или шаги в них получается должны быть одинаковыми?
      Айди тест кейса и баг репорта должны быть одинаковыми?

      Удалить
    8. Тест-кейс и баг-репорт → это РАЗНЫЕ сущности.
      Если вы проверяете баг, вы проверяете баг. И копаете рядом (вдруг что задел разработчик). Тест-кейсы вам в данном случае вообще не нужны.

      Удалить
  11. Добрый день.
    Такой вопрос - какой должен быть тест кейс для фильтра значений?
    Например - в поле ввода пользователь вводит строку и на выходе должны быть все те значения, в которых есть эта строка.
    По идее у нас две тестовых ситуации - строка, которая входит в какое-либо значение и мы проверяем что это значение верное, и негативный тест где строка не входит и тогда значений будет ноль. Но нужно ли проверять на разные типы данных? Или на разное количество выходных данных? Сколько тогда должно быть тест кейсов?
    Еще интересует проверка ряда чекбоксов - например при всех отмеченных чекбоксах параметр n=5. Убираем чекбоксы - уменьшается параметр и наоборот.Сколько в этом случае должно быть проверок? Отметить все чекбоксы и убирать по одному и проверять параметр, а потом убрать все чекбоксы и добавлять по одному параметру? Крайних значений тут нет, а по комбинаторике возможных комбинаций может быть очень много. Как быть?

    ОтветитьУдалить
    Ответы
    1. Добрый день!
      Кейсы "нашли-не нашли" → основные. Но есть и другие классы эквивалентности. если ничего не выбирать? А если результат будет один? А если 100? А если 1000? А если результат из разных категорий товаров? А если из одной? А если наложить фильтры? Итд.
      А вот по поводу чек-боксов очень любопытно, откуда возник вопрос))

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

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

      Удалить
    3. И границы в том числе, конечно. Но не во всех классах эквивалентности они есть. Посмотрите тут — http://okiseleva.blogspot.ru/2015/07/blog-post_87.html — пример с Иваном. Это же не граница, но отдельный класс.

      По поводу чек-боксов погуглите pairwise) Он еще на курсе Алексея Баранцева про тест-дизайн проходится http://software-testing.ru/trainings/catalogue/online/113-td

      Удалить
  12. Ольга, вопрос по тестированию регистрации, помогите разобраться, пожалуйста. Пишу тест-кейс, хочу проверить регистрацию с именем на кирилице, на латинице. Значения всех полей нужно указывать конкретные, а значит "введите логин такой-то", эл.почту "такую-то". Когда в реальности этот кейс начнут выполнять живые люди, то его сможет пройти только первый человек, второму не зарегистрироваться под указанным логином и с указанной почтой, они будут заняты первым прошедшим кейс. Предполагаю, что нужно придумать некую формулу, которая будет отличаться номером выполняющего кейс, например, для первого логин login1 почта login1@ya.ru, для второго login2 и так далее. А как на практике тестируется форма регистрации?

    ОтветитьУдалить
    Ответы
    1. Для почты можно использовать гугловый лайфзак — http://okiseleva.blogspot.ru/2014/08/email.html
      К логину да, тоже можно прибавлять цифры, почему бы и нет?

      Удалить
  13. Добрый день) Подскажите,нужно протестировать форму отправки сообщения из 4-х полей: Имя, Ном.тел, Email, Сообщение. Набор позитивных и негативных данных для каждого поля составлен.
    Имя:позитивные:
    1)мин.длина,русск.язык, смешанный регистр;
    2)мах длина, смешанный регистр, пробел;
    3)дефис, апостроф, англ.язык, укр.язык.
    негативные:
    1)пустое значение;
    2)меньше мин. значения;
    3)больше мах;
    4)спец. символы, знаки препин., цифры.

    Номер тел:позитивные:
    1)10 цифр;
    негативные:
    1)пустое значение;
    2)длина меньше мин.;
    3)длина больше мах;
    4)спец символы, буквы.
    и т.д.для еще двух полей.

    Тест-кейс позитивный:
    Название: Тест отправки сообщения
    Функция: Контакт-Вопросы

    Шаги
    1. Открыть форму отправки сообщения
    ОР:
    - форма отправки сообщения открыта
    - на форме 4 поля: Имя, Номер телефона, Email, Примечание
    - все поля по умолчанию пусты
    - обязательные поля помечены - *
    - Кнопка «Отправить» активна

    2. Заполнить поля формы:
    «Имя»: Ия
    «Номер телефона»: 0502621058
    «Еmail»:
    7cncncncncncncnccnnccncncncncncccnccncncnc.flflflflflflflfflflflflflflfflflflflflfflflflflflfflflfllffllfllf.SKSKSKSKSKSKSKSKSKSS@5slsllslslslslslsllsslslslslsslslsllslslslslslslsslsllsslsllssllslslslslslslslslslslssl.EPPEEPEPEPPEEPPEPPEEPEPPEPEPE.mail.ru
    «Примечание»: укр*%
    ОР:
    - поля заполнены
    - кнопка «Отправить» активна

    3. Нажать кнопку «Отправить»
    ОР:
    - страница «Ваш запрос успешно отправлен» открыта

    негативный тест кейс:
    Название: Тест отправки сообщения
    Функция: Контакт-Вопросы

    Шаги:
    1. Открыть форму отправки сообщения
    ОР:
    - форма отправки открыта
    - на форме 4 поля: Имя, Номер телефона, Email, Примечание
    - все поля по умолчанию пусты
    - обязательные поля помечены - *
    - Кнопка «Отправить» активна

    2. Заполнить поля форы:
    «Имя»: р
    «Номер телефона»: 050987654
    «Еmail»: fjjfjfjfjfjfjfjfjfjfjjfjfjfjodododododooddoododododoofufusuusususususu
    «Примечание»: ркркркрармаомщшаопрпоппалплпопопопопоопопоопопопоопопоопопопопоопопопоопопопопоопопопоппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппопопопопопоппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппрапарараааааа
    ОР:
    - поля заполнены
    - кнопка «Отправить» активна

    3. Нажать кнопку «Отправить»
    ОР:
    - Валидационное сообщение со всеми ошибками выведено на экран:
    - «Поле «Имя» обязательное для заполнения»
    - «Поле «Номер телефона» обязательное для заполнения»
    - «Поле «Email» обязательное для заполнения»
    - «В поле «Примечание» мах длина поля – 255 символов»

    Вопросы:
    1. Исходя из вашей статьи, как в данном случае правильно оформить тест кейс: с несколькими ОР для каждого шага, как я или несколько вариантов вводимых данных для одного выбранного поля отдельно, а остальные поля любые позитивные и сразу ОР в табличке (в таком случае, где должен быть ОР - после 3 шага нажать кнопку "Отправить" или после 2 шага "Заполнить поля формы")?
    Заранее спасибо большое за ответ.
    2. Как назвать позитивные тест кейсы (их будет несколько),если значения подставлены в каждое из 4-х полей, а не в одно. Название получится:
    "Тест отправки сообщения, мин.длина, смешан.регистр в поле "Имя", доп.длина в поле "Номер тел", мах длина,смешанный регистр,с цифры в локале, с цифры в домене,несколько точек в локале и домене в поле "Email",мин. длина, спец. символы в поле "Примечание"", совсем не кратко.
    3. Можно ли подставлять во все 4 поля негативные данные одновременно (по идеи валидация должна выскочить на каждом поле отдельно)? Валидация выскочит когда будут введены данные или когда будет нажать кнопка отправить?





    ОтветитьУдалить
  14. Добрый день!
    У вас довольно странные представления о позитивности имен :) Я бы рекомендовала посмотреть https://www.youtube.com/watch?v=3-5RbtRaYnk

    Но если по вашим вопросам:
    1. Нет единого "правильного" описания. Можно написать один тест-кейс с ОР на каждый шаг, а можно 5. Но, если вы пишщите ОР на каждый шаг, пишите внятно — сделайте табличку. Так, чтобы результат был напротив шага. Иначе я выполняют раз-два-три-четыре-пять шагов и вижу в результате "на первом шаге открылась страничка А" о_О

    2. Можно сделать один базовый позитивный тест, а потом рассматривать каждое поле в отдельности. Запихивать вот эту строку в название тест-кейса не стоит)) Нечитаемо получится. Вообще я бы сделала чек-лист, у вас точно просят тест-кейсы?

    3. Если сгруппировать негативные проверки — как вы узнаете, какая из них сработала? Может, работает только 1 из 3, но вы проверили все три разом, увидели ошибку и успокоились :)

    ОтветитьУдалить
  15. почему ожидаемый - ER - пишете в тесткейсе, а актуальный - AR - не пишете? если тесткейс длинный, то очень неудобно с такими работать.

    ОтветитьУдалить
    Ответы
    1. Потому что ыя говорю о том, как написать тест-кейс, а не о том, как его пройти =) "Актуальный" результат актуален ровно сегодня, уже завтра его результат мало о чем говорит, только "не падало ли раньше"

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

      Удалить
    3. Любой тест-кейс показывает багу? Они не для этого создаются. И рекомендую работать не с кодерами, тогда и проблем не будет :)

      Удалить
  16. просто удивительно, что в ваших тест кейсах нет таких понятий как AR и ER, надеюсь, что в будущем вы пересмотрите свои взгляды.

    ОтветитьУдалить
    Ответы
    1. не смогла мимо пройти) а багов у вас нету что ли?) AR = ER в благополучном случае, а если AR <> ER, то это баг! и когда вы создаете баг, вы либо копипастите свой тест кейс, либо система сама вам все шаги показывает! Вы задолбаетесь каждый раз писать AR. Что за систему вы используете для тест-кейсов, чтобы вам удобно было видеть AR?

      Удалить
  17. Но вообще я не за этим заглянуло. Относительно форм в команде возникла полемика. Одни утверждают, что содержание формы (какие поля должны быть у формы) необходимо держать отдельно от тест-кейса, в документации/еще где-нибудь. Другие считают что поля формы следует описывать в тест-кейсе, то есть это и есть наш кейс, где мы проверяем что форма такая как мы хотели.
    Что вы думаете на этот счет? я искала инфу в англоязычном инете, но не нашла - все обсуждения в основном как тестировать поля (ну а это мы и без подсказок умеем), так что это больше вопрос тест-дизайна скорее.

    ОтветитьУдалить
    Ответы
    1. Правы все! Потому что как принято на проекте, так и делаем.
      Лично я считаю, что если начинается полномасштабный уход от тест-кейса в плане кучи ссылочек "открой личный кабинет, см тут где его искать. Введи данные, вот ссылка с тестовыми данными" итд → то, может, тест-кейсы вообще не нужны, а нужен чек-лист?

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

      Удалить
  18. Оля, спасибо тебе за твой блог. У тебя так много ценной информации, описанной доступным языком.

    ОтветитьУдалить
  19. Ольга, спасибо большое! Стало гораздо понятнее, особенно с примерами и исправлением ошибок.

    ОтветитьУдалить
  20. Оля, а можешь, пожалуйста, дать ссылку, где ты пишешь про тест-план?

    *спасибо за блог :*

    ОтветитьУдалить
    Ответы
    1. А я пока нигде не пишу, у меня нет такого поста))
      Но вот рекомендую эту статейку — http://software-testing.ru/library/testing/test-analysis/2405-the-one-page-test-plan

      Удалить
  21. Добрый вечер!
    Задача: сделать тест-кейс на фичу следующего плана. Имеется карта на которой расположены объекты, наша геопозиция так же присутствует, при наведении на объект расположенный на карте мне показывается расстояние от меня до данного объекта! Вопрос: как бы вы составили тест-кейс ну и в конце концов протестировали данную функцию!?

    Заранее благодарен за ответ!

    ОтветитьУдалить
    Ответы
    1. Решать тестовое задание за вас никто не будет)

      Удалить
    2. это не тестовое задание!Ну или если можно так сказать, это тестовое задание которое я сам для себя придумал!!!
      Осваиваю профессию QA! сейчас сделал для себя практический эксперемент, установил триалы жиры и тестреил, взял просто сайт в интернете, придумал для него легкое ТЗ и хочу по нему практически потренироваться, теории прочитал достаточно, хочется практики ))

      Удалить
    3. За практикой под присмотром опытного — это на курсы. Но можете попробовать написать на https://software-testing.ru/forum/, однако и там никто ничего за вас делать не будет. Осваиваете профессию? Вперед, попробуйте сделать свою практику сами и выносите на форум «посмотрите, что у меня получилось», а не «сделайте за меня»

      Удалить
  22. Хотелось бы спросить, а почему все таки нельзя ограничивать поля воода ФИО? Коллеги не знают, рук. Тоже, разрабы разводят руками, в гугле этого нет, а пытливый ум теперь уснуть не даст... так вот вопрос - ПОЧЕМУ?. Если не трудно, пришлите ответ на 89206574501@mail.ru ,буду очень благодарен, заранее спасибо, have a good day

    ОтветитьУдалить
  23. Слово "корректный" в итоговом тест-кейсе № 03 все также присутствует. Наверное опечатка.

    ОтветитьУдалить
  24. Опечатка:
    Тест-кейс № 2. и Тест-кейс № 4.
    ...
    "2. ... (логин - admin, , пароль - 1) ..."
    Лишний пробел и запятая

    ОтветитьУдалить
  25. Спасибо за статью, возник вопрос по повторяющимся данным тест-кейсов, в статье в каждом тк есть данные для входа (логин и пароль), а если я пишу например тест-комплект с тестами, внутри которых есть так же данные для входа - могу ли я вынести их в шапку тест-комплекта (значение логина и пароля), а в тк писать смотри информацию шапки тест-копмлекта, чтобы уменьшить копипасту? Ведь если я напишу в каждом тк зайти по логину такому то и паролю такому то, а завтра у меня поменяется логин и пароль, то мне придется в каждом тк это менять, что займет гораздо больше времени, чем если бы я просто вынес данные для авторизации отдельно, или же все же лучше писать в каждом тк данные, так как любой тк должен быть независим и выполнен отдельно кем угодно? Спасибо за ответ

    ОтветитьУдалить
    Ответы
    1. Вы можете делать так, как комфортно вашей команде и вам.
      И да, обычно тестовые данные куда-то выносят и просто дают туда ссылку, потому что это самая переменчивая часть)

      Удалить
  26. http://www.dev_test.ru/ - This site can’t be reached

    ОтветитьУдалить
    Ответы
    1. Так вы вчитайтесь в его название)) Это просто пример ссылки

      Удалить
  27. (тут будет ссылка на... - ссылок так и нет :)

    ОтветитьУдалить
  28. Здравствуйте, Ольга!
    А теперь этот сайт недоступен?
    ...Зайти на сайт www.dev_test.ru
    На запрос выходит сообщение:

    Страница не найдена
    Если вы искали на ней что-то конкретное,
    спросите об этом Яндекс:

    http://www.dev_test.ru/

    Техническая информация: ошибка dnserror

    ОтветитьУдалить
    Ответы
    1. А он никогда и не был доступен, это же просто пример ссылки

      Удалить