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



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

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

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

Проверяем мы у себя, внутри ИТ — не воспроизводится, нормально всё работает. Попробовали повторить несколько человек. Не повторяется. Уже и права настроили как у пользователя — не помогло. И всё по шагам прошли 100500 раз, но никак не можем выйти на ошибку, всё работает. А у кассира не работает.

В итоге позвали кассира к себе, встали впятером у неё за спиной и стали смотреть за последовательностью её действий. И на наших глазах у неё ошибка воспроизводится! Сразу.

С первой попытки.

Не поняли. Повторили. И ещё.

А суть была в следующем: оказалось, что каждый раз она входила в лукап валюты, чтобы выбрать из списка рубли. В этом и была засада. Мы же этого не делали, зачем каждый раз проваливаться и что-то выбирать, когда мы знаем, что рубли это 810. Мы просто сразу привычно набирали 810, Tab и шли дальше.

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

Меня зовут Анастасия, я QA техлид платформенного стрима, а мой коллега Сергей — QA лид небольшой, но очень гордой продуктовой команды разработки. Сегодня мы поговорим о наболевшем и углубимся в специфику работы в банке.

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

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

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

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

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

При вводе значения 99999999999 в текстовое поле система падала, значение менялось на другое и выходила ошибка Arithmetic overflow. Ошибка была в том, что значение, которое позволяло ввести текстовое поле, не помещалось в размерность типа integer, которая была выбрана в таблице для записи этого числа из текстового поля. И замена числа, которое подставлялось, была из-за того, что база данных возвращала максимальное допустимое значение по формату.

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

Вообще локализация дефекта довольно интересное и не всегда тривиальное занятие.

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

Как мы определяем приоритетность отработки ошибок

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

Первая составляющая — бизнес. Продукты должны приносить прибыль. Банк не должен нести финансовые потери.

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

И третья — это законодательство. Требования ЦБ должны быть выполнены. Отчётность выгружена корректно. Любые проблемы с отчётностью тоже правятся оперативно, т.к. это грозит всякого рода штрафами.

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

Но даже к внутренним системам может быть предъявлен высокий SLA по решению проблем.
Например, все всегда замечают и, мягко говоря, не особо радуются, когда что-то случается с Jira или АС DevOps, потому что проблемы с ними напрямую влияют на скорость разработки, а это уже критично.

Про интеграцию

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

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

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

Не работало взаимодействие между двумя системами. Проверяем — сервер существует, база данных на нём есть. В конфиг-файле всё это корректно прописано. Всё вроде бы как должно быть, и где зарыта проблема — непонятно. В итоге оказалось, что после названия базы вместо Enter (перенос строки) был лишний пробел, который всё и ломал. Систему это сводило с ума, и она использовала этот пробел в дополнение к названию базы. Причём визуально это было совершенно незаметно: смотришь на два файла — они одинаковые, хотя в реальности в одном из них присутствует лишний незаметный пробел (должно было быть «dbname», а считывало «dbname »).

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

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

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

Один из самых сложных случаев в выявлении ошибок — когда ошибка повторяется только на промышленном стенде. Это может быть связано с более высокой нагрузкой (но её ещё можно локализовать на нагрузочном стенде) либо, что хуже, с непонятным стечением обстоятельств, которые не всегда просто отловить и воспроизвести. Это сложно, потому что несмотря на то, что логирование ведётся всегда, детализация логов может быть недостаточной, при этом расширение детализации логирования на стенде может быть чревато проблемами производительности.

Специфичные ограничения

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

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

В один из дней мы дорабатывали функционал, связанный с открытием счёта и выдачей карт. Мы установились на прод, и я, ни о чём не задумываясь, создал там клиента, открыл ему счёт и оформил карту, чтобы проверить, что доработка встала корректно. Клиент, естественно, придуманный, у него имя что-то типа «Тестовый Иван Иванович», а я ему открыл счёт в реальном процессинге банка.

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

Это заметил мой наставник и посоветовал сходить в поддержку, чтобы узнать, можно ли так делать. Я сходил к ним с этим вопросом и в ответ получил, ну скажем так, мягкое недовольство ситуацией и подтверждение того, что я сделал то, чего делать нельзя. После чего они ушли разруливать проблему — повезло, что информация ещё не ушла в Центробанк.

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

Не всем подходит работа в банке

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

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

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

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

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

Помимо всего этого, наша работа связана с часто возникающим стрессом, когда к нам все прибегают с какими-то вопросами и проблемами, если что-то не работает. И виноваты в этом, по их мнению, именно мы. И починить всё надо срочно, срок был ещё вчера, а если не сделаем, то… Ответственность, одним словом. К этому надо быть готовым, если хотите здесь работать.

Аббревиатуры

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

Общение, которого много

В банке тестировщику приходится очень много говорить. Общение может занимать до трети, а то и больше рабочего времени. Попросить совета, согласовать работу и исправления, обсудить план работ и т.п. С коллегами, разработчиками, начальниками, людьми из бизнеса. И здесь существует своя особенная этика. Надо уметь коммуницировать, знать гласные и негласные правила, находить подход к людям.

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

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