Почему и как нужно адаптировать тест-кейсы перед автоматизацией тестирования
2026-02-21 18:00 Diff
https://skillbox.ru/media/code/pochemu-i-kak-nuzhno-adaptirovat-testkeysy-pered-avtomatizatsiey-testirovaniya/

#статьи

  • 22 июн 2023
  • 0

Почему и как нужно адаптировать тест-кейсы перед автоматизацией тестирования

Или как сохранить деньги, время и нервы, ускорив при этом выпуск новых фич.

Фото: Martin Barraud / Getty Images

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

И здесь на помощь приходит автоматизация, важную роль в которой играют тест-кейсы. Анастасия Леонтьева из SimbirSoft рассказала, как адаптировать их перед автоматизацией, и поделилась примером подготовленного кейса.

Руководитель направления тестирования и обеспечения качества в SimbirSoft. Имеет степень MBA, Six Sigma Yellow Belt, опыт работы в IT более шести лет.

Автоматизация тестирования может повысить скорость проверки качества продукта, что оборачивается для команды и бизнеса следующими выгодами:

  • Снижаются затраты на тестирование.
  • Снижается вероятность пропуска ошибки из-за человеческого фактора.
  • Увеличивается скорость доставки новых фич.

Согласно исследованию practitest.com, более 45% респондентов утверждают, что автоматизация снизила их затраты на тестирование в два раза. Эта статистика подтверждается и нашей практикой. Однако автоматизировать следует тест-кейсы только по той функциональности, в которой не планируется глобальных изменений. Иначе есть риск, наоборот, повысить затраты — так как придётся переписывать автотесты.

Важно помнить, что автотесты запускаются на основе проведённых до этого ручных тестов с проверенными сценариями (чек-листы, пользовательские сценарии и так далее). На основе сценариев, покрытых кодом, в будущем можно будет проводить нагрузочное тестирование. Подробная и адаптивная тестовая документация позволит сократить время на погружение в задачу нового специалиста и увеличить эффективность тестирования в целом.

Представим, что к действующему долгосрочному проекту подключается SDET‑специалист. До того как начнётся написание автотестов, у него могут возникнуть вопросы к QA-инженерам: про объём тестов для автоматизации, приоритеты выбора проверок, набор доступов и так далее.

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

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

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

2. Подробно указывать путь «до места назначения»: если нужно протестировать некую форму, важно расписать все шаги до её открытия. Часть описания можно вынести в предусловие.

3. Рационально подходить к процессу передачи тест-кейсов под автоматизацию. Нужно чётко понимать, что можно реализовать, а что нет. Если же возникли вопросы, то лучше заранее проконсультироваться со SDET-специалистом.

Кадр: фильм «Звёздные войны: Эпизод 3 — Месть ситхов» / Lucasfilm Ltd.

4. Включить в тест-кейс все необходимые данные. А именно: информацию об окружении, специфике тестирования на разных платформах, параметры настройки, а также необходимое время для применения в системе тех или иных настроек, если это требуется.

5. Если для выполнения кейса нужно определённое состояние системы или если кейс меняет его, напишите, как этого состояния достичь и что нужно сделать после проведения теста. Например, если производятся манипуляции над сущностью, должно быть понятно, где эту сущность взять и как потом вернуть на место, чтобы соблюсти идемпотентность.

6. Обращать внимание на тестовые данные. Если, например, требуется авторизация и учётные записи имеют разные уровни доступа, обязательно нужно прикрепить информацию о необходимом уровне доступа или сразу указать данные учёток, в которых уже есть необходимые сведения (документы, поля и прочее).

7. Отражать в кейсах тестовые сценарии использования системы. То есть последовательность запросов и ответов API, в которой заложен путь пользователя, а также чётко прописать ожидаемый результат.

8. Подробно расписать ожидаемый результат. Он должен быть точным и окончательным: один кейс — один результат. В этом поможет подробное описание и хорошие тестовые данные. Если возможен другой результат (сразу несколько изменений системы), необходимо вынести его в другой кейс. В ожидаемом результате важно точно указать, к чему привязаться автоматизатору, например к названию страницы или названию формы/кнопки.

9. Если рассматривать мобильную UI-автоматизацию, в тест-кейсе нужно включить моки и скриншоты для snapshot-тестов.

10. Чётко обозначить в тест-кейсе приоритетные проверки, критичные для корректной и стабильной работы системы.

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

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

