Урок 1 из 0
В процессе

Тест-кейсы и сценарии

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

Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.

Чек-лист (check-list) – набор идей тестов.

Кроме них ещё существует понятие тест-сьюита или тестового сценария – это набор тест-кейсов, собранных в группу (последовательность) для достижения некоторой цели.

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

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

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

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

Функциональные тесты: включить ручку, переключить в рабочее положение, написать несколько слов, переключить в нерабочее положение, извлечь стержень.

Сравнительные тесты: что мы можем сказать об этой ручке в сравнении с другими ручками, которые выпускает наша фирма?, что мы можем сказать об этой ручке в сравнении с ручками, которые выпускают конкуренты?, в чём преимущества именно этой модели ручек?.

Тесты ошибочных ситуаций: что произойдёт, если препятствовать выходу стержня в рабочее положение? Какое усилие и где надо приложить к ручке, чтобы её сломать? Если стержень застрял, легко ли его извлечь? Что произойдёт, если писать по стеклу, асфальту?

Тесты интерфейса: Измерения: высота, ширина, длина, вес; Цвет; Читаемость логотипа фирмы-производителя.

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

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

Стрессовые тесты: При какой температуре расплавится пластиковая часть ручки? При какой температуре потечёт стержень? Какое воздействие необходимо применить к ручке, чтобы сломать её? Пишет ли ручка под водой? А по мокрой бумаге?

Тесты производительности: Сколько текста можно написать ручкой в единицу времени? Как быстро ручку можно привести в рабочее положение? Как много раз ручку можно переключить из нерабочего в рабочее положение, прежде чем её начнёт заедать?

Если не записывать и не структурировать идеи в чек-листе, то уже через несколько минут идеи начнут путаться, теряться и искажаться. Без чек-листа перейти к написанию тест-кейсов нельзя.

Техники тест дизайна

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

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: дети ­– младше 15 лет, студенты – от 15 до 25 лет, взрослые – старше 25 и младше 60 лет и пенсионеры – люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет невозможно.

Так как для проверки работы скидки нужно выбрать всего лишь 5 различных возрастов из разных категорий (например, 10, 18, 35 и 75 лет), нет необходимости писать 99 тестов для всех значений и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), но такие проверки обязательно нужно делать, чтобы не допустить ввода не правильных данных.

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

Граничные значения

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

Она вытекает из метода эквивалентного разбиения, из-за чего часто используется с ним в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

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

 

Таблица принятия решений

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

Здесь есть несколько возможных сценария:

  • Правильный логин и правильный пароль.
  • Правильный логин, неправильный пароль.
  • Неправильный логин, правильный пароль.
  • Неправильный логин, неправильный пароль.

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

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

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

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

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

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.

Пример:

Нужно протестировать совместимость браузеров Opera и Google Chrome и операционных систем Windows и Linux на русском и английском.

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

Все это можно просчитать и вручную, но в случае, когда вариантов будет много – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT).

Для проведения тестирования тестировщик создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли и их можно экспортировать в exel. Также существуют аналогичные приложения доступные online.

 

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera

ОС: Windows, Linux

Язык: RU, ENG

Причина и следствие

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

Примерный алгоритм использования техники:

  1. Выделяем причины и следствия в спецификациях.
  2. Связываем причины и следствия.
  3. Учитываем «невозможные» сочетания причин и следствий.
  4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
  5. Расставляем приоритеты.

Эта техника помогает:

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

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие).

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

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

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

  • Что произойдет, если не ввести код?
  • Что произойдет, если не ввести спецсимволы?
  • Что произойдет, если ввести не цифры, а другие символы?
  • Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

  1. Эта проверка эффективна в качестве дополнения к другим техникам.
  2. Выявляет тестовые случаи, которые “никогда не должны случиться”.

Недостатки:

  1. Техника в значительной степени основана на интуиции.
  2. Необходим опыт в тестировании подобных систем.
  3. Малое покрытие тестами.

Оформление тест-кейсов

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

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