Тест кейс

Пишем максимально эффективный тест-кейс

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

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

Зачем нужны тест-кейсы?

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

Атрибуты тест-кейса

Любой тест-кейс обязательно включает в себя:

  • Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
  • Название — основная тема, или идея тест-кейса. Кратное описание его сути.
  • Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
    Например, оставить комментарий на вашем портале может только зарегистрированный пользователь. Значит для тест-кейса «Создание комментария» будет необходимо выполнение предусловия «пользователь зарегистрирован», и «пользователь авторизован»
  • Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
  • Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.

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

Что еще необходимо знать, перед созданием тест-кейса?

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

Чего не должно быть в тест-кейсе

1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.
Первого следует избегать, потому что: связанный тест-кейс всегда может быть удален из-за ненадобности или он может быть изменен, в этом случае, станет непонятно как исполнить тест-кейс в которому, есть ссылки.
Так же из-за зависимости тест-кейсов, может возникнуть ощущение, что тестируемый продукт уже приведет к нужному состоянию благодаря выполнению связанных тест-кейсов.
Со вторым думаю все ясно. Если описание шагов или ожидаемое результата будет не четким, то это блокирует прохождение тест-кейса.

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

Home

Алексей Лемешко

Статья была переработана с учётом полученной в форуме критики и рекомендаций.

Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения — процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.

Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные — пишут правильно. Но

не все так просто как мне казалось.

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

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

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

  1. Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.
  2. Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).
  3. «Позитивное» тестирование. На этой, третей стадии, надо проверить результат работы приложения при получении им «правильных» входных данных.
  4. «Негативное» тестирование. Это четвертая, завершающая, стадия начального тестирования. Тут надо посмотреть, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом.

Итак, рассмотрим все по порядку.

Спецификация, требования, SRS.

Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?

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

Документация дает возможность понять для себя основные ступеньки проверки приложения, где и как должно приложение работать, где «ломаться». И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке.

Документацию всегда полезно держать перед глазами.

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

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

Процесс тестирования

Этот процесс можно описать следующими шагами:

  1. Проверить, как работает приложение, когда оно получает на вход «правильные» данные (чтоб узнать «что такое хорошо и что такое плохо» читаем документацию);
  2. Если все работает и работает правильно (т.е. именно так как описано в спецификации), следующим шагом является проверка граничных значений (т.е. там, где начинаются «правильные» данные и там где они заканчиваются);
  3. Проверка работы приложения при вводе данных, которые не входят в область допустимых значений (опять таки, смотрим спецификацию).

В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.

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

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

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

Однако предшествовать «позитивному» и «негативному» тестированию должны работы по выполнению «дымового» тестирования.

«Дымовое» тестирование — это быстрое, неглубокое, на наиболее простых или типичных сценариях, с минимумом проверок (чтобы только дыма не было). Оно может выполняться как на «позитивных», так и на «негативных» данных.

Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:

  • рудиментарная форма тестирования программного продукта после изменения его конфигурации либо после изменения его (программного продукта) самого. В процессе дымового тестирования тестировщик проверяет ПО на наличие «дыма», т.е. ищет какие-либо критические ошибки программы;
  • первый запуск программы после её критического изменения или «сборки».

Приоритеты в тестировании

Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?

Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то …».

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

Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».

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

Впрочем, это не означает, что «негативными» тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.

Резюме

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

Желаю удачи.

>Спасибо:

А. Баранцеву и В. Панкратову за консультации.

Киселева Ольга, автор и ведущий тренинга Онлайн-интенсив для начинающих тестировщиков.

Тест-кейс — это проверка. «Выполни тест-кейс по вводу отрицательных значений» = проведи проверку такую-то и проверь, что результат будет такой-то.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

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

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

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

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

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

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

Шаги

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

Ожидаемый результат

Появляется сообщение об ошибке «Заполните обязательные поля, отмеченные *», карточка не сохраняется.

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

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

Недостатки (вытекают один из другого):

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

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

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

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

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

Рассматриваем все тот же абстрактный сайт 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. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

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

Тест-кейс № 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. Введи корректные ФИО, например, «Иванов Иван Иванович» и сохрани карточку.

Ожидаемый результат — карточка создана.

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

Разберем ошибки кейса 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. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Уже хорошо, но можно ли еще улучшить этот тест-кейс?

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

Итак, ошибки кейса 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. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

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

Ron Patton. Software Testing.

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

Lee Copeland. A Practitioner’s Guide to Software Test Design.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

  • Идентификатор тест-кейса — уникальный идентификатор, благодаря которому данный документ может быть отличен от остальных.
  • Элементы теста — идентифицирует элементы и фичи, которые необходимо протестировать по этому кейсу.
  • Входные данные — описывает каждое входное значение, необходимое для выполнения тест-кейса.
  • Выходные данные — описывает каждый результат, ожидаемый после выполнения тест-кейса.
  • Окружение — любое специальное аппаратное, программное обеспечение, аппаратура и т.д., необходимое для выполнения тест-кейса и не перечисленное в документации по тест-дизайну (верхнеуровневая документация).
  • Особые процедурные требования — описывает любые специальные действия по подготовке к тесту, его выполнению или очистке системы после выполнения кейса.
  • Зависимости — список любых тест-кейсов, которые должны быть выполнены перед данным кейсом.

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

Любой тест должен включать две составляющие:

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

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

PS — Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!
PPS — Уже скоро стартует мой курс Онлайн-интенсив для начинающих тестировщиков, в котором мы будем практиковаться составлять тест-кейсы, более полезные чек-листы и прочими полезными вещами! Записаться на курс 1-7 сентября.

Позитивное и негативное тестирование

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

Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Например, умножение на калькуляторе цифр 3 и 5.

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

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

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

Сегодня нет точного и единого мнения о соотношении позитивного и негативного тестирования.

Существует мнение, согласно которому позитивное тестирования считается более важным, чем негативное.

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

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

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

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

Теперь давайте отложим наш виртуальный калькулятор цифр и фруктов, и рассмотрим несколько реальных примеров тестовых кейсов.

Классический пример логина/логаута:

  • регистрация: ввод логина и пароля, с логином без пароля, через социальные сети;
  • авторизация: ввод логина и пароля, вход через социальные сети;
  • восстановление пароля.

Позитивные сценарии:

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

Негативные сценарии:

  • повторная регистрация (имя/пароль уже заняты);
  • регистрация без заполнения обязательных полей (все поля пусты);
  • регистрация с вводом данных в неверном формате;
  • авторизация с неверным логином/паролем.

И еще один пример создания простого контакта (присутствует возможность просмотра, редактирования и удаления):

Позитивные сценарии:

  • доступны функции создания, редактирования, просмотра и удаления контакта;
  • доступна функция создания контакта при заполнении минимального количества обязательных форм;
  • доступна функция создания контакта при заполнении всей формы;
  • просмотр контакта доступен после создания и соответствует нормам ТЗ;
  • изменения вступают в силу после сохранения (отображаются обновленные данные);
  • после удаления контакта больше нет.

Негативные сценарии:

  • создание одинаковых контактов невозможно;
  • создание контакта без заполнения обязательных полей невозможно;
  • и т.д.

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

  1. Внутренние одинарные кавычки в запросах SQL.

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

  2. Обязательные поля для ввода данных.

    В основном поля, обязательные для ввода данных, обозначаются специальным символом “*”, что говорит пользователю о том, что эти поля необходимо обязательно заполнить. Это и является первой проверкой – убедиться, что все обязательные поля отмечены. Второе – убедиться в том, что отмеченные поля действительно определяются системой как обязательные. В рамках данных проверок нужно убедиться, что такие поля действительно нельзя пропустить. Достаточно оставлять такие поля пустыми при отправке формы и наблюдать за поведением системы. Если пользователь получает ошибку о необходимости заполнения поля, то данный сценарий будет считаться успешным. Соответственно, если форма отправляется даже без заполнения обязательного поля, то данный сценарий неправильный и должен быть занесен в багтрекинговую систему. Представим ситуацию, при которой пользователь при регистрации не вводит почтовый адрес или пользовательское имя, и система все равно успешно регистрирует данного пользователя. Соответственно, такой пользователь не сможет войти в систему, так как ранее он не вводил данные, которые обязательно требуются при авторизации. Обратная сторона данных проверок – убедиться в том, что опциональные поля не обязательны к заполнению и форма может быть отправлена без них.

  3. Типы данных в полях.

    При проверке полей ввода данных нужно понимать, что такие поля могут отличаться тем, данные какого формата они принимают. Например, текстовое поле подразумевает то, что оно принимает любой текст. Здесь можно сделать несколько основных проверок. Во-первых, проверить лимит на ввод символов. Часто разработчики не выставляют лимит на символы. Как результат, при вводе длинного имени, например, такой текст будет неправильно отображаться в других секциях приложения/сайта (выходить за пределы блока, перекрывать другой текст и т.д). Это очень распространенная проблема. Во-вторых, мы должны понимать назначение данного текстового поля. Разница между полем никнейма и имени пользователя существенная. Поле никнейма может принимать любой набор символов, включая цифры и специальные символы. Поле же имени должно принимать только буквы. Также в странах Европы и США принято имя и фамилию обьединять под одним понятием “Full name”. Поэтому это поле должно принимать минимум два слова, разделенных пробелом. Еще стоит учитывать рынок, на который ориентируется продукт. Ведь в тех же французском и немецком языках в именах используются дополнительные символы (известны как “умляуты”). И поле ввода должно принимать эти символы. Для числовых полей и полей выбора даты также работают свои правила. Числовое поле не должно принимать других знаков, кроме чисел. Введенная или выбранная дата должна отображаться в правильном формате и т.д.

  4. Размер поля.

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

  5. Числовые граничные значения.

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

  6. Числовые ограничения.

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

  7. Граничные значения даты.

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

  8. Валидность даты.

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

  9. Веб сессии (только для веб приложений).

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *