Общие правила оформления тест-кейсов и их атрибуты
Всем привет! Меня зовут Иван. Почти год, как я работаю начальником отдела тестирования в одной из крупнейших финтех компаний России. Специализируюсь на построении и управлении командами, администрировании процессов.
Нил Армстронг, пройдя по Луне, сказал:»Это один маленький шаг для человека, но гигантский скачок для всего человечества». Так и наш путь начинается с небольшого, но важного шага — изучения фундаментальных основ тестирования.
Предвосхищаю некоторые комментарии. Тест-кейс и стандарты его оформления — это, конечно, база для любого тестировщика и давно избитая тема. Однако хочется выразить немного мыслей на этот счет. Надеюсь, что эти мысли, отраженные на «холсте», помогут тем, кто только вступает на путь тестировщика.
Итак, поехали!
Данный материал поможет совершить первые шаги в познании такого направления, как тестирование, и позволит ответить на следующие вопросы:
Как правильно, а главное, понятно для всех, подготовить и составить тест-кейс?
С какими наиболее частыми проблемами сталкивается инженер тестирования при составлении тест-кейса?
В статье дан разбор основных проблем при составлении тест-кейса. Данный материал не претендует на исключительность, а призван облегчить путь юных тестировщиков на их захватывающем пути познания данной профессии.
Обязательные атрибуты тест-кейса:
Заголовок
Предусловие
Шаги проверки
Ожидаемый результат
Постусловие
На каждом из этих атрибутов мы остановимся отдельно.
Заголовок
Как назовешь корабль, так он поплывет или полетит. Думаю, что нашим космическим исследователям было бы затруднительно выполнять задачи на Луне на кораблях, которые предназначены для Солнца. В обеспечении качества все схоже.
Заголовок должен быть четким, кратким, понятным и однозначно характеризующим суть тест-кейса. «У самурая есть только путь» не прокатит. Что конкретно за путь? Куда или откуда?
Пример хорошего заголовка: «Проверка входа пользователя с корректными данными».
Пример плохого заголовка: «Проверка входа пользователя». В данном примере не указано, что именно проверяем.
Предусловие
Космонавт, перед выходом в открытый космос должен надеть скафандр, а тестировщик должен подготовиться к выполнению шагов кейса и тестированию ПО.
Предусловие содержит полную информацию о состоянии системы или объекта, необходимую для начала выполнения шагов тест-кейса.
Предусловие может содержать список источников информации (описание системы, инструкции), которые тестировщик должен прочитать перед началом выполнения тест-кейса.
Предусловие не может содержать выполняемые шаги и ожидаемый результат. Если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем — открыта главная страница сайта.
Пример хорошего предусловия: «Открыта главная страница сайта».
Пример плохого предусловия: «Перейти на главную страницу сайта». Это не предусловие, а описание шага.
Шаги проверки
Как и любой космонавт, мы в своей работе должны уделять особое внимание шагам. Ниже представлены хорошие и не очень хорошие описания шагов.
Шаги должны быть чёткими, понятными и последовательными. Следует избегать излишней детализации шагов. Для описания шагов нужно использоваться безличные глаголы. Например, нажать, ввести, перейти. В шагах не должно быть:
Комментариев и пояснений. Если есть необходимость привести мини-инструкцию, то даем на нее ссылку (Ссылку на источник)
Жестко прописанных статических данных (логины, пароли, имена файлов) и примеров для исключения эффекта пестицида.
Пример хорошего шага: «Ввести значение в поле «Ваше имя», состоящее из латинских букв, кириллицы».
Пример плохого шага: «Вводим имя в поле «Ваше имя». В данном примере не указано, какие символы вводить.
Ожидаемый результат
Наш земляк Юрий Алексеевич Гагарин поставил перед собой конкретную цель, ожидаемый результат и 12 апреля 1961 года стал первым человеком в космосе. А тестировщик при составлении кейса должен четко понимать, какое поведение он ожидает увидеть от системы.
Ожидаемый результат должен быть у каждого шага проверки. Он должен быть кратким и понятно описывать состояние системы или объекта, наступающее после выполнения соответствующего шага. При этом следует избегать недостаточности описания. Если предусмотрены несколько действий, все должны быть указаны последовательно.
Пример хорошего ожидаемого результата: «В поле «Ваше имя» отображается введенное имя.»
Пример плохого ожидаемого результата: «В поле отображается имя». В каком поле? Какое имя? Куда введенное?
Постусловие
Постусловие должно содержать список действий, возвращающих систему в исходное состояние (указывается при необходимости).
Дополнительные атрибуты тест-кейса
Номер тест-кейса.
Тэг (ручной кейс или тест-кейс под дальнейшую автоматизацию).
Вид тестирования, к которому относится тест-кейс (smoke, регресс).
Вид программного обеспечения, под которое составлялся кейс (тип и вид устройства/ПО/версия ПО).
Взаимосвязь с другим сценарием или прогоном.
Указание ПО, сборки, разрешения и связки браузера при написании кейса на нативное ПО (для мобильных приложений).
Общие требования к тест-кейсам
Перед написанием тест-кейсов сначала нужно разработать структуру/древо. Не путать со стратегией и матрицей трассируемости. Тест-кейсы группируются в функциональные блоки по их назначению.
Описание тест-кейсов излагается простой, общедоступной лексикой. Не нужно оперировать такими понятиями, как креды (они же доступы), гол, реф, апликуха, самый быстрый пистолет на Диком Западе. Лексика должна быть понятна широкому кругу пользователей, а не узкой группе лиц.
В тест-кейсах, проверяющих работу функционала, скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсов при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы, проверяющие отображение страниц и форм.
Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе. Исключение составляют очень долгие проекты с уже существующим покрытием. При условии, что отсутствует возможность отфильтровать по тематике/тэгам. В противном случае, на это уйдет времени больше, чем на написание новых тест-кейсов. Если какие-то шаги дублируют ранее добавленный тест-кейс, переиспользуем, добавляя не шаг, а тест-кейс в шаги (функция в Zephyr, TestIT).
Заключение
Выражаю огромную признательность за уделенное время и прочтение данного материала. Буду благодарен за конструктивную обратную связь. Мир ИТ обширен и многогранен. Он, как и космос, ждет своих исследователей — энтузиастов!
Спасибо!
