Приложение представляет из себя веб-сервис.
Приложение предлагает купить тур по определённой цене с помощью двух способов:
- Обычная оплата по дебетовой карте
- Уникальная технология: выдача кредита по данным банковской карты
Само приложение не обрабатывает данные по картам, а пересылает их банковским сервисам:
- сервису платежей (далее - Payment Gate)
- кредитному сервису (далее - Credit Gate)
Приложение должно в собственной СУБД сохранять информацию о том, каким способом был совершён платёж и успешно ли он был совершён (при этом данные карт сохранять не допускается).
Само приложение расположено в файле aqa-shop.jar и запускается стандартным способом java -jar aqa-shop.jar на порту 8080.
В файле application.properties приведён ряд типовых настроек:
- учётные данные и url для подключения к СУБД
- url-адреса банковских сервисов
Заявлена поддержка двух СУБД (проверить):
- MySQL
- PostgreSQL
Учётные данные и url для подключения задаются в файле application.properties.
Разработчики подготовили симулятор банковских сервисов, который может принимать запросы в нужном формате и генерировать ответы.
Симулятор написан на Node.js, поэтому для запуска нужен либо Docker, либо установленный Node.js. Симулятор расположен в каталоге gate-simulator. Для запуска необходимо перейти в этот каталог.
Запускается симулятор командой npm start на порту 9999.
Симулятор позволяет для заданного набора карт генерировать предопределённые ответы.
Набор карт представлен в формате JSON в файле data.json.
Разработчики сделали один сервис, симулирующий и Payment Gate, и Credit Gate.
Ключевая задача - автоматизировать сценарии (как позитивные, так и негативные) покупки тура.
Задача разложена на 4 этапа:
- Планирование автоматизации тестирования
- Непосредственно сама автоматизация
- Подготовке отчётных документов по итогам автоматизированного тестирования
- Подготовка отчётных документов по итогам автоматизации
После начала работы над проектом в течение 3 рабочих дней предоставить лиду план автоматизации, в котором описано:
- Перечень автоматизируемых сценариев
- Перечень используемых инструментов с обоснованием выбора
- Перечень и описание возможных рисков при автоматизации
- Интервальная оценка с учётом рисков (в часах)
- План сдачи работ (когда будут авто-тесты, результаты их прогона и отчёт по автоматизации)
Отчёт оформляется в виде файла с именем Plan.md.
- Обязательно должны быть тесты UI
- Обязательно должны быть репорты (Gradle/Allure/Report Portal)
- Обязательно должны быть запросы в базу, проверяющие корректность внесения приложением информации
Код авто-тестов заливается в репозиторий проекта вместе с отчётными документами, всеми необходимыми для запуска файлами и конфигурациями.
В файле README.md должна быть описана процедура запуска авто-тестов (если для запуска необходимо заранее установить, настроить, запустить какое-то ПО - это тоже должно быть описано).
В качестве отчётных документов прикладываются issue со скриншотами и описанием багов + формируется документ Report.md, в котором содержится отчёт о проведённом тестировании:
- Краткое описание
- Количество тест-кейсов
- % успешных/не успешных
- Общие рекомендации
Интегрировать отчёты: Gradle, Allure или Report Portal.
В качестве отчётных документов формируется документ Summary.md, в котором содержится отчёт о проведённой автоматизации:
- Что было запланировано и что было сделано
- Причины, по которым что-то не было сделано
- Сработавшие риски
- Общий итог по времени (сколько запланировали/сколько потратили с обоснованием расхождения)