Добрый день, уважаемые читатели.

Хочу рассказать об опыте построения системы автоматизации тестирования, когда на проекте или совсем нет тестирования, или ее степень минимальная.

Надеюсь статьи будет полезна начинающим автотестерам.

В первой части пофилосовствуем в общем про подход.
Во второй части (Часть 1) на примерах сделаем проект автотестов на JAVA + научим быстро тестировать API.
В третьей части дополним проект для UI тестирования, сделаем параллельное выполнение тестов.

Когда делать автотесты?

Краткий ответ — как можно раньше.

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

Почему?

Потому что автотетсы:

Накапливают сценарии для регресса
Непредвзяты
Быстрые

Накопленные сценарии

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

Если автотест проходил стабильно и на какой-то ветке упал, то или меняли требования, или баг, или инфраструктура подвела.

Непредвзятость

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

Скорость

Если каждый тест удовлетворяет занудным условиям:

Предусловие — Тест — Постусловие
То такие тесты легко автоматизировать.

А потом легко распараллелить. Потому что они получаются независимыми.

Количество потоков — сколько выдержат тестовые сервера и чтобы не мешать другим.

Второй момент это сама по себе скорость. В ручном режиме прокликать создание товара, его поиск и покупку в интернет магазине это 5 минут. 4 браузера. Итого 20 минут. На всего лишь одном небольшом сценарии.

Автотест по этому сценарию проходит за 1,5 минуты. Но на 8 браузерах. (Последняя и предпоследняя версии каждого браузера).

С чего начать?

С пользовательских сценариев.

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

QA должен работать от user story. Потому что программист обычно и не знает ее, и не хочет знать.

Соответственно логика 1 тест — 1 пользовательский кейс (бизнес сценарий) наиболее приближена к реальности.

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

Да, иногда предусловия занимают больше времени, чем тест, но при переиспользовании сценариев сложности не несет.

Какие сценарии автоматизировать

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

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

Что конкретно делать?

Обычно в проектах есть

Бэкэнд
Фронтэнд
Мобильные приложения
Железки

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

Поэтому предлагаю заняться Бэкэндом и Фронтом.

Выбираем сценарий

Допустим, у нас есть интернет-магазин.
Есть админка, есть клиентский и админский фронт.
Есть API, которое все это обслуживает.

С чего начать автоматизацию?

Давайте смотреть.

Есть клиенты, есть сотрудники.

У клиента первый кейс — просмотр и поиск товара, добавление его в корзину, и оформление.
У сотрудника самый распространенный кейс — добавление карточки товара.

Какой кейс автоматизируем первым? И как?

Самое важное для магазина — продажи.

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

По API. Но без фронта. Тут можно поспорить, но скорее всего дизайн поменяется 2-3 раза еще, а вот бэкэнд вряд ли. Так что на 1 этапе придется интерфейс проверять вручную.

Далее сделать проверки на API редактирования карточки товара и ее фронт.

И вернуться к клиентскому. На этом этапе уже будет статистика наиболее частых действий пользователей, и наиболее частых путей клиента. Да, Яндекс Метрика и Вебвизор помогают и тестировщикам.

Нет никакого смысла на первом этапе проверять, работает ли функция оплаты на счет фирмы через сгенерированную платежку, если этой функцией пользуется 0,5% посетителей. Конечно можно задать менеджеру вопрос зачем это тут нужно, но тут не об этом.

Допустим у нас 40% человек платят на сайте картой, 30% наличкой, 20% наложенным платежом и 10% все остальные способы.

Какой тип оплаты будем проверять первым? Конечно картой.

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

Постусловия

Мы насоздавали всего-всего в тестах. Намусорили. Надо бы за собой убрать. Нужно заранее предусмотреть, в каких тестах мы будем за собой убирать, а в каких — нет.

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

Странности

Есть странный подход, когда автоматизируют сценарии, в которых пользователи находили баг. Обычно это очень экзотические сценарии, и тратить ресурс на них нет смысла. Была ситуация когда сломался функционал обновления данных банка-контрагента. Сбоила синхронизация со справочником БИК.

То есть новый БИК не обновлялся. Но новый банк заводился нормально.

Есть ли смысл автоматизировать этот сценарий? Если контрагенты меняются каждый день — может быть. И тогда это была недоработка планирования.

Если это делается 5-6 раз в год, то может лучше более приоритетной задачей заняться?

Что будет дальше?

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

Напомню про эффект пестицида, и как его свети к минимуму.

Технологии: Java + maven + testng + allure + RestAssured + Pict.

Автоматизация тестирования с нуля. Часть 1