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

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

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

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

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

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

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

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

  • сам сайт

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

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

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

  • лендинги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • и т.д.

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

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

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

Названия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (10)


  1. MrStrangehold
    01.06.2022 12:47

    Спасибо за статью! Довольно интересный подход.


    1. makeeva_anastasiya Автор
      01.06.2022 12:50

      Спасибо!)


  1. vlad_egrv
    01.06.2022 12:53

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


    1. makeeva_anastasiya Автор
      01.06.2022 15:34

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


      1. vlad_egrv
        01.06.2022 17:34

        но также есть мнение, что данные системы несколько перегружены и не всегда обоснованы. Мне просто интересно, какие вы варианты еще рассматривали в плане окружения


        1. makeeva_anastasiya Автор
          02.06.2022 10:56

          На момент написания тест-кейсов необходимости рассматривать альтернативный инструмент ведения тестовой документации не было.


      1. bmv1986
        03.06.2022 11:05

        Вам на сегодняшний день не заблокировали testrail?


        1. makeeva_anastasiya Автор
          03.06.2022 11:07

          Доброго дня!
          На данный момент наша лицензия еще действует, но уже прорабатываем альтернативные решения.


  1. Aleksey_Zabrodin
    03.06.2022 12:10

    Здравствуйте, ооочень интересно, а про автоматизацию , что нибудь будет ??)))))


    1. makeeva_anastasiya Автор
      03.06.2022 12:12

      Добрый день!
      Не исключено)