Всем привет! На связи Анастасия Макеева. В Утконос Онлайн я работаю лидом автоматизации тестирования на проекте витрины. В мои обязанности входит организация и реализация автоматизированного тестирования сайта, систем и сервисов.
Свой путь в Утконосе я начинала с мануального тестирования, поэтому в этой статье хочу поделиться с вами подходом, который я применила для создания удобной структуры и информативного содержания тестовой документации.
Давным-давно…
Когда мир еще знать не знал, что такое covid.
Когда коллеги дружно работали в офисе.
Когда ходили на встречи в переговорки, а не в Teams или Zoom.
Когда обедали вместе.
Я пришла работать в Утконос.
Моими первыми задачами было:
Организовать структуру хранения тестовой документации
Распределить и отредактировать уже написанные кейсы согласно новой структуре
Написать большую часть недостающих кейсов
Тестовая документация касалась всех блоков, связанных с сайтом Утконос:
сам сайт
административная часть сайта
промо механики
разные категории клиентов
лендинги
интеграции со сторонними подрядчиками
Так или иначе каждый блок содержал в себе свои разделы.
А разделы — подразделы.
По предварительным расчетам общее количество написанных кейсов должно было превысить 1000.
Это большая цифра, и она означала, что с самого начала необходимо продуманно отнестись к созданию и построению удобной структуры хранения тестовой документации.
При планировании мне хотелось добиться:
простой и понятной структуры
единого стиля
быстрой и логичной навигации при поиске
удобства при сборке тест-ранов
легкости восприятия тест-кейсов
чтобы после прочтения кейса тестировщику не хотелось закрыть его и пойти кофейку попить
Структура проекта
Для создания структуры тестовой документации сайта я решила воспользоваться постраничным распределением.
Что это такое?
На нашем сайте существует много функциональностей, и проверять их удобно, если не нужно при этом перескакивать со страницы на страницу. То есть тестировщик будет выполнять все проверки, которые есть на странице, не переходя к другим проверкам. Да и искать определенный тест-кейс в этом случае более логично.
Отсюда сформировались основные блоки нашей будущей структуры:
главная страница
страница поиска
страница карточки товара
страница корзины
страница с акциями
страница чекаута
страница спасибо за заказ
страница лендинга
и т.д.
Далее мне хотелось, чтобы тест-кейсы на фронт и бэкенд не перемешивались. И тогда каждая страница получила по 2 раздела, которые назывались:
— Front
— Back
Но даже в одном разделе — к примеру, главной страницы — насчитывалось очень много кейсов. Хотелось какого-то логического разделения. Поэтому каждый раздел я разбила на подразделы, которые относились к какой-то отдельной функциональности или сущности.
Общие элементы, такие как хедер, добавление адреса и сайдбар (боковая корзина) можно выделить в отдельный блок, поскольку эти элементы есть на каждой странице, но можно и отнести к какой-то определенной странице. Таким образом у нас получилась такая структура для главной страницы:
Названия
Чтобы навигация по кейсам была быстрой и удобной, недостаточно создать только структуру и положить туда все тест-кейсы, названные в разнобой. Чтобы оптимизировать навигацию и сбор тест-ранов, лучше согласовать единый стиль при написании тест-кейсов между тестировщикам. Именно так мы и сделали: утвердили и зафиксировали соглашение о написании тест-кейсов, в котором одним из пунктов был описан принцип составления названия.
Мы воспользовались известной формулой:
Где? Что? Условия?
При нейминге тест-кейса необходимо было придерживаться следующих требований:
В начале кейса отражен территориальный признак.
Далее указывается суть проверки.
После можно указать какие-то особые условия.
Каждый пункт разделен между собой точкой для более легкого восприятия текста.
Сразу приведу примеры таких названий:
Ну что, догадались, о чем этот тест-кейс?
Уже идете на главную страницу utkonos.ru, чтобы
добавить товар в корзину из спецпредложений, не указав адрес в личном кабинете?)
А вот тут?
В представленных примерах мы видим, что:
В названии отражен территориальный признак: то есть, ГДЕ мы проверяем этот кейс.
Далее идет суть самой проверки, то есть, ЧТО мы проверяем в этом кейсе.
После чего — некие разветвления/ особые УСЛОВИЯ.
Таким образом после нескольких прохождений кейсов наши тестировщики могут легко ориентироваться только по названию, не заходя в сам кейс.
Описание
Время — самый ценный ресурс. И зачастую по причине большой загрузки, приближающихся дедлайнов или каких-то срочных задач можно не успеть написать тест-кейс. В таком случае можно остановиться на предыдущем шаге, поскольку из названия кейса можно понять, что делать.
Ну а если вы, как и я, стремитесь к идеальным тест-кейсам, тогда стоит зафиксировать важные моменты. Кстати, вторым пунктом в соглашении о написании тест-кейсов!
Как говорил мой замечательный ментор: «Тест-кейс должен быть написан так, чтобы любой человек, пришедший в компанию, сел за стол и мог его спокойно пройти без лишних вопросов.»
Количество шагов
Сколько их должно быть? 1-2-3-4-10?
Будем честны: шаги идеального тест-кейса должны стремиться к 1!
На практике хороший кейс имеет не более 3 шагов.
Стоит учитывать, что мы не говорим здесь о сценариях, которые проверяют E2E.
В шагах нужно отразить только суть самой проверки, остальное выносите в предусловия — не скупитесь!
Не ссылайтесь в шагах на другие шаги или другие тест-кейсы.
Шаг или тест-кейс, на которые вы ссылаетесь, может быть удален или отредактирован. Любой тестировщик не будет рад тому, что необходимо идти к кому-то и узнавать, как работает функционал, особенно, если это регресс, и еще немало непройденных кейсов.
Пишите в шаге только одно действие. Не надо в один шаг описывать басню о царе султане и его дочери. Если вы не хотите делать из одного шага несколько, или просто хотите значительно сократить шаги в тесте — объедините несколько повелительных предложений в одно.
Приведу пример. Допустим вы проверяете авторизацию в личном кабинете.
Было:
Открыть utkonos.ru
Кликнуть на значок личного кабинета
Ввести кпп
Ввести верный пароль
Нажать на кнопку «Вход»
Стало:
Авторизуйтесь в личном кабинете с кпп и верным паролем
Один шаг вместо пяти. Круто?
Если развернутая последовательность ваших шагов интуитивно не очень понятна, можно с первого по четвертый шаг вынести в предусловия.
Ожидаемые результаты
Теперь вспомним об ожидаемых результатах.
Не забудьте, что на одно ваше действие, может случиться несколько ожидаемых результатов. Их нужно зафиксировать в соответствии с принадлежностью шага.
Шаг:
Нажать на кнопку оформить заказ.
Ожидаемый результат:
Открыта страница «Спасибо за заказ».
Открыто окно с предложением добавить товары в заказ.
Шаг один, а ожидаемых результата два.
В те самые давние времена, когда я пришла в Утконос, у нас не было столько команд, сколько есть сейчас. Сегодня в Утконосе более 10 фича-команд, которые пилят разный функционал. В связи с этим самое верхнеуровневое разделение структуры тестовой документации строится на фича-командах, а далее уже в блоке каждой команды по принципу, описанному выше.
Еще у нас есть мобильные приложения, а также разные системы и сервисы. Они выделены отдельными проектами.
На данный момент для сайта написано более 3000 тест-кейсов.
Высшей наградой для меня была ситуация, когда я зашла почитать нужный мне тест-кейс и не могла понять, кто его писал. Стиль был очень похож на тот, который я описала, но я не помнила, чтобы когда-либо писала этот кейс. И тогда я поняла: заработало!
В данный момент все тест-кейсы, написанные по сайту, имеют удобную структуру и единый стиль написания.
В статье я говорю о сайте, но вы можете применить данный подход к любому приложению, сервису или системе, как мы и сделали в Утконосе.
Надеюсь моя статья помогла вам разложить ваши тест-кейсы по полочкам, как в библиотеке. До связи!
