Русский
Русский
English
Статистика
Реклама

Блог компании росбанк

Код аудита поиск дублей, face detection и аномальные изображения

17.07.2020 22:22:26 | Автор: admin
Хабр, привет! Сегодня я расскажу, как мы делали аудит изображений, используя компьютерное зрение, сверточную нейронную сеть FaceNet, а также про кластеризацию гистограмм с целью поиска аномальных изображений.
image

Самоидентификация


Меня зовут Александр, я развиваю направление аналитики данных и технологий для целей внутреннего аудита группы Росбанк. Мы с командой используем машинное обучение и нейронные сети для выявления рисков в рамках проверок внутреннего аудита. В нашем арсенале сервер ~300 GB RAM и 4 процессора по 10 ядер. Для алгоритмического программирования или моделирования мы используем Python.

Введение


Перед нами стояла задача проанализировать фотографии (портреты) клиентов, сделанные сотрудниками банка во время оформления банковского продукта. Наша цель выявить ранее непокрытые риски, исходя из этих фотографий. Для выявления риска мы генерируем и тестируем набор гипотез. В этой статье я опишу какие гипотезы мы придумали и как мы их тестировали. Для упрощения восприятия материала буду использовать Мону Лизу эталон портретного жанра.


Контрольная сумма


Сперва мы использовали подход без машинного обучения и компьютерного зрения, просто сравнивая контрольные суммы файлов. Для их формирования мы взяли широко распространённый алгоритм md5 из библиотеки hashlib.
Реализация на Python*:
#алгоритм определения контрольной суммы with open(file,'rb') as f:    #последовательно берём блоки файла определенного размера    for chunk in iter(lambda: f.read(4096),b''):        #накопительно калькулируем контрольную сумму файла        hash_md5.update(chunk)

При формировании контрольной суммы мы сразу проверяем наличие дублей с помощью словаря.
#итерируемся по файлам в папкеfor file in folder_scan(for_scan):    #определяем контрольную сумму для файла    ch_sum = checksum(file)    #проверяем была ли уже такая контрольная сумма в проверяемых файлах    if ch_sum in list_of_uniq.keys():        #логика в случае неуникального ключа, например, мы фиксируем это в dataframe        df = df.append({'id':list_of_uniq[chs],'same_checksum_with':[file]}, ignore_index = True) 

Этот алгоритм невероятно прост с точки зрения вычислительной нагрузки: на нашем сервере 1000 изображений обрабатывается не более 3 секунд.

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

Ключевые точки (компьютерное зрение)


Несмотря на положительный результат работы метода контрольных сумм, мы отлично понимали, что в случае изменения хотя бы одного пикселя в изображении его контрольная сумма получится кардинально другой. Как логическое развитие первой гипотезы, мы предположили, что изображение могло быть изменено по битовой структуре: подвергнуться пересохранению (то есть повторная компрессия jpg), изменению размера, обрезке или повороту.
Для демонстрации обрежем края по красному контуру и повернем Мону Лизу вправо на 90 градусов.

В таком случае дубликаты необходимо искать по визуальному контенту изображения. Для этого мы решили использовать библиотеку OpenCV, метод построения ключевых точек изображения и поиска расстояния между ключевыми точками. На практике ключевыми точками могут быть углы, градиенты цвета или изломы поверхностей. Для наших целей подошел один из самых простых методов Brute-Force Matching. Для измерения расстояния между ключевыми точками изображения мы использовали расстояние Хэмминга. На картинке ниже результат поиска ключевых точек на исходном и измененном изображениях (отрисованы 20 наиболее близких по расстоянию ключевых точек изображений).

Важно отметить, что мы анализируем изображения в черно-белом фильтре, так как это оптимизирует время работы скрипта и дает более однозначную интерпретируемость ключевых точек. Если одно изображение будет с фильтром сепия, а другое в цветном оригинале, то, когда мы приведем их к черно-белому фильтру, ключевые точки будут идентифицированы независимо от цветовой обработки и фильтров.
Пример кода для сравнения двух изображений*
img1 = cv.imread('mona.jpg',cv.IMREAD_GRAYSCALE)          # Исходное изображениеimg2 = cv.imread('mona_ch.jpg',cv.IMREAD_GRAYSCALE) # Изображение для сравнения# Инициализируем ORB определитель orb = cv.ORB_create()# Ищем ключевые точки с помощью ORBkp1, des1 = orb.detectAndCompute(img1,None)kp2, des2 = orb.detectAndCompute(img2,None)# Создаем Brute-Force Matching сравнительbf = cv.BFMatcher(cv.NORM_HAMMING, crossCheck=True)# Сравниваем ключевые точки.matches = bf.match(des1,des2)# Сортируем их по растоянию.matches = sorted(matches, key = lambda x:x.distance)# Создаем новое изображение с 20 наиболее близкими ключевыми точкамиimg3 = cv.drawMatches(img1,kp1,img2,kp2,matches[:20],None,flags=cv.DrawMatchesFlags_NOT_DRAW_SINGLE_POINTS)plt.imshow(img3),plt.show()

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

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

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

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

Контрольная сумма VS ключевые точки


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

Поиск аномальных изображений


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

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

Первый шаг состоит в переводе картинки в объект (гистограмму), который мы можем измерить для того, чтобы сравнить картинки по расстоянию между их гистограммами. По сути гистограмма это график, который дает общее представление об изображении. Это график со значениями пикселей по оси абсцисс (оси X) и соответствующим количеством пикселей в изображении по оси ординат (оси Y). Гистограмма простой способ интерпретации и анализа изображения. С помощью гистограммы картинки можно получить интуитивное представление о контрасте, яркости, распределении интенсивности и так далее.

Для каждой картинки мы создаем гистограмму с помощью функции calcHist из OpenCV.
histo = cv2.calcHist([picture],[0],None,[256],[0,256])


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

После того, как мы создали гистограммы для каждой картинки, мы можем просто обучить модель DBSCAN по изображениям для каждого сотрудника, который сфотографировал клиента. Технический момент здесь состоит в подборе параметров DBSCAN (epsilon и min_samples) для нашей задачи.

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

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

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

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

Есть ли лицо на фото? (Face Detection)


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

Такого рода реализация уже существует, и мы решили выбрать для нашей задачи MTCNN (многозадачная каскадная сверточная нейронная сеть) из модуля FaceNet от Google.
FaceNet это архитектура глубокого машинного обучения, которая состоит из сверточных слоев. FaceNet возвращает 128-мерный вектор для каждого лица. На самом деле FaceNet это несколько нейронных сетей и набор алгоритмов для подготовки и обработки промежуточных результатов работы этих сетей. Механику поиска лиц этой нейронной сетью мы решили описать подробнее, так как материалов об этом не так много.

Шаг 1: Предобработка


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

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

Шаг 2: P-Net


После создания разных копий нашей фотографии в ход вступает первая нейронная сеть P-Net. Эта сеть используя ядро 12х12 (блок), которое будет сканировать все фотографии (копии одного фото, но разного размера), начиная с верхнего левого угла, и двигаться вдоль картины, используя шаг размером в 2 пикселя.

После сканирования всех картинок разного размера MTCNN снова стандартизирует каждую фотографию и пересчитывает координаты блоков.

P-Net дает координаты блоков и уровни доверия (насколько точно это именно лицо) относительно содержащегося в нем лица для каждого блока. Оставлять блоки с определенным уровнем доверия можно с помощью параметра порогового значения.

При этом мы не можем просто выбрать блоки с максимальным уровнем доверия, потому что картина может содержать несколько лиц.

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

В данном примере желтый блок будет удален. В основном, результатом работы P-Net являются блоки с низкой точностью. На примере ниже представлены реальные результаты работы P-Net:


Шаг 3: R-Net


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


Шаг 4: O-Net


O-Net сеть последняя часть MTCNN сети. В дополнение к последним двум сетям она формирует пять точек для каждого лица (глаза, нос, углы губ). Если эти точки полностью попадают в блок, то он определяется как наиболее вероятно содержащий лицо. Дополнительные точки отмечены синим:

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

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

Про использование FaceNet хотелось бы добавить, что если вместо Мона Лизы вы станете анализировать полотна Рембрандта, то результаты будут примерно как на изображении ниже, и вам придется разбирать весь список идентифицированных лиц:


Заключение


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

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

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

* Пример кода взят из открытых источников.
Подробнее..

Анастасия Харитонова, Design Lead Росбанка, участвует в онлайн-конференции UX-марафон

13.10.2020 14:23:08 | Автор: admin
Друзья, привет!

15 октября в онлайн-конференции UX-марафон выступит Анастасия Харитонова, Design Lead в команде Малого бизнеса Росбанка.

image

В своем выступлении Юзабилити-тестирования Анастасия расскажет:

Почему проведение юзабилити-тестирования важно для выявления проблем и поиска решений;

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

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

Анастасия Харитонова признанный UX-эксперт, член Гильдии вольных проектировщиков и преподаватель в Нетологии.

Будет интересно. Присоединяйтесь!
Подробнее..

Реализация чистой архитектуры в микросервисах

25.05.2021 14:04:29 | Автор: admin
Привет хабр!

Сейчас многие проекты используют микросервисную архитектуру. Мы также не стали исключением и вот уже больше 2х лет мы стараемся строить ДБО для юридических лиц в банке с применением микросервисов.



Авторы статьи: ctimas и Alexey_Salaev



Важность архитектуры микросервиса

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

Начиная проект, было много обсуждений: какой же подход выбрать? как строить нашу новую систему ДБО? Началось все с обсуждений монолит vs микросервисы: обсуждали возможные используемые языки программирования, спорили про фреймворки (использовать ли spring cloud?, какой протокол выбрать для общения между микросервисами?). Данные вопросы, как правило, имеют какое-то ограниченное количество ответов, и мы просто выбираем конкретные подходы и технологии в зависимости от потребностей и возможностей. А ответ на вопрос Как же писать сами микросервисы? был не совсем простым.

Многие могут сказать А зачем разрабатывать общую концепцию архитектуры самого микросервиса? Есть архитектура предприятия и архитектура проекта, и общий вектор развития. Если поставить задачу команде, она ее выполнит, и микросервис будет написан и он будет выполнять свои задачи. Ведь в этом и есть суть микросервисов независимость. И будут совершенно правы! Но с течением времени команд становятся больше, следовательно растет количество микросервисов и сотрудников, a старожил меньше. Приходят новые разработчики, которым надо погружаться в проект, некоторые разработчики меняют команды. Также команды с течением времени перестают существовать, но их микросервисы продолжают жить, и в некоторых случаях их надо дорабатывать.

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

Граница микросервиса

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

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

Рассмотрим пример стандартного бизнес процесса для любого банка создание платежного поручения



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

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



Некоторые микросервисы не подходят под данную концепцию, но количество таких микросервисов в общем процентном соотношении небольшое и составляет около 5%.

Чистая архитектура

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

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

Популярная диаграмма которую можно найти по этой теме, была нарисована Бобом Мартиным в его книге Чистая архитектура:



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

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

Реализация чистой архитектуры в проекте

Мы перерисовали данную диаграмму, опираясь на наш сценарий.



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

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

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

Для сборки наших микросервисов на Java мы используем Gradle, поэтому основные слои сформированы в виде набора его модулей:



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

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

Встречаются задачи, когда нужно реализовать микросервис без БД или мы можем отказаться от DI, потому что задача слишком проста и ее быстрее решить в лоб. И если всю работу с БД мы будем осуществлять в модуле repository, то где же нам использовать фреймворк, чтобы он приготовил нам весь DI? Вариантов не так и много: либо мы добавляем зависимость в каждый модуль нашего приложения, либо постараемся выделить весь DI в виде отдельного модуля.
Мы выбрали подход с отдельным новым модулем и называем его или infrastructure или application.

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

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



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



Теперь осталось только добавить сам фреймворк DI. Мы у себя в проекте используем Spring, но это не является обязательным, можно взять любой фреймворк, который реализует DI (например micronaut).

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



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

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

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

Про код адаптеров, контроллеров и репозиториев особо нечего сказать, т.к. они достаточно простые. В адаптерах для другого микросервиса используется сгенерированный клиент из сваггера, спринговый RestTemplate или Grpc клиент. В репозитариях одна из вариаций использования Hibernate или других ORM. Контроллеры будут подчиняться библиотеке, которую вы будете использовать.

Заключение

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

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

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

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

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

Год в Scrum наблюдения скрам-мастера

25.07.2020 22:11:28 | Автор: admin
Друзья, привет! Меня зовут Александр Еремин, я скрам-мастер продуктовой команды PRO Daily Banking Росбанка. Мы работаем с сегментом малого и среднего бизнеса.
Сегодня я поделюсь наблюдениями скрам-мастера о первом годе жизни команды в новом фреймворке.

image



Почему мы решили пойти в Scrum? Причины банальные для многих компаний:
  • не совсем простые отношения между бизнесом и разработкой;
  • необходимость ускорить поставки;
  • понимание, что необходимо перестраивать процессы.

Движение к Kick-Off у нас заняло около полугода (с начала 2019 года): изучение, обучение, подготовка материалов и сбор необходимой информации. И вот, наконец,
3 июня 2019 года мы стартанули первый спринт.

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

О чем нужно помнить скрам-мастеру в этот период?

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

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

Scrum, как и LeSS, не терпят личной незрелости участников команд. Если команда не знает, что такое Scrum, никогда не работала в этом фреймворке и, тем более, если до этого уже работала в текущем составе, то я бы рекомендовал воздерживаться от флипа в LeSS сразу.

Выявление добровольцев на Kick-off (на который обычно отводится три дня) внутри ранее не работавшей по Scrum команде, скорее, носит фейковый характер. Если люди ранее не работали в этом фреймворке, едва ли они реально осознают, что это такое, и действительно могут говорить о своей готовности так работать.

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

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

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

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

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

Что нам дал Scrum за год?

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

Мы узаконили работу с техническим долгом и начали отводить ему время в спринтах. Договорились о пропорции 70% VS 30%, где 30% отвели на техдолг.

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

Запустили процесс Discovery значительно усилили погружение в шкуру клиента. Теперь все наши идеи, относительно того, что нам кажется, клиенту было бы полезно, мы проверяем непосредственно с клиентами. Создали среду, готовую к экспериментам и культуру готовности экспериментировать.

Внедрили CI/CD.

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

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

Внедрили систему мониторинга приложений и железа: теперь в режиме on-line есть возможность следить за состоянием одного и другого, и иногда получать сигналы до того, как пойдут звонки от клиентов. Построили ряд дашбордов для мониторинга бизнес-показателей, включая KPI в автоматическом режиме.

За год мы многое успели сделать, но наш путь еще продолжается.

PS Я намеренно не стал писать про этапы внедрения Scrum. Об этом сейчас много где можно прочитать. Если интересно, то потом могу написать отдельную статью.
Подробнее..

Как мы проектировали и строили Agile-пространство

03.02.2021 16:18:50 | Автор: admin
Так как agile и scrum сегодня строят большинство проектных работ внутри каждой большой компании, мы задумались над тем, каким должно быть офисное пространство нового типа пространство, которое будет заточено под agile, гибкость и творчество.

image

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

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

Когда мы начинали проектировать новое офисное пространство Росбанка в башне ОКО в Москва-Сити, мы поставили перед собой задачу сделать не офис в его привычном и устаревшем понимании, а творческий кластер, который позволит разработчикам, работающим по принципам agile и scrum, чувствовать себя максимально комфортно, а тем сотрудникам, кто еще не знаком с этой философией, приобщиться к ней.

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

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

image

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

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

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

image

Также на полуоткрытом в атриум балконе расположен Agile Hub. Зона целенаправленно сделана открытой, чтобы каждый сотрудник мог наблюдать за тем, как проходят собрания agile-команд. Как известно, регулярные встречи команд, критическая оценка хода работ и промежуточных этапов позволяют командам двигаться эффективнее и делать самое ценное, актуализируя при этом и бэклог. А открытое для всего банка agile-пространство помогает бОльшему количеству сотрудников знакомиться с такими подходами и приобщаться к ним.

image

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

image

Игровая зона, расположенная на основном перекрестке внутриофисных потоков недалеко от атриума, напоминает скомканный листок бумаги, на котором изображена одна из работ Ле Корбюзье. Кофе-поинты расположены на каждом этаже при входе.

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

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

image
Подробнее..

Fast-Unit или декларативный подход к юнит-тестам

03.09.2020 16:16:34 | Автор: admin

Всем привет! Меня зовут Юрий Скворцов, наша команда занимается автоматизированным тестированием в Росбанке. Одной из наших задач является разработка средств для автоматизации функционального тестирования.

В этой статье я хочу рассказать о решении, которое задумывалось как небольшая вспомогательная утилита для решения прочих задач, а в итоге превратилось в самостоятельный инструмент. Речь пойдет о фреймворке Fast-Unit, который позволяет писать юнит-тесты в декларативном стиле и превращает разработку юнит-тестов в конструктор компонентов. Проект разрабатывался в первую очередь для тестирования нашего основного продукта -Tladianta единого BDD-фреймворка для тестирования 4-х платформ: Desktop, Web, Mobile и Rest.

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

На первом этапе мы попытались воспользоваться готовыми инструментами, такими как assertJ и Mockito, но быстро столкнулись с некоторыми техническими особенностями нашего проекта:

  • Tladianta уже использует JUnit4 как зависимость, что делает сложным использование другой версии JUnit и усложняет работу с Before;
  • Tladianta содержит компоненты для работы с различными платформами, в ней есть множество сущностей крайне близких с точки зрения функционала, но с разной иерархией и разным поведением;
  • многие компоненты требуют значительной предварительной настройки и могут фонить (влиять на результаты других тестов) при массовом прогоне;
  • некоторые компоненты фреймворка используют другие активно развивающиеся зависимости, и, к сожалению, мы далеко не всегда можем положиться на их надежность и гарантии обратной совместимости, а значит проверять нужно и их работу;
  • некоторую функциональность фреймворка приходится полностью блокировать при запуске юнит-тестов (например, запуск Appium во время тестов крайне нежелателен, тем более, что он закончится ошибкой, поскольку сервер для него никто не поднимал);
  • необходимость толстых обвязок, а также реализации ожиданий: Mockito тут нам помочь полноценно не смог.

Первый подход к снаряду


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

@Testpublic void checkOpenHint() {    ElementManager.getInstance().register(xpath,ElementManager.Condition.VISIBLE,ElementManager.Condition.DISABLED);    new HintStepDefs().open(("Подсказка");    assertTrue(TestResults.getInstance().isSuccessful("Open"));    assertTrue(TestResults.getInstance().isSuccessful("Click"));}@Testpublic void checkCloseHint() {    ElementManager.getInstance().register(xpath);    new HintStepDefs().close("Подсказка");    assertTrue(TestResults.getInstance().isSuccessful("Close"));    assertTrue(TestResults.getInstance().isSuccessful("Click"));}

Или вообще вот так:

@Testpublic void fillFieldsTestOld() {    ElementManager.getInstance().register(ElementManager.Type.CHECK_BOX,"//check-box","",ElementManager.Condition.NOT_SELECTED);        ElementManager.getInstance().register(ElementManager.Type.INPUT,"//input","");        ElementManager.getInstance().register(ElementManager.Type.RADIO_GROUP, "//radio-group","");        DataTable dataTable = new Cucumber.DataTableBuilder()                .withRow("Чекбокс", "true")                .withRow("Радио", "not selected element")                .withRow("Текстовое поле", "text")                .build();        new HtmlCommonSteps().fillFields(dataTable);        assertEquals(TestResults.getInstance().getTestResult("set"), ElementProvider.getInstance().provide("//check-box").force().getAttribute("test-id"));        assertEqualsTestResults.getInstance().getTestResult("sendKeys"), ElementProvider.getInstance().provide("//input").force().getAttribute("test-id"));        assertEquals(TestResults.getInstance().getTestResult("selectByValue"), ElementProvider.getInstance().provide("//radio-group").force().getAttribute("test-id"));    }

В коде выше найти то, что именно тестируется, несложно, как и разобраться в проверках, но кода огромное количество. Если включить сюда софт проверки и описания ошибок, то читать станет очень сложно. А мы всего лишь пытаемся проверить, что метод вызвался у нужного объекта, при том что реальная логика проверок крайне примитивна. Для того чтобы написать такой тест, надо знать про ElementManager, ElementProvider, TestResults, TickingFuture (обертка, чтобы реализовать изменение состояния элемента в течении заданного времени). Эти компоненты отличались в разных проектах, мы не успевали синхронизировать изменения.

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

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

Меняем философию


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

@IExpectTestResult(errDesc = "Не был вызван метод set", value = "set",expected = "//check-box", convertedBy = Converters.XpathToIdConverter.class, soft = true)@IExpectTestResult(errDesc = "Не был вызван метод sendKeys", value = "sendKeys", expected = "//input", convertedBy = Converters.XpathToIdConverter.class, soft = true)@IExpectTestResult(errDesc = "Не был вызван метод selectByValue", value = "selectByValue",expected = "//radio-group", convertedBy = Converters.XpathToIdConverter.class, soft = true)@Testpublic void fillFieldsTestOld() {    ElementManager.getInstance().register(ElementManager.Type.CHECK_BOX, "//check-box", "",ElementManager.Condition.NOT_SELECTED);    ElementManager.getInstance().register(ElementManager.Type.INPUT, "//input", "");    ElementManager.getInstance().register(ElementManager.Type.RADIO_GROUP, "//radio-group", "");    DataTable dataTable = new Cucumber.DataTableBuilder()            .withRow("Чекбокс", "true")            .withRow("Радио", "not selected element")            .withRow("Текстовое поле", "text")            .build();    runTest("fillFields", dataTable);}

Что изменилось?

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

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

@IGenerateElement(type = ElementManager.Type.CHECK_BOX)@IGenerateElement(type = ElementManager.Type.RADIO_GROUP)@IGenerateElement(type = ElementManager.Type.INPUT)@Test@IExpectTestResult(errDesc = "Не был вызван метод set", value = "set", expected = "//check-box", convertedBy = Converters.XpathToIdConverter.class, soft = true)@IExpectTestResult(errDesc = "Не был вызван метод sendKeys", value = "sendKeys", expected = "//input", convertedBy = Converters.XpathToIdConverter.class, soft = true)@IExpectTestResult(errDesc = "Не был вызван метод selectByValue", value = "selectByValue",expected = "//radio-group", convertedBy = Converters.XpathToIdConverter.class, soft = true)public void fillFieldsTest() {    DataTable dataTable = new Cucumber.DataTableBuilder()            .withRow("Чекбокс", "true")            .withRow("Радио", "not selected element")            .withRow("Текстовое поле", "text")            .build();    runTest("fillFields", dataTable);}

Теперь код теста превратился в полностью шаблонный, параметры явно видны, а вся логика вынесена в шаблонные компоненты. Дефолтные свойства позволили убрать пустые строки и дали широкие возможности для перегрузок. Этот код почти соответствует BDD-подходу, предусловие, проверка, действие. К тому же, из логики тестов вылетели все обвязки, больше не нужно знать про менеджеры, хранилища тестовых результатов, код прост и легко читаем. Поскольку аннотации в Java почти не кастомизируются, мы ввели механизм конвертеров, которые из строки могут получать итоговый результат. Этот код не только проверяет сам факт вызова метода, но и id элемента, который его выполнил. Почти все существовавшие на тот момент тесты (более 200 единиц) мы достаточно быстро перевели на эту логику, приведя их к единому шаблону. Тесты стали тем, чем они должны быть документацией, а не кодом, так мы пришли к декларативности. Именно этот подход лег в основу Fast-Unit декларативность, самодокументируемость тестов и изоляция тестируемого функционала, тест полностью посвящен проверке одного тестируемого метода.

Продолжаем развитие


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

  • Package-generate отработка аннотаций, связанных с package-info. Компоненты, связанные с ними, обеспечивают загрузку конфигураций и общую подготовку обвязки.
  • Class-generate отработка аннотаций, связанных с классом теста. Здесь выполняются конфигурационные действия, относящиеся к фреймворку, адаптируя его к подготовленной обвязке.
  • Generate отработка аннотаций, связанных с самим методом теста (точкой входа).
  • Test подготовка инстанса и выполнение тестируемого метода.
  • Assert выполнение проверок.

Обрабатываемые аннотации описываются примерно так:

@Target(ElementType.PACKAGE) //аннотация является пакетной@IPhase(value = "package-generate", processingClass = IStabDriver.StabDriverProcessor.class,priority = 1) //указываем фазу и обработчик (обычно обработчик регистрируется в том же классе)public @interface IStabDriver {    Class<? extends WebDriver> value(); //здесь принимаем класс драйвера, который будет загружен вместо настоящего    class StabDriverProcessor implements PhaseProcessor<IStabDriver> { //класс обработчик        @Override        public void process(IStabDriver iStabDriver) {            //подмена драйвера фейковым        }    }}

Особенность Fast-Unit в том, что жизненный цикл можно переопределить для любого класса он описывается аннотацией ITestClass, которая предназначена для указания тестируемого класса и фаз. Список фаз указывается просто как строковый массив, допуская смену состава и последовательность фаз. Методы, обрабатывающие фазы, находятся так же с помощью аннотаций, поэтому возможно создать в своем классе необходимый обработчик и пометить его (плюс к этому доступно переопределение в рамках класса). Большим плюсом стало то, что такое разделение позволило разделить тест на слои: если ошибка в готовом тесте произошла в рамках фазы package-generate или generate, значит повреждена тестовая обвязка. Если class-generate есть проблемы в конфигурационных механизмах фреймворка. Если в рамках test ошибка в тестируемом функционале. Фаза test технически может выдавать ошибки как в обвязке, так и в тестируемом функционале, поэтому возможные ошибки обвязки мы обернули в специальный тип InnerException.

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

Здесь, наверное, уже возник вопрос, а откуда берутся инстансы тестирования. Если конструктор пустой, это очевидно: с помощью Reflection API просто создается инстанс тестируемого класса. Но как в этой конструкции передавать параметры или выполнять настройку инстанса после срабатывания конструктора? Что делать, если объект строится билдером или вообще речь идет о тестировании статики? Для этого разработан механизм провайдеров, которые скрывают за собой сложность конструктора.

Параметризация по умолчанию:

@IProvideInstanceCheckBox generateCheckBox() {    return new CheckBox((MobileElement) ElementProvider.getInstance().provide("//check-box").get());}

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

Автоматическая инъекция аргументов: положим у нас есть вот такой конструктор:

public Mask(String dataFormat, String fieldFormat) {    this.dataFormat = dataFormat;    this.fieldFormat = fieldFormat;}

Тогда тест этого класса с использованием инъекции аргументов будет выглядеть вот так:

Object[] dataMask={"_:2_:2_:4","_:2/_:2/_:4"};@ITestInstance(argSource = "dataMask")@Test@IExpectTestResult(errDesc = "Неверно сконвертировано значение", value = FAST_RESULT,expected = "12/10/2012")public void convert() {    runTest("convert","12102012");}

Именованные провайдеры


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

@IProvideInstance("Дата")Mask createDataMask(){    return new Mask("_:2_:2_:4","_:2/_:2/_:4");} @ITestInstance("Дата")@Test@IExpectTestResult(errDesc = "Неверно сконвертировано значение", value = FAST_RESULT,expected = "12/10/2012")public void convert() {    runTest("convert","12102012");}

IProvideInstance и ITestInstance связанные аннотации, позволяющие указать методу, откуда брать тестируемый инстанс (для статики просто возвращается null, поскольку в конечном итоге этот инстанс используется через Reflection API). Подход с провайдерами дает гораздо больше информации о том, что на самом деле происходит в тесте, заменяя вызов конструктора с какими-то параметрами на текст, описывающий, предварительные условия, так что, если конструктор вдруг поменяется, мы должны будем лишь поправить провайдер, но тест останется неизменным, пока не поменяется реальный функционал. Если же при ревью, вы увидите несколько провайдероов, вы обратите внимание на разницу между ними, а значит и особенности поведения тестируемого метода. Даже совершенно не зная фреймворка, а лишь зная принципы работы Fast-Unit, разработчик сможет прочесть код теста и понять что делает тестируемый метод.

Выводы и итоги


У нашего подхода оказалось немало плюсов:

  • Легкая переносимость тестов.
  • Сокрытие сложности обвязок, возможность их рефакторинга без разрушения тестов.
  • Гарантия обратной совместимости изменения имен методов будут зафиксированы как ошибки.
  • Тесты превратились в достаточно подробную документацию для каждого метода.
  • Качество проверок значительно выросло.
  • Разработка юнит-тестов стала конвейерным процессом, а скорость разработки и ревью значительно выросла.
  • Стабильность разработанных тестов хотя и фреймворк, и сам Fast-Unit активно развиваются, деградации тестов не происходит

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

Текущие проблемы и планы:

  • Рефлексивные вызовы создают некоторую сложность, поскольку не работает прямое перемещение в редакторе и убиваются примитивы. Мы рассматриваем варианты замены рефлексии на интерсепторы, однако при этом потеряются проверки приватных методов (сейчас фаст-юнит игнорирует модификаторы доступа тестируемых методов).
  • Обработчики фаз на данный момент могут обрабатывать только одну фазу.
  • Обработчики фаз определяются однозначно и не могут быть переопределены.
  • На данный момент написано достаточно мало готовых компонентов, то есть сейчас инструмент является в первую очередь именно ядром юнит-тестов.
  • На данный момент Fast-Unit реализован на базе junit4, но в ближайшее время мы собираемся добавить поддержку junit5 и testng
Подробнее..

Tladianta. Сервис по автоматизированному тестированию в Росбанк

06.10.2020 20:18:31 | Автор: admin


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


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


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


  • степень "зрелости" ручного тестирования на проекте;
  • технологий, используемых в процессе разработки продукта;
  • целей внедрения автоматизированного тестирования и вовлечения команды;
  • компетенции непосредственных исполнителей
    и т.д.

Недостаточная проработка этих моментов может привести к:


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

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


Итак, вернёмся для начала в ноябрь-декабрь 2019 года.


Legacy


image


  • Отдел автоматизированного тестирования в составе 8 человек. Задачи поддержка и запуск автотестов, работа с вендорами, поддержка фреймворка АТ.
  • Для достаточно большого числа команд были разработаны наборы автотестов. Фреймворк разработка 2018 года, основанная на наработках, которые принесла с собой действующая на тот момент команда автоматизаторов.
  • В связи с ИТ-трансформацией и появлением отдельных команд из состава отдела автоматизированного тестирования в эти команды были переданы квалифицированные специалисты.

Вроде всё неплохо, но:


  • До 80% работ выполнялось сотрудниками вендора, сотрудники отдела зачастую занимались приёмкой Pull-requests и могли быть оторваны от реального процесса. Вовлеченности это не помогало. Собственно, как и развитию.
  • Фреймворк 2018 изначально был реализован с архитектурой, при которой работа нескольких независимых команд попросту невозможна из-за постоянного риска сломать кому-либо их набор тестов. Технологии остались в 2018 году без возможности что-то улучшить или исправить (решалось только работой в разных ветках без возможности сделать даже merge).
  • В отделе осталось формально 2 человека 1 в Москве и 1 в Нижнем Новгороде.
  • Каждая команда может выбирать свой стек технологий и языки. Зоопарк технологий виднелся уже буквально на следующей улице.
  • В 2020 и далее планировался запуск большого числа команд.

Возникают понятные вопросы: как сделать автоматизацию действительно полезной? Как обеспечить развитие? Как помочь всем?


Двигаемся к цели


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


Далее, подключились (и доработали со своей стороны) к концепции тестирования как сервиса, предложенную нашими коллегами. Последним решили вопрос что делать с зоопарком по факту до момента его действительного появления.
Так, несколько непоследовательно, но мы пришли к понятию Автоматизированное тестирование как сервис. Наша команда стала Центром экспертизы с функциями:


  • Разработка и развитие Core-фреймворка Tladianta;
  • Внедрение практик автоматизированного тестирования по запросам команд:
    • Внедрение и сопровождение инструментов АТ;
    • Обучение и консультации по развитию сотрудников в направлении АТ;
    • Вендор менеджмент по АТ;
    • Помощь при проведении технических интервью;
  • Старт и развитие темы с Chapters&Guild Автоматизированного тестирования. Тут мы стали пилотом по банку. О том, что это, как и в чем помогает в следующих статьях, тема достаточно обширная.

Под данную концепцию было согласовано расширение штата ЦК АТ с 2 человек до 6 (4 в Москве и 2 в Нижнем) и в дальнейшем до 9 человек, каждому из которых досталось по одному основному направлению и 1-2 резервных.


Основные шаги


image
Далее на каждом из шагов схематически представлен % предполагаемой активности как со стороны обратившейся команды, так и нашего отдела


1. Определение потребности в автоматизации


image
Важная активность, которая позволяет перейти из состояния мы хотим автоматизированное тестирование к мы хотим автоматизированное тестирование, потому что
В основном чаще всего болит где?


  • Срываем сроки релизов
    • Длительный регресс.
    • Мало людей на ручных тестах.
    • Нет данных для адекватной оценки качества релиза.
    • Долго проверяем исправления.
  • Качество самого ПО :)
    • Долго ищем дефекты.
    • Проверяем только "стандартный" функционал системы без учета доработок под банк
    • Очень много проверок интеграционных взаимодействий.
    • Люди все мы иногда ошибаемся, ленимся.
    • Нужно проверять небольшую части функционала на большом объёме данных. Или проверки сложно делать вручную
      Все это приводит к мысли: а не внедрить ли нам АТ?.

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


Опросник

image


Итог: команда в общем понимает, для чего им автоматизированное тестирование. ЦК АТ имеет точку старта в виде заполненного опросника. Ну а если проблемы с этим, тогда заполняем его вместе на следующем шаге.


2. Обращение в ЦК АТ


image
Проводится стартовая встреча с командой, на которой:


  • Обсуждаем или до-заполняем опросник;
  • Мы рассказываем о доступных возможных сервисах:
    • Миграция/актуализация существующих автоматизированных тестов при наличии автоматизатора в команде;
    • Поиск сотрудника (автоматизатора) в команду;
    • Привлечение подрядчика;
    • Обучение специалистов команды;
    • Старт процесса автоматизированного тестирования с нуля;
  • (Опционально) Договариваемся о проведении стартового рассказа о нас и Tladianta Framework с сессией вопросов/ответов со всеми заинтересованными сотрудниками команды.

Итог: Готов список дальнейших шагов, понятный и нам, и команде.


3. Технический анализ системы


image


  1. Анализ инструментов
    На данный момент Tladianta Framework использует в своих модулях возможности следующих инструментов и библиотек (с привязкой к языку Java):


    • Selenium WebDriver;
    • Appium;
    • MF LeanFT (в части desktop-тестирования);
    • RestAssured.

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


    • Нельзя считать значение из текстового поля внутри приложения;
    • Нельзя выполнить клик по необходимому элементу;
    • Приложение вообще не запускается и/или выдает ошибку;
      и т.д.

    Для определения данных проблем и выработки стратегии по дальнейшей работе специалистами отдела АТ проводится исследование совместимости инструментов автоматизации и тестируемого приложения. Результатом данного исследования является заключение о возможности применения инструментов Tladianta. Возможные варианты:


    • Полная совместимость;
    • Возможно расширение функционала Tladianta;
    • Расширение функционала Tladianta не рационально предлагается альтернативное решение.
      Тут важно отметить, что нет цели отправить всех в один инструмент. Это бессмысленно и бесполезно. Критичны два момента чтобы инструмент максимально подходил для решения задачи и чтобы не дублировал уже существующие решения в банке. Об этом мы еще раз поговорим в статье про Chapters&Guild.

  2. Анализ системы и стендов тестирования
    Достаточно часто причинами итоговой нестабильности разработанных автоматизированных тестов являются не ошибки в разработке непосредственно самих тестов. Это могут быть моменты, незаслуженно забытые или не проанализированные до старта разработки тестов. Пара примеров (полный список и варианты решений в эту статью не влезут. Если будет интересно можем рассказать отдельно):


    • "Общий" тестовый контур для всех. Автоматизированный тест это скрипт, который на исчезновение нужного пользователя (которого кто-то вдруг изменил/удалил) отреагирует одинаково ошибкой. Можно усложнять скрипты проверками и вариативностью, увеличивая трудозатраты и сроки, но наиболее правильный вариант отдельный контур для автоматизированного тестирования. Можно уже на этом этапе предложить и зафиксировать методику дальнейшей работы, позволяющую автоматизированным тестам минимально зависеть от вмешательства "со стороны".
    • Возможность доработки системы под автоматизацию. В случае, если мы имеем дело с "коробкой", разработанной сторонней компанией внести изменения крайне сложно. Но вот если разработка ведется внутри банка, то возможно сделать некоторую работу, которая, с одной стороны, сильно облегчит автоматизацию и дальнейшую поддержку, с другой скорее всего, не будет являться большими трудозатратами для самих разработчиков.
      Речь в первую очередь о локаторах элементов. Локатором является некий путь в системе по которому можно найти данный элемент. Сравним два варианта (несколько гипертрофированных для наглядности):
      • Достаточно лаконичное значение
        @ElementTitle("Войти")@FindBy(xpath = "//button[@value='Войти']")public Button enterButton;
        
      • Xpath, который даже не поместился на 1 экран
        @ElementTitle("Ограничения по счету")@FindBy(xpath = "//hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.ScrollView/android.widget.LinearLayout/android.view.ViewGroup[4]")public MobileEditElement accountRestrictions;
        

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



Итоги: Определены используемые инструменты
Сформированы рекомендации по подготовке стенда к тестированию (или методики тестирования)
Сформированы рекомендации к возможной доработке самого тестируемого приложения


4. Подготовка тест-кейсов и оценок


image


'Что бы автоматизировать что-то нужное, надо сначала описать это нужное. А у нас тест-кейсов нет' (с)
Вольная интерпретация известной цитаты из хорошего мультика.

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


  1. Актуализация тестовой модели
    Тестовая модель это модель тестируемой системы, на основе которой разрабатываются сценарии. Модели строятся на основе требований или ожидаемого поведения системы.
    Зачем нужна модель:


    • оценивать полноту покрытия требований тест-кейсами;
    • контролировать изменения требований для своевременного обновления тест-кейсов;
    • приоритезировать тест-кейсы;
    • управлять объемом тестирования для каждого этапа тестирования;
    • определять связи между функциями системы;
    • рассчитывать регресс.

  2. Отбор тест-кейсов в автоматизацию
    Как правило, в первую очередь автоматизируются сценарии со следующим набором свойств:


    • Стабильный функционал (не изменяются, либо редко и незначительно);
    • Есть необходимость проверять часто;
    • Большое число ошибок на продуктивной среде;
    • При необходимости использовать тестовые данные понятно откуда их брать и/или как быстро сгенерировать
      На этом этапе также выбирается и детализируется небольшой набор кейсов, который реализуется нами (1-5 кейсов, в зависимости от объема). Это будут примеры и база для всех остальных.

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



Итог: Сформирован и определен общий объём работ, выбраны тест-кейсы для реализации силами отдела АТ, предоставлена HLE-оценка.


5. Подбор сотрудника в команду


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


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


Основные варианты:


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


  2. Подбор нового сотрудника


    • Совместно с командой составляем профиль поиска и определяем уровень желаемого специалиста
      Нельзя не отметить то, что благодаря Tladianta, можно сразу сформировать необходимый технический минимум. Все технологии и инструменты известны заранее.;
    • Специалист отдела АТ будет присутствовать на технической части собеседования с кандидатом, формируя по итогам общения развернутый итог;
    • После успешного найма, Отдел АТ может помочь с:
      • Обучение Tladianta и теории АТ;
      • Составление ИПР (индивидуальный план развития) и курирование развития сотрудника.

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


    • Совместно с командой формируется ТЗ на работы;
    • Определяются моменты, связанные с дальнейшей поддержкой (после выполнения работ подрядчиком);
    • На основе ТЗ подготавливается HLE-оценка, представляющая собой экспертную оценку в m/d и итоговом бюджете на данный объем работ;
    • Запрос предложений у подрядчиков, с которыми у банка заключены договоры. Выбор, заключение задания на работы;
    • Помощь при приёмке. Итоговые результаты передаются полностью в команду.


6. Внедрение Tladianta Framework (или иного выбранного инструмента)


image
Вот уже 6-й шаг и только сейчас мы доходим непосредственно до кода и написания автотестов. Что же тут происходит:


  1. Доработка под уникальные особенности проекта и разработка базового набора тестов (15-20 m/d) или разработка фреймворка на выбранном инструменте
    На данном этапе специалистом ЦК АТ производятся следующие работы:
    • Создание проекта на базе Tladianta или иного инструмента;
    • Реализация вспомогательных модулей под целевую систему (в рамках необходимого и достаточного объема, ограниченного выбранным начальным набором тестов);
    • Реализация и отладка автоматизированных тестов по отобранным ранее сценариям;
    • Консультации со специалистами команды, связанные с бизнес-логикой тестируемой системы
      На данном этапе крайне важен оперативный отклик от команды, а также стабильность тестируемой системы и ее функционала. Планируемые трудозатраты специалиста ЦК АТ не более 20 m/d
  2. Встраивание тестов в процесс непрерывной интеграции (< 2-3 m/d)
    Один из основных плюсов проведения автоматизированного тестирования возможность автоматически запустить произвольный набор тестов (после изменения кода проекта разработчиком/по времени) хоть глубокой ночью и на любом числе виртуальных машин. Таким образом, уже с утра может быть получен отчет о статусе проведенного тестирования системы. Проведя анализ данного отчета, специалист по автоматизации (или функциональный тестировщик/аналитик) выносят возможные дефекты в JIRA

Итог: Подготовлен базовый набор автоматизированных тестов, которые выполняются посредством запуска задания в Jenkins. Набор готов к передаче


7. Обучение и передача


image
Формально финальный для нас, но стартовый самостоятельный шаг для команды.


  1. Передача проекта. В рамках данной активности в команду передается следующий набор данных:


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

  2. Обучение. Проводится специалистом Отдела АТ. Основные темы:


    • Setup&Configuration;
    • Create&Run;
    • Debug&Modification.

    Онлайн-обучение, которое покрывает только функционал Tladianta (или иного фреймворка). Полноценное покрытие таких тем как теория автоматизированного тестирования, инструменты автоматизированного тестирования (Selenium, Maven, Git, e.t.c), Java, в рамках данной активности не затрагиваются. Это возможно организовать отдельно.
    Также, кроме онлайн-версии, доступны оффлайн-видео, размещенные в Confluence.


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


    • Консультации и поддержка, которая касается возможностей Tladianta Framework;
    • Возможность влиять на развитие Tladianta Framework и его возможности посредством предложений о новых доработках;
    • Со стороны отдела АТ предоставление новых возможностей и гарантия совместимости (новые версии модулей Tladianta Framework);
    • Участие в Community для обмена навыками и наработками (встречи, мастер-классы могут проводиться как силами отдела АТ, так и силами заинтересованных команд).


Итог: Команда развивает направление автоматизированного тестирования у себя, при необходимости получает поддержку со стороны Отдела АТ. Вовлечена в общебанковское Community и обменивается знаниями с остальными командами


Вместо послесловия


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


  • Информация про наш фреймворк Tladianta;
  • Правила и рекомендации по подготовке тест-кейсов к автоматизации;
  • Метрики автоматизированного тестирования, или Как понять, что вы движетесь в правильном направлении;
  • Как проводить анализ совместимости инструментов и тестируемого приложения (и ничего при этом не забыть);
  • И, конечно же, одно из самых важных как в сложной ИТ-компании и при условии множества команд не создать зоопарк подходов и инструментов по АТ. Тут мы поговорим про Chapters&Guild.
Подробнее..

Tladianta инструмент тестирования или нечто большее

10.11.2020 18:17:06 | Автор: admin


Всем привет! Я Максим Кузнецов, и я продолжаю цикл статей рассказом об инструменте автоматизированного тестирования в Росбанке.


В прошлый раз вы читали:


  1. Fast-Unit или декларативный подход к юнит-тестам
  2. Tladianta. Сервис по автоматизированному тестированию в Росбанке

Я сегодня расскажу о самом инструменте фреймворке Tladianta.


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


Tladianta это первый базовый инструмент сервиса по автоматизированному тестированию, который наша команда предоставляет на весь банк.


Какие задачи он должен решать?


1. Легкий старт и удобство настройки

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


2. Легкая поддержка и возможность обновления для всех команд

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


Легкость поддержки сотрудниками сервиса АТ должна быть на уровне я не сильно разбираюсь в специфике проекта вашей команды, но в том, как работает фреймворк тестирования Tladianta, я вам помогу на 100%.


3. Охват основных платформ разработки

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


  • Web (HTML, CSS, JavaScript),
  • Desktop (Delphi, C++ и прочие),
  • Mobile (Android, iOS),
  • Back-end(REST-services, MQs очереди).

Фреймворк должен позволять писать тестовые сценарии для любой из них, оставаясь при этом в процессе Tladianta


4. Простота наращивания функционала фреймворка

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


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


5. Возможность настройки под команду или под систему.

Вот мы пришли в команду с чемоданом счастья, прошли Get started и начали писать тесты сразу, используя функционал из коробки.


Это в идеале.


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


Все это должно работать и при этом оставлять проект с использованием нашего фреймворка на поддержке командой сервиса АТ.


6. BDD стиль в написании сценариев

Что в BDD клёво, так это человеко-читаемый и одновременно авто-исполняемый текст сценария. Важно, чтобы все члены команды могли прочитать сценарий и понять, какую часть функционала протестировали.


BDD каким он задумывался: аналитик пишет сценарий, разработчик его воплощает, а автоматизатор делает его авто-исполняемым.


В банке же реальность это различные гибридные варианты. Например:


  • ПО куплено из коробки или разработано вендором, а команде нужно контролировать основные сквозные сценарии;
  • команда разработки ПО в банке и команда тестирования это две разные команды. Ситуация немного похожа на первую, только разработка внутри банка. Так, команда тестирования создает свои e2e тесты, чтобы контролировать основные сценарии и свои доработки;
  • Legacy ПО, которое взяли на поддержку и стали покрывать тестами.

То есть это уже Behavior Driven Testing когда разработка уже давно завершена. А вот прелесть человеко-читаемого описания поведения сложно переоценить и этот подход нужно учесть наравне с классическим BDD.


Значит, фреймворк должен говорить на языке Gherkin.


7. Единая библиотека шагов сценария

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


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


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


8. Возможность делиться шагами с другими командами

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


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


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


9. Гибкий механизм конфигурирования проекта с тестами

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


10. Одновременное использование нескольких платформенных модулей

Нужно охватить еще такой случай. Допустим, команда поддерживает и тестирует некий портал и в сценариях зачем-то нужно сходить в back-end, например, через REST проверить результат или через него же подготовить данные (вдруг с разработкой все по науке сделано :-) ).


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


11. Удобство в расследовании падений и сбора результатов

Это требование про сервис отчетности. Должно быть удобно:


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

12. Удобство e2e тестирования

Об этом было понемногу в пунктах выше, но некоторые моменты стоит выделить отдельно. BDD ориентированность фреймворка подразумевает сценарные тесты, а они бывают в основном функциональные и end-to-end.


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


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


13. Увеличение вовлеченности автоматизаторов на местах в развитие инструмента

Фреймворк должен задавать общие правила и давать равные возможности для автотестирования многим (в идеале всем) командам. В этом случае он просто обязан быть удобным.
А значит, следующий шаг развития переход к opensource внутри банка.


14. Единая отчетность, сбор метрик и легкое формирование Dashboards

В процессе трансформации в банке образовалось много Agile-команд, которые, тем не менее, все еще работают на один результат все ПО банка должно работать слаженно, в идеале без ошибок и приносить удовлетворение клиентам.


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


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


15. Использование в Agile командах

BDD задумывался его авторами для облегчения взаимодействия в команде трех ролей:


  • аналитик/owner знает, что должно получиться;
  • разработчик знает, как сделать то, что хочет owner;
  • тестировщик знает, как проверить то, что сделает разработчик, чтобы оно работало как хочет owner.

В команде они в тесном общении создают качественный продукт.


Фреймворк должен быть удобен как инструмент в этом взаимодействии: он должен говорить на языке ownerа, быть понятным разработчику и удобным для тестировщика.


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


Архитектура


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


Плагины предоставляют функционал и реализацию шагов для конкретного стека технологий (платформы), на которых написано тестируемое приложение.


Плагинов в семействе компонентов фреймворка пока 4:


  • HTML-plugin для тестирования веб-приложений, сайтов, порталов и пр. на различных браузерах;
  • Desktop-plugin для тестирования desktop-приложений, написанных на Swing, AWT, .Net и пр. языках высокого уровня, Windows-приложения, а также терминальные. Например, Bank Information System;
  • Mobile-plugin для тестирования мобильных приложений на iOS/Android;
  • Rest-plugin для тестирования REST API приложений любых типов.

Ассортимент и функционал плагинов может (и будет) расширяться. Плагин должен отвечать небольшим требованиям, чтобы иметь возможность работать под управлением "common".


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


Какие задачи решает:


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

Конфигурирование


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



Кроме того, часто нужно задать значения свойств любого уровня специально для среды запуска: DEV, TEST, CERT, а также опционально добавлять к набору свойств конфигурации группу свойств под конкретный тест или группу тестов (настройки подключения к базе данных, стороннему сервису и прочие).


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


По умолчанию конфигурация собирается следующим образом:



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


Какие задачи решает:


  • легкий старт и удобство настройки;
  • Возможность настройки под команду или под систему;
  • гибкий механизм конфигурирования проекта с тестами;

Контекст исполнения сценария


Контекст здесь означает закешированные Java-сущности, которые устанавливаются при старте каждого сценария и обеспечивают корректное исполнение его шагов.
Контекст состоит из


В Tladianta реализован механизм регистрации действий для установки контекста проекта. Это такой список отложенных действий, который есть у плагина и у проекта.


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


Такой подход позволил заложить удобство при переходе на контекст другого проекта и использование его шагов прямо в том же самом сценарии (см. далее).


Какие задачи решает:


  • возможность делиться шагами с другими командами;
  • удобство e2e тестирования.

Гостевой модуль использование шагов и контекста других проектов.


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


В своих проектах команды реализуют тестовое взаимодействие со своим тестируемым приложением клики, заполнение полей, проверки и т.д.


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


Я прекрасно понимаю гнев и негодование BDD-евангелистов, но что есть, то есть.


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


Для реализации такой возможности Tladianta имеет спец шаги переключения контекста.

Вот тут и пригодились те самые отложенные действия.


Сценарий при этом может выглядеть так:



Каждый проект на базе Tladianta должен иметь свойство конфигурации app.name с понятным человеку именем. Это имя идентифицирует контекст проекта и используется для переключений/установки контекста в сценарии.


В момент переключения контекста сценария будут выполнены все [отложенные] действия установки контекста, зарегистрированные для конкретного проекта.


Чтобы любой проект на базе Tladianta можно было использовать как гостевой в других проектах, он должен отвечать ряду требований:


  1. проект тестирования должен быть построен на базе Tladianta-framework;
  2. проект тестирования должен собираться по релизам и публиковаться в банковский репозиторий nexus;
  3. проект подключается как гостевой через зависимость в POM-файле принимающего проекта. Последний стабильный релиз;
  4. проект тестирования в процессе сборки релиза должен включать ресурсы с файлами свойств конфигурации.

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


Какие проблемы решает:


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

Библиотека шагов.


Tladianta реализует принцип "Создай шаг один раз и переопределяй его метод, где нужно".
Шаги, составляющие библиотеку, разбиты на несколько уровней:


  • общие шаги для всех проектов на базе любых плагинов;
  • шаги плагина;
  • шаги проекта.

Вместо классической реализации шагов cucumber Tladianta разделяет определение шага (step definition) и реализацию шага (step implementation) на две разные сущности.
Это позволило отделить формулировки шага и собрать их в библиотеку, оставив плагинам и проектам работу над реализацией конкретного поведения шага.


Таким образом, одна формулировка шага может иметь разную реализацию в разных плагинах и проектах.


Создавая сценарий, больше не нужно беспокоиться о том, что шаг "занят" в другом плагине и нужно дублировать его у себя, меняя формулировку или вставляя разные костыли в виде символов точек, лишних пробелов и так далее, чтобы избежать ошибки "Multiple step definition found".


Вместо этого нужно просто переопределить метод этого шага в своем проекте или даже на конкретной странице.


Внешнее поведение шага, интуитивно ожидаемое от его формулировки, останется тем же, скрывая под капотом нюансы его реализации в каждом конкретном случае.


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


Роль сервиса АТ также позволяет нам вылавливать из оставшихся 20% шагов, которые команды делают себе сами, те шаги, которые объективно нужны многим, и мы добавляем их в библиотеку фреймворка. Автоматизаторы в командах, таким образом, принимают участие в развитии инструмента.


Какие задачи решает:


  • возможность настройки под команду или под систему в части реализации шагов;
  • BDD стиль в написании сценариев;
  • единая библиотека шагов сценария;
  • увеличение вовлеченности автоматизаторов на местах в развитие инструмента.

Тестовые данные и шаблоны генерации значений параметров шагов


Cucumber дает возможность часть текста шага использовать как параметр. Это очень удобно.
Tladianta расширяет эту возможность динамической параметризацией шагов.


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


Tladianta перед выполнением сценария все шаблоны заменит на конкретные значения из тестовых данных и в отчетах о прогоне вы увидите уже их.


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


  • Json
  • Excel
  • Properties
  • Mongo DB

Генераторы значений


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


Tladianta представляет очень удобный механизм генерации текстовых значений "на лету" это генераторы значений.


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


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


Какие проблемы решает:


  • возможность настройки под команду или под систему;
  • BDD стиль в написании сценариев.

Древовидная структура


Продолжаем тему длинных сквозных сценариев.
Тут есть дилемма атомарные шаги или читаемый сценарий.


Правильно это и то, и другое.


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


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


Например, у нас есть сценарии из 700+ шагов. Это большие такие сквозные сценарии. В функциональных тестах отдельные части протестированы. А в этом e2e сценарии ничего не выкинуть. Только читать и поддерживать его невозможно. Что делать?


Мы сделали сценарий древовидным.


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


Например,



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



Вы заметили, что это уже не cucumber шаги?


Это то, что понимает, скажем, аналитик, который знает назубок этот сквозной сценарий. Если сценарий упадет, он довольно быстро сможет понять, в каком месте сломалось. Ему не нужно быть для этого автоматизатором. Ему достаточно уметь открыть отчет Allure и знать русский язык.


Древовидное отображение сценария мы сделали в среде разработки и в отчете Allure.


Узлы дерева можно сворачивать и читать сценарий по верхам.


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


Какие задачи решает:


  • BDD стиль в написании сценариев;
  • удобство в расследовании падений и сбора результатов;
  • удобство e2e тестирования.
  • использование в Agile-командах

Page Object


Мы выбрали шаблон PageObject для архитектуры автотеста как основной, но не единственный. Просто он объектно-ориентированный, это так по javaвски.


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


Вкратце PageObject предполагает описание формы или экрана приложения как отдельного java-класса, а поля класса это части интерфейса формы: поля ввода, кнопки, флажки, таблицы и прочее.


В сценарии специальным шагом

объект страницы устанавливается как текущий и дальнейшие шаги работают в контексте этой страницы.


Блоки.


Страницы бывают сложные: много вкладок, разных сгруппированных полей и часто у этих полей одинаковые относительные пути (xPath), что наводит на мысль о DRY, переиспользовании, ООП в конце концов.


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


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


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


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



Блоки элементов могут быть вложены друг в друга



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



Такая навигация очень помогает ориентироваться в сценарии и приложении.


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


Довольно удобно.


Какие задачи решает:


  • BDD стиль в написании сценариев.
  • удобство в расследовании падений и сбора результатов.
  • использование в Agile командах всем просто понять сценарий

Использование нескольких плагинов в одном проекте


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


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


Самая распространенная ситуация это когда нужно результат действий через UI проверить через REST запросы к бэкенду приложения.


Какие задачи решает:


  • одновременное использование нескольких платформенных модулей;

Запись видео.


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


Перед запуском теста фреймворк запускает все зарегистрированные видео-рекордеры и по окончании сценария останавливает их.


Настройки поведения видео-рекордера (вкл/выкл, сохранять видео всегда или только при падении и пр.) можно использовать общие или добавить свои только для проекта.


Какие задачи решает:


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

Allure-report


По-умолчанию результаты прогона тестов логируются в Allure-отчет. Логирование поддерживает древовидную структуру сценария, если она используется. В отчет попадают также логи, сделанные с помощью Sl4j.


Allure позволяет группировать сценарии по Epic/Feature/Story/Case. Это полезно, если у вас есть (должны быть) тестовая модель и матрица зависимости. И когда просматриваешь отчет, который сгруппирован так, как у вас модель тестовая составлена, то становится очень удобно, т.к. по упавшему тесту в отчете сразу видно, какой связанный функционал пострадал и потенциально стал нерабочим.


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


Все результаты собираются в одном месте по проектам/командам и вместе дают ту самую целую картину здоровья ИТ-ландшафта. Причем, собираются также результаты тестов, которые написаны не на Tladianta.


Это уже не фреймворк Tladianta (он только генерирует данные), это уже процесс Tladianta.


Какие задачи решает:


  • BDD стиль в написании сценариев.
  • удобство в расследовании падений.
  • единая отчетность, сбор метрик и легкое формирование Dashboards.
  • Использование в Agile командах

Передача данных между шагами и сценариями.


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


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


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


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


Кроме того, данный контекст можно закрепить за конкретным сценарием и сохранить его в базе данных. Опционально. Для этого есть отдельные методы, их можно использовать в Before/After-хуках в проекте.


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


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


Какие задачи решает:


  • удобство e2e тестирования;

Шаблонные проекты.


Это часть семейства инструментов Tladianta.


Мы сделали заготовки, шаблоны проектов, которые настроены на работу с каким-то одним плагином. Сделали в них структуру со всеми ключевыми пакетами и классами. Сделали настройку для фичи гостевой проект, для выгрузки отчета Allure.


Просто делай клон, пиши имя проекта и начинай писать тесты.


В проектах можно кастомизировать почти все, что может фреймворк:


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

Какие задачи решает:


  • легкий старт и удобство настройки;
  • охват основных платформ разработки;
  • возможность настройки под команду или под систему;

Интеграция с внешними сервисами и инструментами.


Фреймворк позволяет подключать к нему различные интеграторы/выгружаторы результатов выполнения теста.


Мы сделали репортер в ALM и репортер в Jira.


Jira-reporter, например, создает задачу на реализацию новых шагов на автоматизатора в команде, а также задачу на расследование падения сборки со всеми ссылками и логами.


Tladianta-editor


Это плагин для среды разработки IntelliJ IDEA.


Его основное назначение повысить скорость и комфорт в разработке сценария.


Можно создать рабочий сценарий не выходя из файла .feature, при условии что использован шаблонный проект, конечно.
Он позволяет:


  • выбрать шаг из доступной библиотеки шагов
  • перейти из шага сразу в его step definition (это должно быть знакомо)
  • позволяет создать заглушку step definition для нового шага (это тоже)
  • выбрать страницу из списка в шаге установки текущей страницы
  • а также создать новую страницу с элементами и блоками, не уходя из редактирования сценария
  • провалиться в класс страницы, если уж так сильно нужно.
  • набивать стрелочный путь до элемента в блоке, который в блоке и т.д.
  • выбирать шаги гостевого проекта после переключения на его контекст
  • выбирать страницы гостевого проекта после переключения на его контекст
  • редактировать сценарий как дерево, добавляя и удаляя группировки шагов. Уровень вложенности любой
  • и прочее.

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


Реализацию нового шага или специфичную реализацию существующего шага придется все-таки писать самостоятельно. Но для этого есть автоматизатор :-)


Заключение


Как видите, мы нарушили много канонических положений BDD. При этом мы сделали cucumber пригодным для использования в наших банковских реалиях. Получился такой cucumber по-росбанковски. Поэтому и Tladianta.



Не все идеи мы придумали сами. Многие из них мы почерпнули из трудов таких замечательных ребят как Константин Мальцев, Виктор Сидоченко, Алексей Лустин, Артем Ерошенко и других авторов open-source проектов.


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

Подробнее..

Recovery mode Автоматизация поставок Siebel На пути от хаоса к порядку

06.05.2021 14:05:14 | Автор: admin

Введение


Разработка под Siebel имеет свои отличительные черты. В её основе лежит конфигурирование объектов, и автоматизация бизнес процессов c их использованием, как из кубиков, использование справочников особых значений. Возможность написания скриптов присутствует, но не занимает доминирующее положение. Все изменения производятся через IDE Siebel Tools, либо в интерфейсе приложения. Особенностей много, но ничто человеческое Siebel не чуждо, и в том числе проблема переноса изменений с dev контура на другие среды. В этой статье мы хотели бы рассказать о том, как работает наш ci/cd конвейер.


Авторы материала Horkin и Mryavka


RosbankSiebelTeam


Проблематика


Стоит начать с того, что изначально процесс переноса изменений состоял только из инструментов Siebel. После того, как разработчик внес изменение в объект, он должен вручную его экспортировать и положить в папку со своей задачей. При этом нельзя экспортировать только ту часть, которая была изменена, необходимо выгружать объект целиком. А решение задачи, вроде формирования PIN-кода для карты, или списания комиссии за справку, состоит из изменений большого количества таких объектов. При этом IDE не отслеживало список изменений и его приходилось вести вручную. Кстати, такие объекты хранятся в репозитории Siebel, и потому называются repo объектами. К этому добавляется то, что некоторые объекты имеют свои характерные особенности, например, Workflow-процессы (WF) нужно активировать, и чтобы изменения применились и работали, нужно написать инструкцию для администратора, и указать, какой именно процесс нужно активировать. Также нужно выгрузить справочники, которые содержат определенные значения бизнес логики, например, типы банковских счетов и их коды. Если справочник был изменен, например, появился новый тип счета, необходимо его также добавить в поставку. (Такие справочники экспортируются с помощью инструмента Siebel Application Deployment Manager и называются ADM объектами).


Скорее всего, если читатель не знаком с Siebel, то уже загружен новой инфой, но стоит сказать, что и это еще не все. Также есть элементы кастомизации интерфейса, скрипты БД и некоторые конфигурации, которые требует ручных действий. Все это также необходимо выгружать отдельно и указывать в инструкции.


В итоге, когда собирается релиз, который включает в себя большое количество задач от разных команд, то возникают проблемы: долгое формирование поставок, длительная установка, большое количество ошибок человеческого фактора. Администраторы загружены, а разработчики нервничают. В общем, такой подход вызывал заслуженное недовольство, и требовал преобразований. Так и началась работа над ci/cd конвейером.


Инструменты


Для корректной работы конвейера и коммуникации с участниками процесса были выбраны следующие инструменты:


JIRA используется для ведения задач для поставки; Частично используется для коммуникации: разработчики уведомляются о проблемах в сборке, заказчики уведомляются о завершении установки (посредствам комментариев и изменении статусов задач). Так же Jira используется для ведения истории поставок в задачах отмечается, в рамках каких поставок была произведена установка на наши стенды.
RocketSiebel (RS) система контроля версий Siebel. В ней происходит версионирование стендов, разработчики размечают изменения в рамках задач, а конвейер собирает поставку на требуемую среду.
Jenkins оркестратор конвейера. Занимается упорядочиванием действий конвейера, сигнализирует о наличиях ошибок.
Ansible руки нашего конвейера. При помощи скриптов, написанных на Python и PowerShell, выполняет сборку и установку поставки на стенды Siebel.
Bitbucket на данный момент исполняет только роль хранилища исходного кода конвейера. В будущем планируется использоваться для передачи ADM, неверсионируемых в RocketSiebel, и файлов Web-серверов.
нативные инструменты Siebel :)


Описание работы


На текущий момент в Росбанке используется Siebel CRM Innovation Pack 20.5. При разработке функционала (в рамках требований задач Jira) разработчики вносят изменения на dev-стенде. Все эти изменения подтягивает в себя RocketSiebel и позволяет использовать эти изменения для сборки поставки и их передачи по средам. По завершении задачи разработчик размечает свои изменения в Task и называет ключом задачи Jira (чтобы в дальнейшем он мог быть использован при работе конвейера).



Рисунок 1. Тикет в JIRA


По расписанию (в 12:00 и 17:00 для ТЕСТ и в 14:00 для СЕРТ) конвейер начинает работу. Первым шагом он скачивает актуальные версии скриптов установки из Bitbucket. Затем конвейер выгружает по фильтрам Jira задачи для поставки (для ТЕСТ и СЕРТ отдельный фильтр), формирует патч для требуемого стенда в RockerSiebel. Если по какой-то причине по задаче нет Task'а конвейер её просто пропускает.



Рисунок 2. Таск в RocketSiebel


После сборки конвейер производит проверку патча на наличие конфликтов. Если таковые имеются идёт оповещение разработчиков через комментарий в Jira и сообщение в Telegram. Для решения конфликтов разработчикам даётся время на их исправление (по умолчанию 1 час), если конфликты решены не будут задача исключается из поставки.
При отсутствии конфликтов конвейер продолжает свою работу.



Рисунок 3. Оповещение о конфликте


По завершении работы с конфликтами конвейер делает Merge патча и формирует итоговую поставку для стенда Siebel CRM. После чего начинается процесс установки патча.
Следующим шагом конвейер скачивает и распаковывает архив с поставкой на Windows-сервере, откуда будет производиться установка на стенд. Обязательное условие наличие на этом сервере подключения к БД Siebel CRM и Siebel Tools.



Рисунок 4. Пайплайн в Jenkins


Установка на требуемый стенд начинается с создания Workspace, в который будут импортироваться объекты. Имя воркспейса соответствует названию поставки в RocketSiebel (для удобства разбора проблем с поставкой).


По нашему опыту работы с IP 20.5 есть определённые проблемы с импортом Workflow процессов, в связи с этим после создания Workspace конвейер переименует WF на стенде по списку объектов поставки, во избежание проблем после установки. SQL скрипт для переименования формируется при помощи java-метода, который вызывается Ansibleом в БД Siebel.


Затем конвейер блокирует все проекты и происходит импорт объектов из поставки. Далее формируется и применяется скрипт изменения объектов БД (Apply DDL). После происходит инкрементальная компиляция таблиц в Runtime-репозиторий. Список таблиц для компиляции формируется на основании объектов в поставке.


Следующим шагом происходит Checkpoint и Deliver Workspace в Main (применяются изменения к Runtime-репозиторию). При помощи Soap-сервиса отправляется запрос в Siebel с названиями Workflow процессов для их активации.


Последним шагом в установке является заливка справочников ADM. Импорт производится при помощи вызова утилиты RocketSiebel.


По завершении установки конвейер делает оповещения в задачах JIRA из поставки о завершении установки:


  1. Указывается имя поставки, в рамках которой производилась установка;
  2. Публикуется комментарий о том, что поставка завершена;
  3. Меняется статус, сигнализирующий о том, что можно начинать тестирование.
    Дополнительно идёт оповещение разработчиков в Telegram-канале о завершении установки (и наличии возможных ошибок). Дополнительно, информация об установке и лог заливки объектов дублируются в почте.


Рисунок 5. Оповещение об успешной установке


Ближайшие планы


Хотя все справочники версионируются в RocketSiebel, есть печатные формы (ПФ), которые тоже относятся к АДМ объектам, но стоят особняком. На данный момент RS их не версионирует, а в задачах они встречаются часто. Чтобы встроить деплой ПФ в пайплайн, на стороне Siebel сделали отдельный веб-сервис, а сами формы планируем передавать через BitBucket.
Кроме этого, на данной момент конвейер не содержит шаг с рестартом сервера, а не смотря на введения нового Innovation Pack, рестарт часто требуется, так как некоторые серверные компоненты, например, EAIObjMgr не подтягивают изменения из рантайм репозитория без рестарта.


Заключение


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


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

О том, как искусственный интеллект помогает сэкономить время, или как мы встраивали ИИ в бизнес-процесс открытия счета

28.08.2020 10:04:17 | Автор: admin
Всем привет!

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

image

Итак, начнем. В Росбанке существует бизнес-процесс открытия счета для заемщика в лице банка партнера. Существующий процесс, следуя всем регуляторным требованиям и требованиям группы Societe Generale, до автоматизации занимал до 20 минут операционного времени на каждого клиента. Процесс включает в себя получение сканов документов back-офисом, проверку корректности заполнения каждого документа и разнесения полей документа по информационным системам банка, ряд других проверок и только в самом конце открытие счета. Это именно тот процесс, который стоит за кнопкой Открыть счет.

Основные поля документа фамилия, имя, отчество, дата рождения клиента и др. содержатся практически во всех типах получаемых документов и дублируются при вводе в разные системы Банка. Наиболее сложный документ вопросник KYC (от Know Your Customer знай своего клиента) представляет собой печатную форму формата А4, заполняемую шрифтом 8 кегля и содержащую порядка 170 текстовых полей и чек-боксов, а также табличные представления.

Что нам предстояло сделать?


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

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

Для решения задач (1) и (2) было решено воспользоваться уже внедренным в банке решением по распознаванию образов и текста на базе GreenOCR (рабочее название распознавалка). Форматы используемых в бизнес-процессе документов не являются стандартными, поэтому перед командой стояла задача разработать требования к распознавалке и подготовить примеры для обучения нейронной сети (сэмплы).
Для решения задач (2) и (3) была необходима доработка систем и межсистемных интеграция.

Наша команда под руководством Юлии Алексашиной


  • Александр Башков внутренняя разработка систем (.Net)
  • Валентина Сайфуллина бизнес анализ, тестирование
  • Григорий Проскурин интеграции между системами (.Net)
  • Екатерина Пантелеева бизнес анализ, тестирование
  • Сергей Фролов Project Management, анализ качества моделей
  • Участники от внешнего вендора (Smart Engines совместно с Философия.ит)

Обучение распознавалки


Комплект клиентских документов, используемых в бизнес-процессе, включал в себя:

  • Паспорт;
  • Согласие печатная форма формата А4, 1 л;
  • Доверенность печатная форма формата А4, 2 л;
  • Вопросник KYC печатная форма формата А4, 1 л;

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

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

  • Каждый документ может содержать текстовые поля и статический текст, меняющие свое положение в пределах печатной формы при заполнении шаблона документа реальными данными. Наиболее заметно это сказывается при распознавании многостраничного документа, когда поле может переползать с одной страницы на другую;
  • Шрифт 8-го кегля очень чувствителен к разрешению скана документа. При низких разрешениях такой шрифт не может быть распознан ни системой распознавания, ни визуально;
  • В процессе сканирования используются документы самого разного качества (зачастую невысокого) и сканеры с самыми разными техническими характеристиками;
  • Документ одного и того же типа может иметь разные шаблоны;
  • Исходная ориентация документа, использовавшаяся при сканировании, заранее неизвестна;
  • Имена файлов получаемых сканов документов могут быть произвольными и при этом могут повторяться;

Безопасность персональных данных


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

Требования > Вендор > Модель > Тестирование модели -> Запуск процесса

В случае не успешных тестов модель возвращается вендору на повторное обучение.

Ежедневно мы получаем огромное количество сканов документов, и подготовить выборку для обучения модели не должно было стать проблемой. Вся обработка персональных данных должна соответствовать требованиям Федерального закона О персональных данных N152-ФЗ. Согласия клиентов на обработку персональных данных клиентов есть только внутри Росбанка. Передать вендору, для обучения модели, документы клиентов мы не можем.

Рассматривалось три пути решения проблемы:

  1. Распространить и обеспечить себя типовыми формами согласий всех клиентов на передачу персональных данных на случаи передачи данных вендору, что означало бы пройти долгий путь всех необходимых согласований в крупной компании, что, в свою очередь, ставило бы под угрозу соблюдение сроков проекта;
  2. Маскировать готовые данные. Этот путь означал бы высокий риск получения неточной модели и высокие трудозатраты на подготовку выборки документов, так как каждый документ пришлось бы обрабатывать вручную удалять (маскировать) персональные данные, а также проводить заключительную проверку всего массива подготовленных документов на предмет правильности и полноты удаления персональных данных;
  3. Синтезировать (имитировать) документы из несуществующих данных. Было ясно, что этот путь потребует привлечения подразделений банка для синтеза, печати и сканирования документов и, следовательно, значительного объема ручной работы, но при этом обеспечит максимальную гибкость и оперативность внесения изменений;

Обучение модели


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

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

Обучение нейронной сети, разметка областей и настройка форм проходили на стороне вендора.

image

По причине ограниченных сроков, обучение модели разбили на 2 этапа.

На первом этапе было проведено обучение модели распознаванию типов документов и грубому распознаванию содержимого самих документов:

Требования > Вендор > Подготовка тестовых данных-> Сбор данных-> Обучение модели по распознаванию форм > Тестирование форм -> Настройка модели

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

Подготовка тестовых данных в разных разрешениях -> Сбор и передача данных вендору -> Обучение модели -> Тестирование модели -> Калибровка модели -> Внедрение модели > Проверка результатов в бою -> Выявление проблемных кейсов -> Имитация проблемных кейсов и передача вендору -> Повторение шагов с тестирования

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

Тестирование


Так как контур обучения модели находился на стороне вендора и не был связан с системами банка, после каждого цикла обучения модель передавалась вендором в банк, где проводилась её проверка на тестовой среде. В случае успешной проверки модель переносилась на сертификационную среду, где проводилось ее регрессионное тестирование, и далее на промышленную среду, для выявления особых кейсов, не учтенных при обучении модели.
В периметре банка на модель подавались данные, результаты записывались в базу данных. Анализ качества данных проводился с помощью всемогущего Excel с использованием сводных таблиц, логики с формулами и их комбинаций vlookup, hlookup, index, len, match и посимвольного сравнения строк через функцию if.

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

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

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

Интеграция и внутренняя разработка


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

Реализованный сценарий состоит из следующих этапов:

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

Итог


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

FlexCube внедрение революционной бэк-офисной платформы в Росбанке

22.06.2020 20:08:04 | Автор: admin
Друзья, привет!

Я Никита Климов, Platform Owner Oracle FlexCube (FCUBS) для процессинга операций корпоративных депозитов, межбанковских кредитов, валютных операций и деривативов в Росбанке. Сегодня я расскажу, как мы внедряли платформу FCUBS и в чем уникальность этого проекта для российского рынка. Все подробности под катом.

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

Архитектура

Архитектура системы это классическая трехзвенка. В нашем случае backend это Oracle 12c (правда, он на текущий момент уже снят с поддержки, и мы переходим на 19сно это уже совсем другая история) и frontend IBM WebSphere. Искушенный читатель сразу задаст вопрос а почему не использовать нативный для Oracle Weblogic? И, безусловно, будет прав, потому что это первое, что рекомендовал нам сам Oracle. Но, так вышло, что для банка стандартом является именно сервер приложений IBM WebSphere, к тому же у нас ULA на этот продукт, и было принято решение адаптировать слой приложения под особенности WebSphere. Не сказать, что это было очень трудной задачей, однако ряд особенностей организации внутренних очередей все же имелся, и нашей команде пришлось провести немало часов на трехсторонних конф-коллах с поддержками Oracle и IBM.
image

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

Функциональность

Как я уже отметил ранее, система из коробки была совершенно не готова к российским реалиям, начиная с отсутствия плана счетов и заканчивая налоговым учетом. По сути это было просто ядро с набором событийных моделей, из которого надо строить космический корабль. Следовательно, вооружившись функциональными требованиями от бизнеса, мы приступили к разработке своего custom слоя на основе ядра системы. Мы разработали свой Accounting engine для генерации двадцатизначных счетов и приступили к реализации STP процессов. Исключить ручное вмешательство пользователей оказалось нетривиальной задачей, и не решалось лишь с помощью триггеров на уровне СУБД. Пришлось строить событийную логику на JOB и вводить расписание заданий. Этого тоже оказалось недостаточно, и мы вынуждены были использовать Quartz, на основе которого мы и автоматизировали наш workflow. В результате у нас в полностью автоматическом процессе происходит следующее:

  • Контракт попадает к нам из фронтовой системы Kondor+, и в зависимости от его суммы он либо автоматически авторизовывается, либо уходит на авторизацию к бизнесу;
  • После успешной авторизации система анализирует клиента является ли он клиентом головного офиса, а значит его счета лежат в GL1, либо это клиент регионов, а значит его счета лежат в GL2. Есть еще случай, когда это совершенно новый клиент, и тогда мы должны запросить его в нашей CRMсистеме и на основании полученной информации инициировать ему открытие необходимых счетов в соответствующей GL;
  • В результате процессинга система в режиме онлайн запрашивает остатки по счетам и при наличии таковых генерирует и передает в соответствующую GL необходимые проводки, формирует и отправляет SWIFT сообщения и платежки в ЕРЦ;
  • Внутри дня в системе происходят стандартные операции погашения, начисления процентов, досрочное закрытие и т.д;
  • Различную информацию о движениях по счету, контрагентах и контрактах мы автоматически передаем в ФНС, AML, Nostro. Также не забыли и об Интернет-Клиент Банке, через который клиенты видят, что происходит с их счетами после открытий и погашений депозитов;
  • Подготавливаем различную информацию для обязательной и управленческой отчетности и отдаем ее в DWH тут стоить отметить, что мы как делаем классические view для забора информации, так и генерируем транзакционные логи для IBM CDC, который в режиме онлайн забирает и агрегирует эту информацию.


Интеграция
image
Тут я для наглядности приложу нашу архитектуру и скажу лишь, что в связи с выбором frontend IBM WebSphere, было принято решение отказаться от стандартного для FCUBS Gateway, который разворачивается как дополнительное приложение и работает по старинке с листнерами и очередями, и перейти на работу c MDB Activation Specification. В результате чего мы разработали дополнительные интеграционные приложения, опубликовали их на нашем сервере и подключили к банковской интеграционной шине для взаимодействия с другими системами.
Кроме этого, у нас так же используется интеграция по средствам Systematica Modullar на основе TIBCO Rendezvous, общающийся с нашим фронтом и являющейся входной точкой для всех контрактов и ETL средство IBM DataStage. При этом функциональность на DataStage используется для интеграций, не связанных с DWH. Для одной из GL cпециально разработана логика батчевой загрузки\выгрузки данных, с проверкой статусов и breakpoints для ожидания вычислений.
image
ИТОГИ

  1. Заменили морально и технически устаревшую систему
  2. На основе ядра FlexCube создали свою платформу с неограниченными возможностями по параметризации и вариациям учета
  3. Минимизировали участие пользователей в процессе обработки дня
  4. Оптимизировали время выполнения EOD 15 минут вместо 3 часов ранее.
  5. Создали внутри банка центр компетенций и можем поддерживать и развивать платформу независимо от поставщика
  6. Практически неограниченно можем изменять usability пользовательского интерфейса и создавать любые проверочные экраны консолидированной информации для удобства контроля
  7. Внедрили систему мониторинга контрольных точек для беспрерывного процесса обработки
  8. Создали платформу, на которой готовы реализовать любой банковский продукт

image
Подробнее..

Женское это дело В преддверии 8 Марта рассказываем о прекрасной половине IT-сообщества

05.03.2021 12:10:54 | Автор: admin


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

Жанна Старилова, главный IT-менеджер департамента информационных платформ и сервисов



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

Сегодня в ИТ моя команда занимается автоматизацией и оптимизацией бизнес-процессов банка по направлению электронного документооборота на платформе СЭД CompanyMedia, где происходит слияние процессов электронного взаимодействия и электронного документирования.

В 2019 году мы стали лауреатами конкурса Инновационные решения в управлении электронными документами. Также мы успешно стартовали в эксперименте, который организовал Минтруд России, по переводу кадрового документооборота в электронный формат.

В 2020 году наша команда совместно с АО Компания Интертраст одними из первых успешно провела обновление СЭД CompanyMedia на базе платформы IBM Lotus Domino на новую версию. Новая версия СЭД CompanyMedia представлена на основе документоориентированной платформы ActiveFrame5, созданной специалистами АО Компания Интертраст на основе Java, платформой для хранения данных может служить любая реляционная СУБД, пользовательский интерфейс реализован с помощью web-клиента. Отличительной особенностью новой версии является возможность применения как проприетарных компонентов (СУБД, ОС, офисные пакеты), так и компонентов на базе СПО, в том числе разработанных отечественными производителями программного обеспечения.

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

Анастасия Харитонова, старший менеджер управления развития транзакционного бизнеса



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

Особенно горжусь разработкой ДБО для малого бизнеса, потому что именно с него я начала свой путь в банке. В мои руки попал хаос и вместе с командой мы смогли систематизировать всё от и до, создав полноценную дизайн-систему PASCAL, на базе которой теперь строятся все интерфейсы, процесс разработки стал в разы быстрее, а результат намного качественнее. Кроме того, даже оценки в мобильных сторах значительно выросли. Теперь мы с другой командой приводим в порядок новое мобильное приложение для физлиц, делаем только первые шаги, но я уверена, что с такими заряженными ребятами нас точно ждёт успех.

У меня 2 высших образования юриспруденция (административное и финансовое право) и переводчик (английский), по специальности я поработала всего несколько месяцев, понимая что это совершенно не то, чему я хотела бы посвятить свою жизнь. Еще во время учёбы я была погружена в изучение цифрового дизайна, брала небольшие заказы, а моим первым IT-проектом был небольшой амбициозный стартап, где я с головой ушла в проектирование мобильных интерфейсов. С тех пор я не представляю другую сферу деятельности, это то чувство, когда делаешь то, что тебе нравится, и тебе за это, к тому же, платят :) В банк я пришла из другой сферы, но, тем не менее, мое образование в какой-то мере было связано с финансами.

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

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

Анна Еганова, директор департамента развития и операционной эффективности IT



Я руковожу департаментом развития и операционной эффективности ИТ. Среди моих проектов ключевой это ИТ-стратегия. В ней есть ряд стримов, которые реализуются с моим непосредственным участием. Например, стрим Cost Management, в рамках которого мы продумываем и реализуем активности по снижению затрат на ИТ при постоянном развитии, стрим Архитектура и технологии, в рамках которого мы запустили ребут функции ИТ-архитектуры в банке, трансформируем подходы, развиваем архитектурные компетенции и управление технологиями. Кроме этого, во всех остальных стримах ИТ-стратегии активно участвует моя команда, например, в рамках стрима Стабильность мы выстраиваем и развиваем ИТ-процессы, измеряем Pain Index (индекс клиентской боли), метрики по инцидентам для повышения качества управления стабильностью ИТ-систем. Работаем над важными для сотрудников аспектами (мотивация, карьерное развитие) в рамках стрима People + и многое другое. Ведем стратегические проекты (Happy Developer, Data Masking, Full Remote и многие другие).

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

В 2011-2012 годах я активно занималась автоматизацией процессов розничного кредитования в другом банке, являясь директором департамента розничного андеррайтинга. До этого мой опыт был и в бизнес, и в операционных подразделениях банка, и сформировалось хорошее понимание работы банковских процессов. Я сама вместе с командой занималась разработкой процессов, требований, архитектуры, тестированием. Мы разрабатывали процессы и тут же реализовывали их автоматизацию. Команде удалось автоматизировать практически все этапы процесса розничного кредитования, которые можно было автоматизировать на тот период (кроме визуального отсмотрю документов клиентов). Это позволило в 3 раза уменьшить участие человека в процессе, расширило воронку входящего потока, минимизировало ошибки человеческого фактора. Банк смог значительно наращивать объемы и каналы привлечения, не прирастая в численности сотрудников операционных подразделений.

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

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

Юлия Стрельцова, старший IT-менеджер центра компетенций развития систем принятия решений департамента IT финансового мониторинга и рисков



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

Из реализованных проектов особенно горжусь тем, что в одиночку удалось разобраться с принципами работы ИТ-системы (по обрывкам документации), полностью разработанной сторонним поставщиком ИТ-услуг. Теперь на пару с разработчиком способны вносить практически любые изменения в данную ИТ-систему по заказу пользователей, что позволило полностью отказаться от дорогостоящих услуг вендора. За 2018-2021 год уже сэкономили банку порядка 17,5 млн рублей. Благодаря усовершенствованиям со стороны ИТ и корректным методикам работы с ПО удалось добиться крайне высокой степени стабильности системы, позволяющей работать без технических сбоев и ошибок.

ИТ довольно интересный род занятий, включающий в себя множество профессий и, следовательно, возможностей для реализации, увы, для большинства людей крайне непонятных. В школе выигрывала олимпиады по биологии и информатике, а после того, как при поступлении на биологический факультет МГУ не хватило одного проходного бала, пошла учиться на программиста, о чем нисколько не жалею. Это четвертый для меня по счету банк (три иностранных плюс один российский из системообразующих).

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

Далее планирую развиваться как IT-lead в сочетании с ИТ-аналитиком. Было бы крайне интересно реализовать проект с использованием, например, нейросетей и других элементов искусственного интеллекта в применении к анализу данных.

Елена Боровая, project manager в департаменте развития и операционной эффективности IT



Два моих ключевых проекта это реализация новой ИТ-стратегии и координация QBR (циклов квартального планирования).

По ИТ-стратегии мы работаем в рамках месячных спринтов, работаем в команде ИТ-директоров и лидеров крупных проектов. Всё по канонам Agile с регулярными демо и ретро. И мою роль можно упрощенно описать cкрам-мастер на уровне ИТ-стратегии.

А практики QBR охватывают практически все инициативы по изменениям в банке, реализуемые в форме agile-команд, проектов или CR. Это квартальная сверка часов команд друг с другом, со своими планами и с ожиданиями правления банка. Наш подход к QBR активно развивается вместе с банком. Первые QBR проходили, когда Agile-команды только-только появлялись, сейчас же их уже больше 75%. Это требует постоянного пересмотра и самих QBR практик.

Есть еще очень крутые и сложные ИТ-проекты, которые реализует моя команда это Happy Developer, Data Masking, Эльбрус (миграция дата-центра), развитие гильдий, построение процесса онбординга новых сотрудников, развитие бренда ИТ-работодателя.

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

Я работаю в Росбанке с 2016 г. Моими первыми проектами были внедрение Lean-культуры и программа Agile-трансформации. В конце 2019 г. я плотно работала с ИТ-командой в части формирования новой ИТ-стратегии, и в 2020 г. полностью перешла в ИТ реализовывать ту самую созданную нами новую ИТ-стратегию.

С 8 Марта!
Подробнее..

Трансформация IT-ландшафта в банке

29.10.2020 18:20:36 | Автор: admin

Всем привет! Меня зовут Дима Зыков, я архитектор офиса корпоративной архитектуры Росбанка.


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


Предыстория проекта


У Главной книги есть 2 основные функции: обработка бизнес событий с последующим превращением их в события бухгалтерского учета и хранение уже трансформированных по правилам учёта Банка России событий.


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


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


На первых этапах многие банки решали данную проблему внедрением дополнительных АБС в CORE BANKING сегмент архитектуры, а бухгалтерский учет консолидировали в заранее выбранной мастер системе с главной книгой, либо в вынесенной в сторону системой для формирования регуляторной отчетности и отдельными бухгалтерскими движками. Всё это приводило к тому, что сложность таких ИТ-ландшафтов увеличивалась и с каждым новым внедрением ситуация только усугублялась, увеличивая time-to-market и снижая эффективность возврата инвестиций.



Рисунок 1. Один из многих вариантов IT-архитектуры в эпоху частых глобальных трансформаций в Банках


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


В рамках программы перед нами стояли следующие проблемы, которые предстояло решить:


  1. распределенный бухгалтерский учет с частым дублированием функций в разных системах одного сегмента архитектуры со всеми вытекающими последствиями;
  2. постоянные процессы консолидации результатов финансовой деятельности как при закрытии банковского дня, так и при подготовке отчетности;
  3. жестко связанный продуктовый и бухгалтерский учет на уровне кода систем;
  4. постоянно растущие требования бизнеса к развитию и разнообразию продуктовой логики;
  5. повышенные требования отказоустойчивости к механизмам интеграции систем CORE BANKING сегмента между собой.

Реализация


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


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


В рамках программы по трансформации IT-ландшафта были выделены основные фазы внедрения новой главной книги.


  • Первая фаза подразумевает внедрение только модуля главной книги и её параллельной работы вместе с действующими АБС. Такой режим работы будет дублировать функциональности систем, но позволит обкатать решение от вендора и более уверенно перейти на него уже с внедрением следующей фазы.


Рисунок 2. High-Level-Architecture (далее HLA) первого этапа внедрения новой Главной книги Банка, этапа зеркалирования


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


Рисунок 3. Целевая архитектура (HLA) в рамках проекта внедрения новой Главной книги Банка


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


Сейчас проект внедрения Главной книги находится в стадии активной разработки.


Что это нам даст?


  1. Разделение бухгалтерского и продуктового учета, что в своё время даст возможность развиваться продуктовым платформам самостоятельно, реализуя свою, независимую от регуляторных требований бухгалтерского учета логику во всём её разнообразии.
  2. Возможность быстрой реакции на изменение требований регуляторов в плане бухгалтерского учета, т.к. вся логика бухгалтерского учета реализована в одной системе.
  3. Простые механизмы закрытия бухгалтерского дня и распределенные механизмы закрытия операционного дня в продуктовых системах.
  4. Возможность более детально исследовать TCO каждой отдельной бизнес системы.
  5. Повысится прозрачность в процессах и, как следствие, увеличится скорость реакции на требования бизнеса.
  6. В среднесрочной перспективе начнет снижаться time-to-market при росте сложности и количества банковских продуктов.
  7. Повысится уровень возможностей дальнейшего развития экосистемы банка.

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


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

Подробнее..

Алексей Бородкин и Виталий Мазуревич 9 июля принимают участие в онлайн-конференции UX-марафон

03.07.2020 18:07:41 | Автор: admin
Друзья, привет!

Алексей Бородкин и Виталий Мазуревич, Product Leadы в Росбанке, 9 июля примут участие в онлайн-конференции UX-марафон.

image

В своем выступлении 8 наколок UX-менеджера ребята расскажут, почему работа UX-менеджера с пользовательским опытом (User Experience) не ограничивается только визуальным отображением (макетами, интерфейсами и так далее). И поделятся как в UХ оценивать влияние таких продуктовых факторов как бизнес-требования к продукту, особенности технической платформы, системная архитектура, функциональность; а также влияние текстов и, конечно же, визуальной составляющей.

Алексей Бородкин и Виталий Мазуревич, признанные UX/CX-эксперты, основатели Гильдии вольных проектировщиков, преподаватели ФРИИ и Британской высшей школы дизайна.

Будет интересно и полезно. Приходите!
Подробнее..

Роботизация банковских сервисов

10.07.2020 12:22:13 | Автор: admin
Друзья, привет!

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


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

Какие виды роботов существуют:
RPA Robotic Process Automation это технологии автоматизации бизнес-процессов, заключающиеся в том, что простую работу за компьютером вместо человека выполняет программный комплекс.
IPA Intelligent Process Automation технология интеллектуальной автоматизации бизнес-процессов. В этом случае робот не только выполняет простые действия вроде скопировать-вставить-сравнить-сохранить, но и наделен функцией принятия решений.
Чат-боты технологии, имитирующие речевое поведение человека и предназначенные для общения с живыми людьми, к примеру, клиентами банка.
Когнитивный робот максимально продвинутая программная система, сочетающая все три перечисленных выше функционала и фактически копирующая действия человека, в том числе и в сфере принятия решений.

В апреле 2020 года в Росбанк Дом был внедрен первый робот для автоматизации процесса принятия кредитного решения. Для понимания его функционала немного методологии: одним из этапов проверки компании-работодателя потенциального заёмщика является подтверждение принадлежности заявленного рабочего номера телефона для связи компании через независимые источники. Это осуществляется для того, чтобы верифицировать заявленные клиентом данные. Данный функционал является обязательным при проведении андеррайтинга платежеспособности и ранее выполнялся сотрудниками в ручном режиме.

Сейчас механизм построен следующим образом: робот сопоставляет информацию из поисковой выдачи Yandex c заданными критериями поиска, по которым телефон признается либо принадлежащим заданной компании, либо не принадлежащим, либо мошенническим.

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

Робот формирует для себя задания самостоятельно из кредитных дел, доступных в CRM Loris, и работает до тех пор, пока все задания не будут закончены. Либо есть возможность настройки расписания работы с учетом часовых поясов и нерабочих дней или даже при помощи Cron-выражений

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

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

Мы столкнулись с некоторой обеспокоенностью со стороны ИТ и безопасности по причине новшества такого подхода. ИТ беспокоила нагрузка на информационные ресурсы, которая, по их мнению, могла возникнуть по причине быстрой работы робота. Да, робот может делать операции в 5-10 раз быстрее человека, но он всегда ждет ответа от информационной системы или веб-ресурса (ждет полной загрузки сайта, отрисовки окна, изменение индикатора Загрузка и т.д.), без которого процесс не продвигается дальше, к тому же робот делает все однозадачно, в одном потоке: как человек, но зато в режиме 24/7.

В данном проекте задействуется поисковая система, которая так и не вычислила робота и до сих пор не требует ввода капчи (средство защиты сайта от ботов и автоматических систем), это показывает преимущество данного подхода перед headless-browser подходами.

За работой робота можно смотреть в режиме реального времени, наблюдая, как он нажимает на различные кнопки, двигает курсор и т.п. Были некоторые проблемы при отключении от сеанса удаленного рабочего стола (RDP), т.к. при этом пользовательский сеанс Windows перестает отрисовывать графический интерфейс и работа робота на удаленном виртуальном рабочем месте прерывается, но это можно обойти, если подключаться к рабочему месту робота при помощи теневого подключения (команда Mstsc /shadow).

Также запланирована роботизация процессов на этапе подготовки ипотечной сделки и выдачи кредита, обработка запросов клиентов и т.д.

Каковы же преимущества внедрения робота?
1. Робот работает круглосуточно, снимает рутинную нагрузку с сотрудников и не допускает ошибок, связанных с человеческим фактором, при этом не занимает офисное пространство.
2. Работа робота полностью прозрачна, все действия фиксируются в логах и могут быть проверены.
3. Технологии RPA не требуют сложной интеграции в IT-ландшафт финансовой организации. Он использует имеющуюся систему как это делал бы человек.
4. Робот позволяет значительно улучшить скорость обработки банковских операций, эффективность бэк-офисных и фронт-офисных процессов в банке, уменьшить продолжительность обработки клиентских запросов, а, следовательно, высвободить фронт-офисным сотрудникам время, необходимое для лучшего обслуживания клиентов.

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

Для ответа на вопрос Какие процессы стоит роботизировать? нужно понять следующее:
1. Является ли операция повторяющейся?
2. Одинаково ли протекает процесс каждый раз?
3. Насколько трудоемкий процесс?
4. Тратятся ли на него ресурсы, которые имеет смысл экономить?

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

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

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

De-Flash Как вы справляетесь?

02.03.2021 16:05:07 | Автор: admin
Как всем известно, компания Adobe отказалась от поддержки и выключила flash начиная с 1 января 2021 года. Росбанк активно сотрудничает с компанией SAS крупнейшей в мире частной IT-компанией, специализирующейся на разработке решений и услуг в области бизнес-аналитики. Большинство продуктов SAS используют flash-зависимые компоненты, которые так и или иначе должны быть заменены на flash-независимые или требуют миграции данных на другое ПО, которое уже не использует flash. Сегодня мы хотим рассказать, как мы решали эту задачу, и узнать у сообщества, как аналогичная задача решалась в других компаниях.





Первое, что мы сделали, это заморозили браузер с выключенным 80 портом и рабочей версий flasha. Полагаю, так поступило большинство.

Второй шаг вполне возможно использовать как целевое решение использовать браузер Maxthon 5 с выключенным 80 портом и забыть про необходимость дефлэшатизации. Решение выбрано в связи с особенностью версии браузера, который не будет обновляться сам (финальная версия) и использует 27 версию flash-плеера, который также обновляться уже не будет.

Третье и самое затратное это обновление ПО до flash-независимой версии. Такая задача потребовала усилий со стороны вендора SAS, со стороны команды внедрения ООО Глоубайт и со стороны команды IT банка. Со стороны вендора необходимо было переработать flash-зависимые модули на HTML5 и предоставить инструмент для обновления существующих экземпляров системы. Со стороны команды внедрения выбрать стратегию обновления и проработать план с учетом особенностей внедрения и его кастомизации. Со стороны команды IT согласовать подход с бизнес-заказчиком и обеспечить выполнение работ на производственных средах.

Для продуктов SAS существует два варианта обновления системы. Первый это update-in-place. По сути, это большой патч для платформы SAS с обновлением продуктов, который устанавливается на существующую рабочую среду. Разумеется, что первая установка производится на непромышленных стендах: здесь может потребоваться и провести слияние кода в кастомизированных частях продукта, если такие кастомизации были, и провести регрессионное тестирование. И только следующим шагом будет обновление пред-промышленных и промышленных стендов.

Однако update-in-place возможен не всегда: например, когда продукт эволюционировал и новая версия построена на другой архитектуре и другом техническом стеке. В этом случае необходима полноценная миграция на новую версию ПО это второй вариант обновления ПО SAS.

И именно в такой ситуации оказалось решение SAS AML. Наше достижение последних лет запуск и реализация первой очереди масштабного проекта по построению AML системы для департамента финансового мониторинга. Особенностью данного проекта является то, что это первый проект в банке, в рамках которого в полной мере были задействованы возможности новой платформы онлайн-обработки данных ODPP. В ходе первой фазы были реализованы требования обязательного контроля и отчетность. С конца 2019 года запущена вторая фаза проекта, предполагающая развитие функционала в области выявления сомнительных операций и online-контроля. В промышленном режиме работает версия SAS AML 6.3 на платформе SAS 9.4 M3, а новая версия решения SAS AML 8.2 представлена на обновленной платформе SAS Viya 3.5. Новая платформа построена на новой микросервисной архитектура и включает в себя новые продукты, поэтому при миграции на новую версию одну часть функциональности необходимо адаптировать, другую реализовать заново.

Цель, которая перед нами стояла, выполнить задачу по дефлешезации и выдержать строки второй фазы проекта. Для системы SAS AML выбрали последовательную миграцию в два этапа.
На первом этапе необходима миграция flash-зависимых модулей, что позволит снять острую проблему и уйти от заморозки браузера. Основной модуль, требующий дефлешезации, это SAS Visual Analytics инструмент для создания и визуализации аналитических и управленческих отчетов. Помимо выделения нового оборудования и развертывания новой версии SAS VA 8.5 на платформе SAS Viya 3.5, потребуется решить несколько обязательных задач, таких как интеграция решений и настройка ETL-процессов, так и ряд задач, обеспечивающих прозрачность и удобство работы пользователей, например, настройка сквозной аутентификации (single sign-on), чтобы избежать повторного ввода данных. В следующем этапе полная миграция на новую версию решения SAS AML 8.2: с переносом полной функциональности системы, настройкой интеграций, запуском новой системы в опытно-промышленную эксплуатацию и поддержкой существования двух систем на переходный период.

Коллеги, поделитесь опытом: как вы справились с задачей De-Flash?

Автор статьи @DSSD
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru