Код

22 июн 2023
0

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

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

Фото: Martin Barraud / Getty Images

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

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

Анастасия Леонтьева

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

Очевидные плюсы от автоматизации тестирования

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

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

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

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

Как учесть ожидания SDET‑специалистов при подготовке тест‑кейсов

Представим, что к действующему долгосрочному проекту подключается 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.ENABLE
2. Подготовить тестового клиента БД 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-разработку можно и другими способами, например с помощью аудита и услуг на аутсорсе. Но это — тема для новой статьи.

Читайте также: