У каждого специалиста со временем накапливаются свои трюки и стандартные решения. Я не исключение, а довольно хорошее подтверждение. Есть у меня страсть к сбору и сортировке всяких мыслей, созданию мини-стандартов и совершенствованию "снизу-вверх". В текущей заметке я бы хотел поделиться трюками в именовании тест сценариев.
Если классически подходить к вопросу создания сценариев у нас должно быть несколько атрибутов:
1. Уникальный индекс (Тест Сценарий 1, ТС-1, ТС00001), возможно имеющий аббревиатуры тестируемых фич (кнопка от которой у плюшевого мишки поднимаются руки: ТС_МИШ_РУК-1).
2. Название (тестирование кнопки плюшевого мишки 1, тестирование кнопки плюшевого мишки 2, тестирование кнопки плюшевого мишки 3).
3. Описание. Сюда можно включить такие поля как описание, предусловия, постусловия, ограничения, связи и пр. что не требует (как вы думаете) сортировки или фильтрации.
4. Шаги и ожидаемые результаты.
Сегодня я бы хотел остановиться на атрибуте [Название] и полезных символах. Описанный ниже подход хорошо подходит для случаев сравнительно небольшого количества состояний, условий, значений и очевидно слабо для сценариев с большим количеством уникальными значений.
Небольшое замечание почему я практикую специальные символы и, на первый взгляд, не совсем стандартные именования сценариев. Я не люблю непонятные названия такие, например, как [тестирование кнопки плюшевого мишки 1], [тестирование кнопки плюшевого мишки 2] ... О чем сценарий и что проверяет? - мы это можем узнать из описания. Но я привык работать с чек листами и описание сценария это лишняя громоздкая информация (как мне кажется). Люблю видеть информацию сразу.
Объединение проверяемых параметров. Знак +
Данный символ применяется в кросс тестировании, например когда можно за один проход проверять несколько полей в графическом интерфейсе. Если вы можете вычленить несколько изменений, которым они подчиняются, то вам будет достаточно легко описать ожидаемые результаты:
- при создании объекта (добавление нового товара в интернет-магазине) срабатывает правило: установить значение по умолчанию,
- при копировании/клонировании объекта поле копируется, а не устанавливает значение по умолчанию,
- при изменении значения поля, оно изменяется (т.е. после изменения нужно открыть объект опять для просмотра и убедиться, что оно изменилось. По хорошему неплохо еще в базу зайти - вдруг проблемы с кешем).
Пример имени сценария:
Дефолты и изменения: Поле1+Поле2+Поле3
Если у вас зависимые поля, например существуют различные правила для проверки (если изменяется поле 1, то нужно выбрать одно из значений поля 2, также можно выбрать одно из значений поля 3). То применяя например pairwise медод мы получаем переборы значений и имя сценария у нас выглядит уже как-то так:
Связанные поля (Поле 1+ Поле 2 + Поле 3): Значение поля 1+Значение Поля 2+ Значение поля 3
Конечно, конечно же если вам нужно проверить 1024 поля на 256 вкладках в 128 окнах то именовать сценарии так не нужно.Нужно подумать как использовать в именовании сценариев названия окон и вкладок.
Параметр не имеет значения. Знак ~
Если знак [+] объединяет объекты и устанавливает обязательные значения полей, с которыми их использовать, то знак [~] помогает вам понять: можно выбрать указанное значение, но оно на самом деле уже не важно. Это может случиться например, когда вы используете тот же pairwise и создали кучу сценариев. У меня часто случается, что значение поля 3 в других сценариях уже использовано со всеми значениями полей 1 и 2. То что вы поставите в качестве значения поля 3 уже не имеет значения, но мини-стандарт именования сценария нарушать не хочется и появляется на свет:Связанные поля (Поле 1+ Поле 2 + Поле 3): Значение поля 1+Значение Поля 2~Значение поля 3
Выбрать какой нибудь из параметров (хотя бы один). Знак /
Итак мы уже поделились знаками: обязательный [+] и необязательный [~]. В случае когда объект может иметь несколько значений и вам действительно важно выбрать 2-3 из всех 10, то знак [/] подходит как никак лучше: Связанные поля (Поле 1+ Поле 2): Значение поля 1+Значение Поля 2-1/Значение Поля 2-2/Значение Поля 2-1
Сложное расположение объекта. Знак ->.
Если у вас используется сложное графическое приложение, которое имеет 1024 поля на 256 вкладках в 128 окнах, то вам нужно как то их разделять. Мы используем символ ->; для указания нисходящего движения (или просто движения):Окно 1 -> Вкладка 1 -> Поле 1023
Либо движение по меню:
Меню 1 -> Пункт меню 1 -> Подпункт 11 -> Подпункт 111
Отделение название объектов от описания. Знаки [].
В заметке я уже несколько раз (даже умышленно) использовал знаки []. В имени сценария или в шагах или в ожидаемых результатах или даже в описании сценариев мы можем захотеть выделить [имя объекта], [значение объекта] или [сложный объект]. Пользуемся и улыбаемся. Заключение
Для меня название сценария это та краткая информация, которой мне должно быть достаточно для быстрого принятия решения - включать или не включать его в тест план. Если это двадцати строчный текст (все зависит от широты ячейки в таблице), то в стандарте именования нужно что-то менять (крайний случай - тест дизайнера).Возможно вы заметили некоторую связь символов с регулярными выражениями. Это так, паттерны могут стать хорошим источником идей для именований сценариев.
Комментариев нет:
Отправить комментарий