Интеграционное тестирование банк.приложений

Коллеги, всем здравствуйте.

Занимаюсь тестирование не столь давно, пока вопросов не возникало.

Но сейчас я в тупике.

Скажите, кто сможет что посоветовать.

Представьте, есть система интернет-банкинга (ИБ). Функционал примерно представляете. Там можно делать платежи, проверять свой баланс, делать переводы и так далее.

Для меня как тестировщика - ИБ представляет собой черный ящик. Доступ только к веб-интерфейсу.

Сам ИБ, а так же его база данных - предоставлен вендором, доступа к нему прямого нет.

Процесс ручного тестирование мануальщиками выглядит так:

 - человек логинится

 - выбирает платеж к примеру

 - заполняет нужные поля (сумма, счет, номер телефона и т.д.)

 - нажимает "Продолжить"

 - на телефон тестировщика - физический телефон - прилетает СМС, в котором код авторизации

 - тестировщик вводит код, платеж проходит

 - далее: тестировщик открывает приложение для просмотра операции в бэкенде (это оболочка для базы данных - назовем DBM), в нем проводит закрытие дня для своего счета, делает постилирование и потом появляются проводки, которые он может глазками посмотреть

 - далее: открывает банковскую систему (Colvir) и смотрит, появился ли там платеж

Желание бизнеса (не разработчиков) - проверять всю эту цепочку. Я пока могу - довести до платежа. Вскоре, как решу проблему с СМС - провести платеж, подтвердив вводом кода из СМС.

Но дальше: мне надо залезть в DBM, сделать там уже в десктоп приложении нужные действия.

Потом посмотреть еще в Colvir`е- сели ли туда проводки.

Возникает собственно вопрос:

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

Что у меня есть:

 - пишем для веба тесты на Python + Selenium Grid + Allure и все это на jenkins ci крутится. Прогнать тесты для веб части - не проблема. Использую pytest и page object pattern.

 - для десктоп приложений - у нас есть купленный HP UFT, под который кстати написан фрейморк на питоне, для запуска из скрипта с передачей параметров.

Спасибо. Если что-то надо уточнить - пожалуйста, жду уточняющих вопросов.

Теперь вопрос, а стоит ли всё это затраченных усилий, и сколько времени у вас будет уходить на поддержу данного огорода технологий?

По вопросу, я бы на вашем месте исключил из интеграционного тестирования конечный десктоп интерфейс и лез бы прямо в БД для проверки проведённого платежа. У вас и так не понятно как будет работать СМС пароли, если вы ещё и построите свой фрэймворк на настолько разных технологиях, то сопровождать это будет нереально.

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

Хотя даже простой тест веб части важно: ведь система смотрит наружу - нужно, чтобы после обновления не слетал функционал (валидация полей, наличие веб-элементов на страницах и т.д.).

Теперь вопрос, а стоит ли всё это затраченных усилий, и сколько времени у вас будет уходить на поддержу данного огорода технологий?

 

По вопросу, я бы на вашем месте исключил из интеграционного тестирования конечный десктоп интерфейс и лез бы прямо в БД для проверки проведённого платежа. У вас и так не понятно как будет работать СМС пароли, если вы ещё и построите свой фрэймворк на настолько разных технологиях, то сопровождать это будет нереально.

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

В БД доступ не дадут. К сожалению.

По поводу СМС - решаем просто: СМС приходит на телефон, автоматом форвардится на определенный почтовый ящик, а там скрипт читает по POP3 и парсит код. Это уже сделано, осталось только отдельную симку под это дело выделить и почтовый ящик создать.

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

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

А функционал каждой из отдельных систем уже можно автоматизировать.

В принципе к тому же склоняюсь.

Каждую систему тестировать в отрыве от остальных систем. Независимо.

Ок.

Может кто-то еще выскажется?

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

 

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

А функционал каждой из отдельных систем уже можно автоматизировать.

без доступа к БД это конечно всё будет разваливаться, полностью согласна с Дмитрием. Был бы доступ, наверняка можно было бы и смски доставать из БД.

Неужели нельзя организовать тестовую БД?