Описание
Время — самый ценный ресурс. И зачастую по причине большой загрузки, приближающихся дедлайнов или каких-то срочных задач можно не успеть написать тест-кейс. В таком случае можно остановиться на предыдущем шаге, поскольку из названия кейса можно понять, что делать.
Ну а если вы, как и я, стремитесь к идеальным тест-кейсам, тогда стоит зафиксировать важные моменты. Кстати, вторым пунктом в соглашении о написании тест-кейсов!
Как говорил мой замечательный ментор: «Тест-кейс должен быть написан так, чтобы любой человек, пришедший в компанию, сел за стол и мог его спокойно пройти без лишних вопросов.»
Правильно пишем тест-кейсы. памятка начинающему специалисту по тестированию — заметки victorz
Когда смотришь на специалистов по тестированию, которые пишут тест-кейсы, то понимаешь, что многие из них даже не имеют представления как это правильно делается. Я не буду приводить множество примеров, которые показывают вопиющие ошибки, а постараюсь озвучить основные принципы того, как надо писать тест-кейсы.
Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Надеюсь, теперь многим стало понятно, что такое тест-кейс. Теперь перейдём к правилам написания тест-кейсов, которые вырабатывались не один год и показывают свою эффективность до сих пор.
Обязательные атрибуты для заполнения
- Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
- Заголовок — краткое, понятное и ёмкое описание сути проверки.
- Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
- Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
- Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.
В зависимости от специфики компании могут присутствовать дополнительные атрибуты для заполнения: приоритет, функциональный блок, программа, ссылка на требование, номер требования и т.д.
Правила написания тест-кейсов
- Заголовок:
- должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
- не может содержать выполняемые шаги и ожидаемый результат.
- Предусловие:
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
- не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
- не может содержать ожидаемый результат.
- Шаги проверки:
- должны быть чёткими, понятными и последовательными;
- следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; - должны использоваться безличные глаголы.
Правильно: нажать, ввести, перейти.
Неправильно: нажмите, введите, идите; - не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
- не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
- Ожидаемый результат:
- должен быть у каждого шага проверки;
- должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
- не должно быть избыточного описания.
- Общие требования к тест-кейсам:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
- в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
Примеры
Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.
Тест-кейс №1. Корректный
Тест-кейс №2. Некорректный
В данном тест-кейсе постарался в каждой строке писать неправильно, чтобы было наглядно. И в скобках добавлял наводящие пояснения.
Во второй части видео (с 8-й минуты) разбираю на примерах создание тест-кейсов:
Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.
Если вы будете вести тест-кейсы в таблице (к примеру в Excel), то можете скачать шаблон тест-кейсов. В файле две вкладки. На одной шаблон единичного тест-кейса, а на второй пример порядка размещения группы тест-кейсов.
#1 h8zerg
В прошлой теме мне никто не ответил, а сроки поджимают, поэтому я попрошу оценить и указать на ошибки.
Нужно составить позитивные тест-кейсы в гугл таблице.
Вопрос вот в чем, будет ли являться ниже преведенная моя фантазия , тест кейсом?)
Тест-кейс 1, Регистрация
Предусловия: Сайт (название) предназначен для , удобного составление задач и планов на день. * больше никаких значений, просят протетсировать сайт полностью, опираюсь на свои ощущения)
Шаги Ожидаемый результат
1. Нажимаем на кнопку регистрация Открылась страница регистрации
#2 vasiliy
В прошлой теме мне никто не ответил, а сроки поджимают, поэтому я попрошу оценить и указать на ошибки.
Нужно составить позитивные тест-кейсы в гугл таблице.
Вопрос вот в чем, будет ли являться ниже преведенная моя фантазия , тест кейсом?)
#3 h8zerg
В прошлой теме мне никто не ответил, а сроки поджимают, поэтому я попрошу оценить и указать на ошибки.
Нужно составить позитивные тест-кейсы в гугл таблице.
Вопрос вот в чем, будет ли являться ниже преведенная моя фантазия , тест кейсом?)
Как правильно создавать тест-кейсы для формы регистрации?
Например, есть форма регистрации с множеством полей. Если не заполнить (или заполнить невалидными данными) все поля и нажать [Отправить], то под каждым полем высветится ошибка, если заполнить все поля валидными данными кроме одного, то только под одним полем высветится ошибка.
Как правильней? 1) Проверить, что все ошибки высветились сразу заполнив все поля невалидными данными или оставив их пустыми? (т.е. будет максимум 2 тест-кейса) 2) Проверить, что появилась ошибка под полем n, после заполнения всех полей кроме поля n валидными данными. Повторить n раз для каждого поля. (Множество тест-кейсов)
- Вопрос задан более двух лет назад
- 11581 просмотр
Если форма заполнена не полностью, то кнопка отправить должна быть неактивна. Если форма заполнена невалидными данными и/или неполностью — кнопка «Отправить» должна быть неактивна и неверно заполненые поля должны показывать подсказку. Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются.
Переполнение поля тоже. Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (radio buttons) можно проверить выставляется ли значение по умолчанию если должно или не выставляется если не должно. Бывает что выставляется хотя не должно.
Кроме этого навигацию по полям табуляцией можно проверить. Можно проверить, что при перезагрузке страницы введенные в формуляр данные не сбрасываются, если они не должны сбрасываться. Если поля поддерживают автозаполнение можно проверить и это. Если формуляр многостраничный — нужно проверить навигацию между страницами, что введенные данные не теряются. Что их можно отредактировать вернувшись назад.
Не думайте о количестве тесткейсов, думайте о том, в чем вы хотите убедиться.
Источник
Количество шагов
Сколько их должно быть? 1-2-3-4-10? Будем честны: шаги идеального тест-кейса должны стремиться к 1!
На практике хороший кейс имеет не более 3 шагов. Стоит учитывать, что мы не говорим здесь о сценариях, которые проверяют E2E.
В шагах нужно отразить только суть самой проверки, остальное выносите в предусловия — не скупитесь!
Не ссылайтесь в шагах на другие шаги или другие тест-кейсы. Шаг или тест-кейс, на которые вы ссылаетесь, может быть удален или отредактирован. Любой тестировщик не будет рад тому, что необходимо идти к кому-то и узнавать, как работает функционал, особенно, если это регресс, и еще немало непройденных кейсов.
Пишите в шаге только одно действие. Не надо в один шаг описывать басню о царе султане и его дочери. Если вы не хотите делать из одного шага несколько, или просто хотите значительно сократить шаги в тесте — объедините несколько повелительных предложений в одно.
Приведу пример. Допустим вы проверяете авторизацию в личном кабинете.
Названия
Чтобы навигация по кейсам была быстрой и удобной, недостаточно создать только структуру и положить туда все тест-кейсы, названные в разнобой. Чтобы оптимизировать навигацию и сбор тест-ранов, лучше согласовать единый стиль при написании тест-кейсов между тестировщикам.
Мы воспользовались известной формулой: Где? Что? Условия?
При нейминге тест-кейса необходимо было придерживаться следующих требований:
Сразу приведу примеры таких названий:
Ожидаемые результаты
Теперь вспомним об ожидаемых результатах.
Не забудьте, что на одно ваше действие, может случиться несколько ожидаемых результатов. Их нужно зафиксировать в соответствии с принадлежностью шага.
Шаг: Нажать на кнопку оформить заказ.
Ожидаемый результат:
Шаг один, а ожидаемых результата два.
В те самые давние времена, когда я пришла в Утконос, у нас не было столько команд, сколько есть сейчас. Сегодня в Утконосе более 10 фича-команд, которые пилят разный функционал. В связи с этим самое верхнеуровневое разделение структуры тестовой документации строится на фича-командах, а далее уже в блоке каждой команды по принципу, описанному выше. Еще у нас есть мобильные приложения, а также разные системы и сервисы. Они выделены отдельными проектами.
На данный момент для сайта написано более 3000 тест-кейсов.
Высшей наградой для меня была ситуация, когда я зашла почитать нужный мне тест-кейс и не могла понять, кто его писал. Стиль был очень похож на тот, который я описала, но я не помнила, чтобы когда-либо писала этот кейс. И тогда я поняла: заработало!
В данный момент все тест-кейсы, написанные по сайту, имеют удобную структуру и единый стиль написания.
В статье я говорю о сайте, но вы можете применить данный подход к любому приложению, сервису или системе, как мы и сделали в Утконосе.
Надеюсь моя статья помогла вам разложить ваши тест-кейсы по полочкам, как в библиотеке. До связи!
Структура проекта
Для создания структуры тестовой документации сайта я решила воспользоваться постраничным распределением.
Что это такое? На нашем сайте существует много функциональностей, и проверять их удобно, если не нужно при этом перескакивать со страницы на страницу. То есть тестировщик будет выполнять все проверки, которые есть на странице, не переходя к другим проверкам. Да и искать определенный тест-кейс в этом случае более логично.
Отсюда сформировались основные блоки нашей будущей структуры:
Далее мне хотелось, чтобы тест-кейсы на фронт и бэкенд не перемешивались. И тогда каждая страница получила по 2 раздела, которые назывались: — Front— Back
Но даже в одном разделе — к примеру, главной страницы — насчитывалось очень много кейсов. Хотелось какого-то логического разделения. Поэтому каждый раздел я разбила на подразделы, которые относились к какой-то отдельной функциональности или сущности.
https://www.youtube.com/watch?v=dwYE7uLt_j4
Общие элементы, такие как хедер, добавление адреса и сайдбар (боковая корзина) можно выделить в отдельный блок, поскольку эти элементы есть на каждой странице, но можно и отнести к какой-то определенной странице. Таким образом у нас получилась такая структура для главной страницы: