Всем привет! На связи Анастасия Макеева. В Утконос Онлайн я работаю лидом автоматизации тестирования на проекте витрины. В мои обязанности входит организация и реализация автоматизированного тестирования сайта, систем и сервисов. 

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

Давным-давно…
Когда мир еще знать не знал, что такое covid.
Когда коллеги дружно работали в офисе.
Когда ходили на встречи в переговорки, а не в Teams или Zoom. 
Когда обедали вместе.
Я пришла работать в Утконос.

Моими первыми задачами было: 

• Организовать структуру хранения тестовой документации

• Распределить и отредактировать уже написанные кейсы согласно новой структуре

• Написать большую часть недостающих кейсов

Тестовая документация касалась всех блоков, связанных с сайтом Утконос:

• сам сайт

• административная часть сайта

• промо механики

• разные категории клиентов

• лендинги

• интеграции со сторонними подрядчиками

Так или иначе каждый блок содержал в себе свои разделы. 
А разделы — подразделы. 

По предварительным расчетам общее количество написанных кейсов должно было превысить 1000.

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

При планировании мне хотелось добиться: 

• простой и понятной структуры

• единого стиля

• быстрой и логичной навигации при поиске

• удобства при сборке тест-ранов

• легкости восприятия тест-кейсов

• чтобы после прочтения кейса тестировщику не хотелось закрыть его и пойти кофейку попить

Структура проекта

Для создания структуры тестовой документации сайта я решила воспользоваться постраничным распределением. 

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

Отсюда сформировались основные блоки нашей будущей структуры:

• главная страница

• страница поиска

• страница карточки товара

• страница корзины

• страница с акциями

• страница чекаута

• страница спасибо за заказ

• страница лендинга

• и т.д.
  

Далее мне хотелось, чтобы тест-кейсы на фронт и бэкенд не перемешивались. И тогда каждая страница получила по 2 раздела, которые назывались: 
— Front
— Back 

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

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

Названия

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

Мы воспользовались известной формулой: 
Где? Что? Условия?

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

• В начале кейса отражен территориальный признак.

• Далее указывается суть проверки.

• После можно указать какие-то особые условия.

• Каждый пункт разделен между собой точкой для более легкого восприятия текста.

 Сразу приведу примеры таких названий: 

Ну что, догадались, о чем этот тест-кейс? 
Уже идете на главную страницу utkonos.ru, чтобы 
добавить товар в корзину из спецпредложений, не указав адрес в личном кабинете?) 
А вот тут?

В представленных примерах мы видим, что: 

• В названии отражен территориальный признак: то есть, ГДЕ мы проверяем этот кейс.

• Далее идет суть самой проверки, то есть, ЧТО мы проверяем в этом кейсе.

• После чего — некие разветвления/ особые УСЛОВИЯ.

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

Описание 

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

Ну а если вы, как и я, стремитесь к идеальным тест-кейсам, тогда стоит зафиксировать важные моменты. Кстати, вторым пунктом в соглашении о написании тест-кейсов! 

Как говорил мой замечательный ментор: «Тест-кейс должен быть написан так, чтобы любой человек, пришедший в компанию, сел за стол и мог его спокойно пройти без лишних вопросов.»

Количество шагов

Сколько их должно быть? 1-2-3-4-10? 
Будем честны: шаги идеального тест-кейса должны стремиться к 1! 

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

В шагах нужно отразить только суть самой проверки, остальное выносите в предусловия — не скупитесь! 

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

Пишите в шаге только одно действие. Не надо в один шаг описывать басню о царе султане и его дочери. Если вы не хотите делать из одного шага несколько, или просто хотите значительно сократить шаги в тесте — объедините несколько повелительных предложений в одно. 

Приведу пример. Допустим вы проверяете авторизацию в личном кабинете. 

Было:
Открыть utkonos.ru
Кликнуть на значок личного кабинета
Ввести кпп
Ввести верный пароль
Нажать на кнопку «Вход»

Стало: 
Авторизуйтесь в личном кабинете с кпп и верным паролем

Один шаг вместо пяти. Круто?

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

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

Теперь вспомним об ожидаемых результатах.

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

Шаг: 
Нажать на кнопку оформить заказ. 

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

• Открыта страница «Спасибо за заказ». 

• Открыто окно с предложением добавить товары в заказ.

Шаг один, а ожидаемых результата два. 

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

На данный момент для сайта написано более 3000 тест-кейсов. 

Высшей наградой для меня была ситуация, когда я зашла почитать нужный мне тест-кейс и не могла понять, кто его писал. Стиль был очень похож на тот, который я описала, но я не помнила, чтобы когда-либо писала этот кейс. И тогда я поняла: заработало! 

В данный момент все тест-кейсы, написанные по сайту, имеют удобную структуру и единый стиль написания. 

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

Надеюсь моя статья помогла вам разложить ваши тест-кейсы по полочкам, как в библиотеке. До связи!