Рсхб интех чем отличается

РСХБ-Интех

Диджитал-сердце Россельхозбанка. Мы занимаемся цифровой трансформацией крупнейшего сельскохозяйственного банка России.

Дата основания компании 2016
Количество сотрудников 2000+
Ссылка скопирована!
Ошибка отправки
Произошла ошибка при отправке вашей
заявки, попробуйте отправить заново

Мы занимаемся цифровой трансформацией банка

Сервисы для удаленного пользования

Наши сервисы помогают миллионам клиентов удалённо пользоваться банковскими услугами, оформлять карты, брать кредиты и инвестировать

Новые банковские продукты
Разрабатываем новые банковские продукты для Россельхозбанка и улучшаем текущие.
Маркетплейс для агропредпринимателей

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

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

Быть в РСХБ-Интех — значит

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

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

Чувствовать заботу компании о здоровье и благополучии сотрудников, присоединившись к нашей расширенной программе ДМС

Совершенствовать свои навыки и попробовать себя в новых направлениях и стартапах

Наша команда

Мы поддерживаем гибкий формат работы — работаем как удалённо, так и в офисах по всей стране. Наши сотрудники живут в Москве, Уфе, Пензе, Краснодаре, Волгограде, Владимире, Санкт-Петербурге, Новосибирске и других городах — их список постоянно пополняется.

Мероприятия

Показано 0 из 0

Офис на карте

Офис РСХБ-Интеха:
г. Москва, ул. Профсоюзная, д. 125А
Офис Россельхозбанка:
г. Москва, Пресненская наб. 10, стр. 2

Видеообзор офиса РСХБ-Интех

Внутренние документы

Специальная оценка условий труда
Политика в отношении обработки персональных данных
Противодействие коррупции

Обратная связь по вопросам противодействия коррупции

Обращения принимаются по электронной почте doverie@intech.rshb.ru или телефону (495) 363-02-89

Прием обращений по телефону осуществляется ежедневно, кроме выходных и праздничных дней, с 09:00 до 18:00 (понедельник-четверг) и с 09:00 до 16:45 (пятница) по московскому времени.

Россельхозбанк

отличается от системы к системе. Мы внимательно изучаем все доступные технологии на рынке и внедряем самые передовые из них.

На данный момент в РСХБ используется следующий стек:

Центр разработки ЦРФТ РСХБ-Интех

• Java 8/11 (Spring Boot),
• PHP (Magento 2),
• JavaScript (React, Vue.js),
• Flutter/Dart,
• Python,
• NodeJs,
• PostgreSQL,
• MySQL,
• Elasticsearch,
• Redis

Data Science, ИИ

• Hive,
• PostgreSQL,
• GreenPlum,
• JupyterLab,
• Python: pandas, seaborn, sklearn, xgboost, catboost, tensorflow, keras, pytorch, transformers,
• Git,
• Docker,
• MLFlow

ДИТ, РСХБ — Интех

• .NET Core 5.0,
• T-SQL,
• Vue.js,
• HTML5,
• SCSS,
• Javascript,
• Typescript,
• Webpack,
• GitLab,
• Jira,
• Kafka,
• ActiveMQ,
• react/redux

Проекты «Россельхозбанка»

«Своё Фермерство»

«Своё Родное»

«Своё Жилье»

«Своё Село»

Маркетплейс драгоценных монет от РСХБ

Финансы: потребительские кредиты, кредитные и дебетовые карты

«Виртуальный помощник»

«Цифровой офис онлайн»

Рассказываем

о будущем и настоящем на стыке финтеха и агротеха

Я б в финтех пошёл, пусть меня направят

TechTalk с Михаилом Вронским (HighLoad++)

TechTalk с Денисом Рылеевым (DevOps Conf)

Flutter вот-вот завоюет Web

Агротех в стартапах: интеллектуальный подход к фермерству

Портал в новое фермерство или агротех на цифре: опыт Россельхозбанка

. и показываем

Вакансии

Тест-менеджер нагрузочного тестирования

Ведущий инженер по нагрузочному тестированию

Руководитель направления тестирования

Инженер по автоматизации тестирования

DBA Specialist / Администратор базы данных PostgresSQL (удаленно)

Либутина Екатерина

Вишневская Полина

Жукова Валерия

Дмитриева Екатерина

Альтер Мария

События осени

Saint TeamLead Conf 2021

Saint HighLoad++ 2021

TestDriven Conf 2021

HighLoad++ 2021

На SaintTeamLead Conf (16 и 17 сентября) и SaintHighLoad++ (20 И 21 сентября) с 10-00 до 19-00 на стенде Россельхозбанка тебя ждет VR-квест. Знакомые темы в незнакомом мире: гуляй по средневековому замку, собирай артефакты, отвечай на вопросы и получай призы.

Кроме того, мы подготовили стресс-тест, приходи на стенд и попробуй!

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

Призы для победителей и подарки для всех участников

Прошедшие события

HighLoad++ Весна 2021

DevOps Conf 2021

TechLead Conf 2021

Организаторы

Шершов Андрей

Исполнительный директор Департамента информационных технологий

Тагинцев Кирилл

Арт-директор, Управляющий директор экосистемы

Россельхозбанк переходит на отечественные решения: рассказываем о нашем выборе

Последние несколько лет в России проходят под флагом миграции на российские аналоги зарубежных сервисов. В 2022 году эта проблема проявилась особенно остро, вынудив многие компании в экстренном режиме искать отечественную замену привычным решениям, как в области ПО, так и в железе. Мы также столкнулись с такой задачей. В новом материале Григоренко Вадим Андреевич, исполнительный директор Департамента информационных технологий Россельхозбанка (РСХБ), рассказывает о переходе РСХБ на продукты российских компаний, какие решения использовали до этого и чего до сих пор очень не хватает.

Серверы

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

Раньше РСХБ закупал серверы у лидеров, таких как HP, Lenovo, IBM, Oracle и Huawei. У них уже достаточно продуманные решения. Конечно, представленное в России железо по сравнению с импортными имеет ряд ограничений и минусов. Но для многих задач его более чем хватает. В отношении имеющихся минусов — компании движутся к их устранению, набираются опыта и развивают продукты.

В РСХБ уже прошли две поставки российских серверов отечественных вендоров DEPO и «Звезда». Они пока не ставятся на уровень критичных систем банка, но в целом уже внедрены в продуктивную и тестовую среду, постепенно на них разворачиваются тестовые системы РСХБ или мигрируют уже существующие не первого уровня критичности. До конца 2023 года банк доведет долю использования отечественных серверов до 15% (около 170 серверов) от общей инсталляционной базы. В 2024 году планируется увеличить этот показатель до 40%.

В серверах DEPO и «Звезда» используются процессоры Intel Xeon 2 и 3 поколений. К сожалению, в РСХБ нет серверов с отечественными процессорами. При этом банк готов поддержать подобные решения, если они будут подходить под заявленные требования.

Вендоров РСХБ выбирает на основании открытого конкурса. Решения обязательно должны быть в Реестре телекоммуникационного оборудования российского происхождения (ТОРП), иметь нужную производительность и успешно пройти тесты на территории банка. В текущем конкурсе таких компаний уже больше пяти. В РСХБ довольно широкие требования, и многие компании могут им соответствовать.

Переходим на Linux

В Россельхозбанке в инфраструктуре уже давно в небольших количествах эксплуатируются серверные версии Astra Linux и Alt Linux. В будущем доля Linux-систем также будет расти. Дополнительных проблем переход на новую систему не вызывает.

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

Банк не планирует останавливаться на Astra Linux и Alt Linux. В этом году РСХБ собирается проводить большой конкурс на закупку российских ОС для серверов и для рабочих станций.

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

С Microsoft Office на Р7-Офис

До сравнительно недавнего времени РСХБ закупал офисные решения Microsoft, и лицензия на пакет действует до сих пор. При этом банк давно начал активный переход на офисный пакет Р7-Офис — уже приобрели 9270 лицензий и продолжаем наращивать объемы закупок. Решения выбираются на основе открытых конкурсов, в которых может поучаствовать любой вендор. Р7-Офис полностью устроил и ценой, порой в два раза ниже, чем у других участников конкурса, и своей функциональностью.

Р7-Офис поддерживает те же форматы документов, что и Microsoft Office, которые при открытии не переформатируются, что очень удобно. В целом переходить на Р7-Офис оказалось не так болезненно, как многие полагают. При сравнении с Microsoft Word грандиозные отличия замечены не были, а Powerpoint в какой-то степени даже оказался менее удобным. Другое дело Excel — в этом плане к российскому решению еще стоит привыкнуть из-за заметной разницы в функциональности.

В целом команда Р7-Офис принимает претензии и предложения по доработке продукта, в том числе от наших технических специалистов. Периодически специалисты РСХБ отправляют в компанию отчеты и рекомендации. Коллеги из Р7-Офис быстро выходят на реализацию и отработку претензий. Кроме того, Р7 ведет блог с «лайф‑хаками» как облегчить жизнь пользователю Р7. Есть центр поддержки с подробным описанием вопросов, связанных с работой Р7 (и макросы, и API, и плагины и многое другое), а также Telegram-канал, в котором разработчики оперативно отвечают на различные вопросы.

При развертывании пакета Р7-Офис в РСХБ проблем не было, все прошло бесшовно. Переход сотрудников также проходит мягко, поскольку работники пока могут параллельно пользоваться решением Microsoft ввиду действующей лицензии. Жестко на Р7-Офис мы сейчас никого не загоняем. На старте в некоторых департаментах сотрудники были слегка напуганы, но испуг прошел буквально за день два, когда успели опробовать новое решение. Большого негатива в компании не наблюдалось. Постепенно доля использования нового офисного пакета растет.

В свое время Россельхозбанк закупил более 25 тысяч лицензий Microsoft Office для своих сотрудников и пока может себе позволить пользоваться зарубежным решением. При этом к концу этого года банк планирует перевести 100% сотрудников на пакет Р7-Офис.

ВКС

Что касается видеоконференцсвязи (ВКС), тот тут вопрос был решен задолго до 2022 года. В РСХБ уже более 8 лет есть действующий контракт с российской компанией TrueConf. Сначала платформа появилась на уровне региональной сети, после чего была внедрена во всем Банке.

Главный плюс TrueConf — возможность самостоятельно настраивать ограничения по пропускной полосе. Зачастую офисы банка установлены в весьма удаленных регионах России, где услуги по ширине пропускной способности канала связи либо отсутствуют, либо очень дорогие. Следовательно, для исключения лишних затрат при сохранении возможности пользоваться ВКС в региональной структуре был сделан выбор в пользу решения с возможностью ограничения пропускной полосы до 512 кбит на соединение, что очень хороший показатель.

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

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

Ещё один важный плюс — TrueConf входит в реестр отечественного ПО, что для РСХБ довольно критично при принятии решений. Кроме того, компания регулярно выпускает обновления, в том числе основанные на обратной связи от технических специалистов банка. Видна нацеленность коллег на результат.

К сожалению, переход сотрудников на TrueConf происходит не так спокойно, как на Р7-Офис. Работники часто жалуются на решение, и, действительно, есть вещи, с которыми неудобно работать. Со временем благодаря обратной связи проблем с TrueConf становится меньше. Например, раньше были нюансы с включающейся камерой. Теперь их нет, и сервис работает одинаково хорошо как на ПК, так и на устройствах с Android и iOS. Качественная регистрация претензий в данном случае стала ключевым стимулом к улучшению продукта.

СХД

Сейчас на российском рынке СХД два основных игрока, но в скором времени ожидается прибавление новых. Уже есть подходящие решения, и наше тестирование это доказало. В частности, тестировались AllFlash СХД: Yadro TATLIN.UNIFIED и Aerodisk N2 от компании «Аэродиск». После него было принято решение провести конкурс. В этом году Банк уже приобретет новую системы у компании-победителя. Сейчас в РСХБ используются решения Huawei, NetApp, HP и других крупных известных игроков.

Российские СХД по сравнению с зарубежными решениями на текущий момент проигрывают в функционале. Но в целом отечественные СХД уже способны закрыть значительную часть задач. Перспективы развития отечественных систем положительные. К концу 2023 года банк рассчитывает увеличить долю отечественных СХД в инфраструктуре до 15% от общего числа, к концу 2024 года — до 40%.

Стоит отметить, что РСХБ ориентирован на переход с классических СХД на гиперковергентные. Подобных решений сейчас на рынке гораздо больше и шире выбор. Такая перестройка инфраструктуры позволяет закрывать определенный круг задач поставками отечественных серверов с дисковыми полками. В целом наиболее критичным моментом сейчас является перестройска архитектуры под доступные решения.

Очень нужно, но пока нет

Смешно, но сейчас в России нет подходящих многофункциональных устройств (МФУ). Казалось бы, это довольно простое решение. Но, к сожалению, в ТОРП нет ни одного российского производителя МФУ, у которого можно было бы закупать устройства, подходящие под все критерии программы по импортозамещению. Есть куча компаний, разрабатывающих подходящий софт, и ни одной компании с подходящими МФУ.

Приобретение оборудования не из ТОРП нельзя будет внести в отчет по программе импортозамещения, контролируемой Минцифры РФ. Регулятор строго следит за процессами перехода на российские продукты.

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

Также РСХБ занимается развитием собственных систем. Один из самых грандиозных проектов — разработка собственного частного облака. Оно базируется на Open Source решении и собственных доработках. Это классическое частное облако с порталом, куда может зайти пользователь в рамках выделенного под него пула ресурсов. В облаке пользователь без заявок и дополнительных согласований может управлять ресурсами, разворачивать системы, софт и так далее. Развитие подобных технологий в банке считают одним из наиболее перспективных направлений. Решение уже зарегистрировано в реестре.

О четырех основных продуктах РСХБ-Интех, уже отлаженных и активно используемых в банке, можно почитать в отдельной статье.

• Блог компании РСХБ.цифра (Россельхозбанк)
• IT-инфраструктура
• Софт
• IT-компании

Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию

Привет, Хабр! Меня зовут Андрей Околелов, я работаю ведущим инженером в Блоке обеспечения и контроля качества выпуска изменений ПО в РСХБ. В банковской сфере я работаю с 1992 года, с 2018 основная деятельность — тестирование банковских приложений.

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

Весь жизненный цикл приложения сопровождается тестированием. Передать написанный код куда‑то без тестирования нельзя. В свою очередь в теме тестирования одним из ключевых вопросов является поиск данных для теста.

Тест включает три этапа: формирование условий, воздействие и проверка результата. Формирование предусловий — значит найти договор, на основе найденного договора найти новый договор и проверить, что договор создан. Все вроде бы просто: разработчик сделал инструмент, SQL‑запрос, провел тест, прогнал его в Jenkins, тест прошел. К этому процессу подключается тестировщик, говорит, что все здорово, но добавляет и свой критерий по договору:

• дата открытия договора (пример: в 2020 году ЦБ выпустил новое указание № 10 005);
• тип и вид договора (простой, сложный, красный, в национальной или иностранной валюте);
• валюта договора (рубль, юань, доллар, евро);
• дата закрытия.

Разработчик снова посмотрел; подумал, что все просто; и сделал. Тестировщик обрадовался, что ему достанется меньше работы, и добавил новые критерии поиска для тестов:

• тип клиента (физлицо, юрлицо или ИП);
• группа клиента (вип, не вип, средний);
• справочник по террористам (включен или нет);
• справочник особого внимания (включен или нет);
• действующий (да или нет).

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

• счет 2 порядка;
• валюта (RUB, USD);
• остаток на счете (открыт, закрыт, зарезервирован);
• подразделение счета;
• статус (открыт, закрыт, зарезервирован).

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

Тут не мог не возникнуть целый ряд проблем.

• Монолит, с которым тяжело разбираться.
• Монолит перемещается от теста к тесту. При перемещении разработчик может добавить что‑то ненужное или упустить очень важное.
• Проблема дублей. Поскольку постоянно что‑то куда‑то перемещается, скриптов становится много, они похожи как две капли воды друг на друга, но в чем‑то разница есть. При этом проще написать свой скрипт, чем разбираться в существующем.
• Нет единства в запросах. Хотя на проекте утвержден кодстайл, и для любого скрипта разработчик должен соблюдать некие правила, все равно у каждого разработчика получается по‑своему, что не позволяет проводить единый анализ.
• Выдача запроса: выдает в основном единичные элементарные данные (ID, CollectionId и т. д.).
• Неудобства при переносе запроса из проекта в SQL develop для тестирования и обратно, принимаем как должное.
• Для написания запроса требуется уверенное знание структуры БД.

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

• FrameWork для работы с текущей БД и на перспективу. Поскольку первая и основная задача — это поиск данных, чтобы на них потом воздействовать, мы рассмотрели вопрос с FrameWork для работы с текущей БД и на перспективу. Например, сейчас у нас проходит проект импортозамещения, в котором одна БД меняется на другую.
• Понятная, удобная выдача с необходимым набором данных.
• Дружественный инструмент для разработчика и тестировщика. Члены команды, работающей над проектом, должны понимать друг друга, разговаривать едиными терминами.
• Удобный инструмент разработчика для формирования SQL запросов на основе модели данных и на основе элементов предметной области. Есть модель, мы ее «рисуем». Абстрагируясь от этой модели, мы должны еще создать инструмент, работающий не на модели, а на основе элементов предметной области. То есть мы говорим уже не про таблицу как таковую, а, например, про продукт.

Вот конкретный пример того, что раньше у нас было на проекте.

По нему сразу видны проблемы, о которых я уже говорил. Первая: query запросы — это как string. В задачи первостепенные ставилось уйти от string и перейти к какому‑то объекту. Второй момент: минималистичная выдача, то есть выдает какой‑то один ID. Я посмотрел и поискал на проекте, у меня есть часто используемые таблицы. В моменте я нашел по одной таблице в варианте SQL‑запросов и в варианте выдачи порядка 40–45 классов, работающих с одной таблицей, что тоже совершенно неудобно для работы.

Мы рассмотрели, что можно задействовать в работе, и остановились на FrameWork Hibernate. Мы сделали первый DAO (Data Access Object) — инструмент, который обращается к базе данных и возвращает нам результат. Здесь ничего особо интересного нет, замечу лишь, что для себя мы нашли нечто новое: класс может возвращать не только список сущностей, но и один экземпляр. Все зависит от того, как построен запрос. Мы в DAO всегда возвращаем только список, ограниченный нашим максимальным результатом. А уже класс сервиса, который будет обрабатывать результат, который мы получаем из данных, уже сам решает, что он должен вернуть: какую‑то коллекцию или единичный результат.

Далее приведу пример реализации таблицы. Это никого не удивляет, у всех есть такое. Но для себя мы получили четкий набор атрибутов и данных, что ранее было проблемой. Кроме того, мы отказались от всех связей, которые можно организовать в Dto классе, и оставили только связи 1:1. В этом случае у нас класс данных становится объемным. Это тоже дало свои плюсы.

В рамках реализации цели дружественности инструмента было больше организационных моментов: посмотреть на документы проекта, что уже сделано и как это было реализовано, а также еще раз это дело пересмотреть. Какие вопросы были проработаны.

Особое внимание уделили параметрам для запросов. Параметры надо всегда показывать перед тем, как мы будем выполнять запрос. Их должны видеть не только разработчики (для которых название параметра C_CURRENCY = 840 вполне понятно), но и тестировщики, которые со временем привыкнут к названию C_CURRENCY и будут понимать, что это валюта. Но лучше сразу проявить дружелюбность и вывести описание элемента предметной области ВАЛЮТА.

Формирование JavaDoc. Ранее на проектах были приняты комменты на классах, методах и атрибутах. Мы посмотрели, подумали «да, это хорошо», но все же перешли на JavaDoc. Мы посмотрели, как это должно формироваться, определились с шаблонами на формирование классов и описание методов, какие теги и что мы должны писать. Помимо прочего, JavaDoc оказался в некоторых случаях полезен не только для классов и методов, но и для атрибутов. То есть если атрибут используется на 500 строке класса, просто наведение курсора на этот атрибут сразу показывает, что там есть. Не нужно перемещаться к атрибуту и читать комменты к нему.

Названия шагов теста и результат шага, название методов и классов. Дружественность должна быть обоюдная. При чтении allure‑отчетов тестировщик должен видеть термины, с которыми он привык работать. Также мы еще раз пересмотрели структуру, формирование package, наименования методов, классов и названия атрибутов.

Вот пример с названиями атрибутов класса Dto. При формировании каждый атрибут ассоциируется с колонкой в БД. В данном случае c_name c_registr_num . Мы префикс удалили, а все остальное мы в CamelCase вводим. То есть не нужно придумывать ничего нового, уже все есть, и при новых выводах любой атрибут уже будет ассоциироваться с той колонкой, которую планируется использовать.

Для атрибутов, организующих link, мы тоже создали свое правило. То есть отбросили префикс «С подчеркивание» и добавили в нему link с простым названием. База у всех организована так: есть таблица клиентов, есть клиент юрлицо. Есть таблица продукт и производная продукта — договор. Они всегда идут вместе. Если потом назвать в старшем наследуемом классе «клиент» то мы в итоге получим клиент‑клиент, что крайне неудобно. Когда используем link, мы понимаем, что сразу идем к какому‑то объекту и просто переносим link‑клиент и link‑продукт, или link‑клиент1 и link‑клиент2. То есть сразу все понимаем, нет никаких разногласий.

Анализируя наш проект, мы заметили, что у нас довольно простой select, то есть select from where и то же самое с условием join — select from join where .

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

Мы назвали инструмент QueryBuilder. Он четко повторяет то, что мы делаем, поддерживает математические и логические операции, некоторые функции БД.

Вот код, сгенерированный этим инструментом.

Что мы в итоге получили. От стиля организации и документации проекта просто отойти невозможно. Генератор выдает select строго в нужном формате.

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

И тут проявилась другая проблема — проблема дубликатов. Есть требование — найти договор, где у клиента есть какой‑то тип, или найти клиента, где у договора есть какой‑то тип. В нашем случае получается, что и в билдере для договора и в билдере для клиента есть одни и те же требования — тип. Возникла идея их объединить. То есть договор объединить с клиентом.

Мы их даже не объединяем, а наследуем. В итоге мы получили: запрос на поиск клиента с параметрами 1 и 2 (которые могут иметь свои параметры) реализуется с использованием инструмента, обладающего деревом критериев, который накрывает все требования. Такие запросы исполняются теперь просто и быстро.

Зная, как работает инструмент, попробуем его использовать. Ниже справа в ТК № 1000 представлены реальные условия из нашей работы. Слева то, что написать тестировщик — иди туда не знаю куда, возьми то не знаю что. Справа уже разработчик выделил ключевые моменты, области и критерии для поиска.

При использовании нашего инструмента получается вот такая запись. Мы это назвали ParametersBuilder. Мы тут увидим joinClCorp — это юрлицо, имеющее статус и один в один повторяющее те критерии, которые и выделил разработчик во время чтения предусловий теста.

Давайте теперь попробуем разработать наш инструмент. Первое — любой билдер имеет целевую таблицу, с которой мы будем работать. Целевых таблиц может быть несколько, в том числе по умолчанию (продукт, клиент, договор и т. д.). В данном случае у нас одна таблица.

Первую часть QueryBuilder мы нарисовали, конструктор сделали, идем дальше.

Раньше запросы были совершенно простые: select from where и select from join where . Написали первый критерий select from where .

Второй пример, когда выборка идет из какой‑то другой таблицы, и здесь есть select from join where .

В итоге мы за 5–10 минут создали новый инструмент. С ним можно уже идти работать.

Что мы еще получили. Приятные бонусы в Allure. Вот фрагмент Allure. Его читает тестировщик, видит нужные параметры и знакомые термины, которыми оперирует. Есть объект и сразу можно посмотреть, что еще отобрано. По реквизитам объекта можно однозначно определить выбранный экземпляр. Тестировщик видит все это удобство и снова благодарит разработчика.

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

Какой эффект мы в итоге получили.

• Разработан удобный инструмент поиска данных для разработчика.
• Инструмент удобен для всей команды.
• Понимаем, как будем развивать и актуализировать.
• Начала решаться проблема дубликатов.
• Быстрый вход в проект.

Момент с быстрым входом в проект объясню на примере. У нас сейчас есть стажерская программа. В нашем понимании типичный стажер — молодой человек, имеющий средние познания в java и очень общие познания в тестировке. Однако он совершенно не знает тестируемую систему, а также структуру ее БД. Но с помощью разработанного нами инструмента стажер способен начать писать тест в совершенно новой области уже после третьего занятия.

В общем и целом, мы посчитали, что инструмент и централизация процессов дали нам средний прирост сдачи тестов на ревью на 20%. Можно сказать, что мы «наняли» еще одного разработчика в команду.

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

Случай первый. У нас есть таблица с колонкой «Филиал» и кодом филиала. Для этого случая у нас написан свой QueryBuilder. Итак, подставляем код, все хорошо, но через некоторое время начала появляться ошибка: «Счет принадлежит другому подразделению». Мы начали разбираться и получили случай второй. Он говорит о том, что, оказывается, в таблице есть еще и «Подразделение», и код подразделения формируется как код филиала — порядковый номер подразделения. Но в этом примере мы видим, что код филиала не соответствует коду подразделения. Опять же, это проблема некорректности БД. Ее мы решили исправленным билдером, и все заработало.

Теперь смотрим другой случай на основе номера 2. У нас всегда должны быть филиал 000 и подразделение 000–001. В одном из тестов был написан билдер от случая первого. Это я называю функциональной некорректностью скрипта, который мы написали. Также нам встретилась проблема некорректности самого скрипта и его производительности, то есть когда скрипт не был актуализирован, а отклик от БД был больше минуты. После актуализации отклик от БД составлял меньше секунды.

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

Задача 1: Импортозамещение. Задача, поставленная сейчас всем организациям в РФ. Нас она тоже, конечно же, зацепила. В РСХБ проводится большая работа по миграции на отечественные решения, и одна из ключевых систем сейчас переводится на другую БД. Работа будет выполнена, однако новую БД мы не запустим, пока бизнес не скажет, что у него есть уверенность в текущих делах. А это напрямую зависит от значимости и глубины системы. Чем значимее система, тем дольше будет период согласования запуска. В какой‑то момент у нас будут эксплуатироваться две системы, а значит и тестироваться будут они обе.

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

Задача 2: Простой доступ к данным заинтересованных лиц. Например, мы возьмем АБС — автоматизированную банковскую систему — и тестировщика. Однако регулятор и бизнес постоянно подкидывают задачи. В итоге изменения будут всегда, и всегда их необходимо будет тестировать. Соответственно, тестировщику необходим постоянный доступ к данным для проверки и написания новых тест‑кейсов.

Сами системы ценны тем, что они хранят. Возьмем пример с ДБО — дистанционное банковское обслуживание. Там все иначе: и FrameWork, и команды, другой тестировщик и т. п.. Но если глобально, то это лишь канал доступа к нашей основной системе, а основные данные опять таки хранятся в нашей АБС. И тут опять, тестировщику ДБО нужно иметь постоянный доступ к данным.

• Блог компании РСХБ.цифра (Россельхозбанк)
• Тестирование IT-систем
• SQL