Чек-лист тестировщика в финансовой компании06.12.2024 19:00

Добрый день! Меня зовут Анастасия, я QA-инженер команды бэкофиса в «Финаме». С 2022 года занимаюсь тестированием бэкофисных и торговых систем финансовых компаний. До перехода в QA работала в эксплуатации и поддержке торгово-клиринговой системы СПБ Биржи. Моя сильная сторона — глубокое понимание бизнесовой части тестируемого продукта.

За 5 лет работы в компаниях-участниках финансового рынка РФ я осознала: тестирование продуктов в финансовой компании не равно классическому тестированию. QA-инженер в сфере финансов отличается пониманием предметной области для обеспечения качества, особой усидчивостью, а также навыком работы с большим количеством данных.

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

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

Полезные навыки при тестировании ПО в финансовой компании

1. Знание предметной области

Тестирование ПО в финансовых компаниях (особенно бэкенда) осложняется тем, что нужно вникать в бизнес-смысл поставленных задач, а задачи обычно очень объемные.

Немного из личного опыта: в IT я пришла из финансовой сферы, образование у меня по профилю «Финансовые рынки и банки», работала я сначала с брокерами и депозитариями. Потом я устроилась в эксплуатацию торговой системы биржи, оттуда переросла в главного специалиста и захотела больше погрузиться в тестирование.

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

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

Давайте разберем, что вам может помочь при прокачке предметной области.

Определить интересные сферы тестирования

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

Например, мне ближе всего брокерская и биржевая отрасли: торги ценными бумагами и иными инструментами, специфика сделок, устройство торговых систем, специфика разных финансовых инструментов меня привлекали еще со времен университета.

Понять, что интереснее лично вам может помочь серия запросов в Google вида «Чем занимается банк/брокер/страховая компания». Или при использовании приложения своего банка задаться вопросом:, а что там под капотом и как оно работает?

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

Выяснить и разобрать основные термины

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

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

Изучить функционал приложений, которыми сами пользуетесь

Например, открыв приложение для инвестиций, взгляните на него глазами тестировщика:

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

Потренируйтесь и подумайте, какие в целом проверки можно применить к тому или иному функционалу.

2. Работа в SQL

Кажется очевидным, что без SQL где угодно в IT пропадешь. Но на практике выясняется, что приходится не просто делать select *, а соединять данные из разных баз, результатов хранимых процедур и выделять из них нужное.

На что особенно стоит обратить внимание при обучении SQL и что вам точно пригодится.

Агрегатные функции

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

Создание временных таблиц

Тут прошу обратить внимание: при практической работе очень часто нужные вам данные не хранятся в таблицах, а выводятся какой-либо хранимкой как ее результат.
Что с таким делать и как этот результат присоединить к другой таблице? Тут на помощь приходят временные таблицы! Давайте посмотрим на конкретном примере:
у вас есть хранимая процедура, которая выдает остатки по ценным бумагам на дату: exec [DB].[Proc_for_rest] @date=»2024–10–11». У процедуры 1 параметр — дата.
Вам нужно получить этот остаток, приджойнить к таблице клиентов — [DB].[Clients] (два поля clientID, Name) и вывести остаток + имя клиента, на чьем счете этот остаток находится.

Для упрощения задачи добавим условие, что accountID=clientID, то есть у клиента только 1 счет.

NB! Обычно текстовые значения не принято хранить в таблицах с большим количеством данных, хранятся только их числовые id. Например, в таблице с остатками по ценным бумагам не хранят имена клиентов, которые владеют счетами, как и названия этих ценных бумаг. Вместо этого хранят id счета и id ценной бумаги, это уменьшает время запросов к таблице, т.к. такие данные легче обрабатываются.

Возможная реализация:

#Удаляем временную таблицу с остатками, если она есть в БД.

DROP TABLE IF EXISTS #rests

#Создаем временную таблицу и обозначаем поля, как в результате вывода процедуры.

Create table #rests ( daterest DATE, accountID bigint, restondate bigint)

#Записываем результат вывода хранимой процедуры в таблицу.

insert into #rests (daterest, accountID, restondate)

exec [DB].[Proc_for_rest] @date=’2024-10-11’

#Джойним результат временной таблицы с таблицей клиентов.

select cl.Name, r.daterest, r.restondate from #rests r

inner join [DB].[Clients]  cl on rests.accountID=cl.clientID

Временные таблицы существенно облегчают работу с разными видами результирующих данных.

JOIN

Один из наиболее важных инструментов при работе в SQL. На практике я преимущественно использую LEFT и INNER.

Преобразование типов данных и в целом знание типов данных

Очень часто схожие данные хранятся в разных таблицах с разными типами. Например, вы собираете транзакции из разных источников в одну внутреннюю таблицу.

Есть два внешних источника:

1) внешний источник 1 (ext1) хранит номер транзакции в Varchar (50);

2) внешний источник 2 (ext2) хранит номер транзакции в int.

Во внутренней таблице данные хранятся в Varchar (100) в поле External Number. Вам нужно получить остальные атрибуты из внешних источников по внутреннему External Number. При использовании Join внутренней таблицы с первой таблицей не возникнет проблем, но при Join с таблицей внешнего источника вы получаете вместо результирующей таблицы красный текст вида:

Conversion failed when converting the varchar value to data type int in a JOIN

Что же в таком случае делать? Для этого запроса поможет преобразование данных функцией CAST — т.е. нужно будет преобразовать Number внешнего источника 2 в Varchar (100). В запросе это будет выглядеть так:

CAST (ext2.Number as Varchar (100))

(Кстати, полезная статья на тему CAST и второй функции преобразования данных CONVERT.)

3. Написание автотестов

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

И кому захочется руками делать регрессионное тестирование одного и того же отчета на тех же данных постоянно? Эту функцию исполнят автотесты.

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

Язык программирования для автотестов

Если вы ранее не писали автотесты и еще не знакомы с языками программирования, то рекомендую начать с изучения Python, так как он достаточно простой для изучения и является одним из самых распространенных языков для написания автотестов. Для изучения базовых понятий есть много бесплатных курсов и интерактивных учебников. Я начинала учить этот язык на «Питонтьюторе».

Библиотеки используемого языка

В Python одной из самых популярных (и удобных!) библиотек является pytest. В pytest много встроенных фишек, которые упростят написание автотестов. Например, при помощи parametrize легко можно создать параметризированные тесты.

Словари

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

#список , в котором каждый элемент - это массив : акция и ее цена
prices=[('AAPL', 160), ('BK', 90), ('OKE', 61)]

#выглядит не совсем понятно  + неудобно будет искать цену определенного актива, придется либо цикл для поиска писать, либо обращаться по индексам

#хорошо, что есть словари их встроенные методы!
pricesd= {}

for ticker in prices:
   pricesd.update({ticker[0]:ticker[1]})

#сформированный из изначального списка словарь, где по ключу можно обратьься к любому элементу и получить его значение
print(pricesd)
print(pricesd['OKE'])
#получить цену OKE из изначального списка при условии того, что знаем индекс элемента
print(prices[2][1])

Результат отработки вышенаписанной программы:

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

Вывод и полезные ссылки

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

Основные направления для изучения:

предметная область,
SQL,
написание автотестов.

Надеюсь, что статья окажется вам полезна!

Приложения

Также хочу поделиться несколькими ссылками:

Статья на тему CAST и второй функции преобразования данных CONVERT: https://learn.microsoft.com/ru-ru/sql/t-sql/functions/cast-and-convert-transact-sql? view=sql-server-ver16
«Питонтьютор» — интерактивный учебник по Python: https://pythontutor.ru