Давайте на примере разберём, как можно улучшить кейсы под автоматизацию. Возьмём интернет-магазин, у которого есть API для совершения CRUD-операций с карточкой товара:

  • Создание.
  • Просмотр.
  • Редактирование.
  • Удаление.

Мы будем использовать открытый API shop.bugred.ru. Предварительно в нём необходимо будет авторизоваться. Это можно вынести в предусловие, так как оно не требует описания шагов или тела запроса, а лишь указывает на необходимость того или иного действия перед выполнением шагов. Ссылку на документацию, а также доступы можно найти на главной странице.

Несколько допущений в рамках нашего тест-кейса:

  • Мы будем рассматривать только взаимодействие через API.
  • В базу данных вынесены настройки, позволяющие включать или отключать возможность создания товара пользователем.
  • В системе может быть несколько тестовых сред со своей базой данных.

А вот, собственно, и сценарий: пользователь (например, менеджер) заходит в административную панель магазина, создаёт товар, обновляет информацию о нём (правит цвет, размер и так далее), проверяет, что данные изменились, и потом удаляет товар.

Наименование: «Проверка удаления созданного товара».

Предусловия теста:

  • Пользователь авторизован.
  • Значение ITEMS_CREATE.ENABLE равняется true
ШагиОжидаемый результат1.Создать товар в магазине

{

"name": "Шортики",

"section": "Платья",

"description": "Модное платье из новой коллекции!",

"color": "RED",

"size": 44,

"price": 666,

"params": "dress"

}

Товар создан. Получить код 200

{

"method": "/items/create",

"status": "ok",

"result": {

"id": "76",

"name": "Шортики",

"section": "Платья",

"description": "Модное платье из новой коллекции!",

"color": "RED",

"price": 666,

"params": "dress"

}

}

2. Обновить созданный товар

<request>

76

<name>Шортики</name>

Платья

<description>Модное красное платье</description>

48

RED

678

dress

</request>

Товар обновлён. Получить код 200

{

"method": "/items/update",

"status": "ok",

"result": "Товар обновлён!"

}

3. Получить данные о товаре

{

"id": 76

}"

Товар найден. Получить код 200

{

"method": "/items/update",

"status": "ok",

"result": {

"id": "76",

"name": "Шортики",

"section": "Платья",

"description": "Модное платье",

"color": "RED",

"size": "48",

"price": 666,

"params": " ",

"photo": "http://shop.bugred.ruhttps://via.place.com/300x300"

}

}

4. Удалить товар из БД DELETE FROM items WHERE items.id = 76Запись удалена

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

Наименование: «Проверка удаления созданного товара».

ПредусловияОжидаемый результат1. Тестовые базы:

БД Preprod: preprod.shop_bugred_r_db

БД Test: test.shop_bugred_r_db

Выполнить SQL-запрос:

UPDATE {БД}.SETTINGS_CUSTOMIZE SET ITEMS_CREATE.ENABLE=true

Время переключения настроек: от 10 минут

В таблице {БД}.SETTINGS_CUSTOMIZE обновилось значение ITEMS_CREATE.ENABLE2. Подготовить тестового клиента

БД Preprod: preprod.shop_bugred_r_db

БД Test: test.shop_bugred_r_db

В таблице {БД}.items.user найти запись не удалённого пользователя c помощью запроса SQL:SELECT method ,sessionId FROM {БД}.users WHERE user.remote <>true

Запись найдена. Значение method записать в переменную {{method}},

значение sessionId записать в переменную {{sessionId}}

3. Получить токен выполнив метод GET api/v1.0/shop/test/auth/token

В параметрах указать:

method = {{method}},sessionId = {{sessionId}}

Получить код 200 и Body:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG

Получить из ответа одну переменную:{{Token}}

ШагиОжидаемый результат1. Выполнить POST-запрос http://shop.bugred.ru/api/items/create/ c параметрами:

Header:Content-Type:application/json

Authorization: Bearer {{Token}}

Передать тело запроса:

{

"name": "Шортики",

"section": "Платья",

"description":"Модное платье из новой коллекции!",

"color":"RED",

"size": 44,

"price": 666,

"params":"dress"

}

Товар создан. Получить код 200 и тело ответа:

{

"method": "/items/create",

"status": "ok",

"result": {

"id": "76",

"name": "Шортики",

"section": "Платья",

"description": "Модное платье из новой коллекции!",

"color": "RED",

"price": 666,

"params": "dress"

}

}

Проверить, что выделенные поля присутствуют в ответе. Получить из ответа две переменные: {{id}} и {{name}}

2. Выполнить POST-запрос http://shop.bugred.ru/api/items/update/ c параметрами:

Header:Content-Type:application/json

Authorization: Bearer {{Token}}

Передать тело запроса:

<request>

<id>{{id}} </id>

<name> {{name}}</name>

<section>Платья</section>

<description>Модное красное платье</description>

<size>48</size>

<color>RED</color>

<price>678</price>

<params>dress</params>

</request>

Товар обновлен. Получить код 200 и тело ответа:

{

"method": "/items/update",

"status": "ok",

"result": "Товар обновлён!"

}

Проверить значение выделенных полей

3. Выполнить запрос POST http://shop.bugred.ru/api/items/update/ c параметрами:

Header:Content-Type:application/json

Authorization: Bearer {{Token}}

Передать тело запроса:

{

"id": {{id}}

}

Товар найден. Получить код 200 и тело ответа:

{

"method": "/items/update",

"status": "ok",

"result": {

"id": "76"

"name": "Шортики",

"section": "Платья",

"description": "Модное платье",

"color": "RED",

"size": "48",

"price": 666,

"params": " ",

"photo": "http://shop.bugred.ruhttps://via.placeholder.com/300x300"

}

}

Проверить значение выделенных полей (пояснить, что за значение ожидается)

4. Выполнить SQL-запрос:DELETE FROM items WHERE items.id = {{id}}Товар удалёнПостусловияОжидаемый результатВернуть первоначальные настройки в БД. Выполнить SQL-запрос:

UPDATE {БД}.SETTINGS_CUSTOMIZE SET ITEMS_CREATE.ENABLE=false

В таблице {БД}.SETTINGS_CUSTOMIZE обновилось значение ITEMS_CREATE.ENABLE

После правок тест-кейс стал выглядеть более продуманным, понятным, структурированным. В нём учтены ожидания SDET-специалиста, которые до этого требовали бы излишней коммуникации между ним и QA. Если в инструментах хранения тестовой документации добавить теги, приоритетность и статус (например, требует корректировки, ожидает автоматизации, автоматизирован и так далее), это также сократит количество вопросов к QA-специалисту.

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

Каждый запрос к API или БД, скорее всего, будет написан и представлен в коде проекта автотестов как отдельный метод с передаваемыми в него параметрами. Этот метод будет использоваться в кейсах. Тело запроса будет описано всего в одном месте, благодаря чему очень удобно вносить правки в код.

Такая же логика действует и в ручных кейсах. Если мы напишем 20 кейсов, в каждом из которых будем создавать товар и полностью описывать API-запрос, то вносить правки нужно будет в 20 кейсах. Куда удобнее сделать один кейс для создания записи, где будет описан соответствующий API-запрос, а в остальных — просто ссылаться на этот кейс. Таким образом, поддерживать ручные кейсы тоже будет просто.

В рамках написания автотеста можно придерживаться правила: автотест должен сам создать себе необходимые тестовые данные.

Пример. Допустим, в рамках теста нужно создать «маршрут», а в него добавить «автобус» из тех, что уже заведены в системе. Здесь предлагаю сначала создать «автобус», чтобы при создании «маршрута» выбрать его из списка. В этом случае создание «автобуса» как предусловие в тест-кейсах не описывается, поскольку автотест каждый раз будет сам готовить себе тестовую среду, создавая «автобус». А значит, даже на чистой базе данных без созданных «автобусов» будет отрабатывать корректно.

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

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

Кадр: сериал «Парки и зоны отдыха» / NBC

У адаптации тест-кейсов под автоматизацию есть ряд преимуществ:

  • На автоматизацию SDET-специалисту попадают более читабельные кейсы, в которых обозначена цель проверки, информация об окружении, настройках, тестовых данных и прочее. Это экономит время разработчиков на написание кода.
  • В процессе адаптации QA-инженер обновляет версии кейсов и поддерживает их в актуальном состоянии.
  • Специалистам нужно меньше времени на коммуникацию.
  • Повышение качества тестирования и производительности команды, благодаря единому взгляду QA и SDET на процесс выстраивания автоматизации на основе тестовых сценариев.

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

Оптимизировать затраты на IT-разработку можно и другими способами, например с помощью аудита и услуг на аутсорсе. Но это — тема для новой статьи.

Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу