Як влаштовано тестування «важкого» банківського софта в німецькій фірмі

Добрий день, Хабр. У цій статті я хочу показати життєвий цикл тестування клієнтського порталу розроблявся спочатку для найбільшого німецького банку Deutsche Bank) і далі для провідних банків в німецькомовній Європі (UBS – Швейцарія, Raifeissen – Австрія), а також для інших банків працюють за європейським стандартом EBICS.

Спочатку трохи передісторії.

Мене звати Олександр. У 2009 році я закінчив МІФІ, факультет Теоретичної та Експериментальної Фізики. Під час навчання, як і багато технарі, я підробляв активно в сфері IT: спочатку ручне тестування (Microsoft Office і Windows Vista), а потім 1С (Програміст-Консультант). Все це досить швидко мені набридло і я вирішив звернутися знову до фізики. Попередньо вивчивши англійську, здавши TOEFL і GRE іспити, став надходити в США в аспірантуру на PhD. Я встиг відіслати тільки документи в 1 (середньої руки) університет, звідки досить швидко прийшов позитивну відповідь. У той же час мій товариш, який вже знайшов PhD позицію у Франції, порекомендував мені написати оголошення на європейському сайті вакансій для молодих вчених — і мені несподівано прийшло 2 запрошення з Німеччини. У підсумку мій вибір припав на користь Deutschland. Перерахую основні фактори, що визначили мій вибір: близькість країни до Росії (2х годинний переліт Берлін-Москва), довгий порівняно з США відпустку, PhD триває в середньому 3-4 роки замість 5-6, плюс мені подобався німецька мова, завдяки Rammstein.

PhD пролетів досить швидко (трохи більше 3 років). Незважаючи на деякі досягнуті результати і 4 опубліковані статті, я не бачив себе далі в науці через: непопулярності моєї теми (фізика твердого тіла), дуже високої конкуренції в науковому середовищі (30 постдоков в середньому на 1 професорське місце), а також постійної необхідності переїжджати по всьому світу в пошуках позицій. Пообжившись в Німеччині і вивчивши більш менш німецька мова (робота на вивчення за моїми прикидками в 2 рази вище англійської), я вирішив звернутися до місцевого ринку праці (докторська ступінь защиталась як отримання німецького освіти, тобто я міг жити в Німеччині і шукати роботу ще протягом 1 року). Однак, знайти роботу виявилося непросто: у багатьох випадках я був перекваліфікований», сертифікатів і місцевого досвіду роботи у мене теж не було. На чисто девелоперські позиції я не подавався, так як вмів програмувати лише трохи на Пітоні, а 1С все-таки поганий старт, тим більше в Німеччині. У підсумку вибір був досить звужений: Data Analysis або, пам'ятаючи про свій досвід, тестування в якості першого кроку, щоб застрибнути в ІТ-сферу. Незважаючи на більш ніж сотні розісланих резюме, пошук роботи тривав понад півроку, можливо в тому числі і тому, що тут влітку-восени набирають мало нових співробітників.

У результаті взимку 2015 року я отримав позицію в середній за розміром IT фірмі в Гамбурзі (близько 500 співробітників по всій Німеччині, 200 в Гамбурзі). Далі я оформив Blue Card (тут нещодавно був пост про цю так званої Блакитний/Синій Карті: до речі Німеччина видала 87% всіх таких карт від усього Євросоюзу, що вказує на відносну доступність ринку праці для іноземців та на сам факт, що є робота), яка дозволить вже на початку наступного року отримати ВНЖ. Оформлення дуже просте, достатньо принести копію контракту та сертифікат німецького (рівень В1).

З самого початку мене кинули на новий проект: клієнтський портал, далі KundenPortal, що працює за стандартами SEPA.

Важливо згадати, що KundenPortal працює в парі з іншим продуктом нашої фірми: BankRechner, ака банківський розрахунковий центр: програма яка акумулює всі платежі, у тому числі з клієнтських порталів інших фірм, і проводить подальші розрахунки для аналізу та податкової звітності. «Важкість» софта виникає з факту, що найбільші банки працюють з багатьма тисячами клієнтів, кожен з яких може вводити в систему величезний масив документів. Природно, все це працює на дуже потужних серверах (Unix), з терабайтними базами даних (Oracle). У підсумку, навантажувальне тестування в цьому випадку критично.

Проект спочатку представлений клієнту (майже 2 роки тому) мав лише базовий функціонал. Далі почалося активне взаємодія між менеджерами нашої фірми і банками-клієнтами. Клієнти оформляють свої побажання у вигляді так званих CRs (Change Requests), де описано необхідний функціонал. Природно, це не просто побажання, а все узгоджується компетентними в області Zahlungsverkehr (Платіжний транспорт/транзакції) людьми з обох сторін на основі EBICS стандарту і з опрацюванням юридичної сторони і концепцій безпеки. Ці аспекти лежать не в площині моєї компетенції, тому я залишу за дужками.

Далі ці CRs (від різних клієнтів) акумулюються в єдиний список. Виконання цього списку визначає ітерацію (вона ж версія продукту). У нашому випадку типовий цикл версії лежить між 3ма і 6ю місяцями. На основі цього списку технічний керівник проекту створює Концепт, де він описує, як це повинно бути реалізовано і поділяє всі на теми, які програмісти вибирають на так званій «Ярмарку тим» (зазвичай 2 програміста припадають на 1 тему для підстраховки і обміну досвідом, по завершенні теми вони знову перемішуються і знову об'єднуються в пари). Програмісти на основі Концепту та узгоджених шаблонів GUI (Mockups) реалізують всі в коді. Коли код готовий на якийсь прийнятний відсоток, теми розподіляються між тестерами. Так як тестерів менше, ми отримуємо кілька тем, теж за вибором. Ідея схожа, як і у випадку розробників: ми повинні знати максимально функціонал і страхувати один одного. З одного боку такий метод складний в плані того, що треба все знати про програму та вміти швидко перемикатися, але з іншого – нам не стає нудно, постійно дізнаєшся щось нове (навіть про фінанси та національні банківські системи), а також можна поглянути на проблеми тестування під різними кутами, що підвищує ефективність і навіть інтуїцію при пошуку багів. У нинішній ітерації на мене припадає вже близько 10 тем.

На початковому етапі в проекті було близько 10 розробників і 3 тестера (причому 2 з них тільки вийшли на роботу, інший тестер, втім, мав IT освіта). Зараз у проекті близько 30 розробників і 6 тестерів, плюс приходять студенти, які виконують ручне тестування в різних браузерах. Єдиним тестером з досвідом (близько 15 років) була фрау Фрауке (таке ім'я), яка і стала нашим Тимлидом. Вона швидко ввела мене в курс справи, незважаючи на мої початкові проблеми в німецькому, а також відсутність досвіду в автоматизованому тестуванні, про який і піде мова. Основна мова фірми — німецький, в першу чергу завдяки національним складом: я був одним з перших іноземців в офісі. Тому скріншоти будуть показані на німецькій мові з поясненнями в разі необхідності. Отже, поїхали.

Коротка ремарка для тестерів:Ми здійснюємо наступні види тестування:
а) Чорний ящик
b) Функціональне
з) Модульне, системне та інтеграційне
e) Регрессионное
Юзабіліті і локалізація не входять в обов'язки відділу. JUnit тести і навантажувальне тестування виконують розробники.

З точки зору методології не можна сказати конкретно, що у нас. Така збірна солянка з V моделі, Agile і т. д., а цикли приблизно наступні:підготовка, розробка тест кейсів, реалізація тест кейсів, виконання тестів і виявлення помилок, повторне та регрессионное тестування.

Щоб дати уявлення, що таке банківський клієнтський портал, я покажу скріншот старої версії (соррі, копірайт). Зараз існує вже купа пунктів меню, в залежності від варіанту ліцензування. Теми та кольори інтерфейсу зазвичай підбираються під загальну стилістику банку-клієнта.



Тут показано введення даних платежу певного типу (DTAZV). Платіж вводиться в розділі що має таку ж назву, що в свою чергу, знаходиться у розділі Erfassung (занесення/реєстрація даних в системі). Підрозділ вище називається Kontoinformationen (Руху за рахунками). Нижче знаходяться функції EBICS.

Всі інтерфейси витримані в єдиному стилі і об'єднані схожою логікою в плані елементів управління, можливості повторення одного і того ж дії різними способами і так далі. Програма дозволяє відстежити повний життєвий цикл оформлення документів, у тому числі: саме їх оформлення, відсилання в банк, отримання відповіді і статусу документів, аналіз стану банківських рахунків, формування та вивантаження звітів. Все це, природно, з дотриманням правил і форматів Єврозони і національних особливостей кожного банку, плюс приправлено криптографією і шифруванням. Це призводить до більшої кількості налаштувань, варіантів ліцензування, варіантів баз даних, варіантів софта на серверах, а також мозгодробительной системі адміністраторських та інших ролей (так передбачено, як мінімум 3 рівня адміністраторів з декількома їх підвидами на кожному рівні і пара сотень прав і ролей, які в свою чергу дробляться на рівні придатності).

Вибраний тип платіжного документа: Auftragsart (AZV) є одним з десятків можливих варіантів тільки для цього типу вибраного платежу (DTAZV), тому у нас є широке поле для комбінаторики. Природно, у такому випадку на перше місце стає автоматичне тестування, основні фази якої, а також підготовку і супутній софт я опишу.

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

Далі для нової ітерації (цикл нагадаю триває в середньому 3-6 місяців) ми повинні підготувати віртуальні машини для тестування, встановити необхідний софт (нові версії браузерів, плагінів і так далі), прочитати і проаналізувати Концепт, прикинути що важливо для тестування, знайти можливі слабкі місця, згенерувати перші тестові дані, або підготувати отримані дані від клієнта.

Проектування Тест Кейсів
Тут ми досить консервативні: всі наші ідеї, ми формуємо в тест кейси, намагаючись охопити основні аспекти тестування і коротко заносимо їх в Excel документ, з позначками і питаннями. Далі або організовується особиста зустріч (близько 1 години), або відео-конференція (у нас частково команда знаходиться в іншому місті) між керівником проекту, керівником команди тестування, програмістами і тестерами, які мають відношення до теми. Завдання тестера презентувати цей документ, пояснити, що і як він збирається тестувати. У разі необхідності ми супроводжуємо презентацію переглядом макетів GUI (Mockups) або запуском самої програми. Відповіді на запитання, пояснення з обох сторін, вказівки програмістів на важливі чи вразливі на їхню думку місця, побажання та пропозиції фіксуються і настає час формування тест кейсів в реальності.

Реалізація/Програмування Тест Кейсів
Вона/воно складається з 2 основних частин:
а) Конкретний опис тест кейсів у програмі TestLink, тобто фактично документування.
b) Автоматизація тест кейсів у програмі QF Test.
Опис знову ж німецькою мовою, прошу не судити суворо.



Як можна бачити: присутній розбиття за версіями і темами, на даний момент у нас майже 700 тест кейсів.

Раніше основним продуктом для тестування в фірмі був відомий HP Quality Center. Зараз стандартом став QF Test>, який, по суті, належить до сімейства Captcha-Replay, тобто в програмі можливо записати дії користувача (кликання, введення даних в GUI і т. д. і використовувати повторно). Певна сукупність дій збирається процедури. Зазвичай елементи інтерфейсу мають свої IDs, які ми використовуємо, щоб звернутися до елементу. IDs можуть також динамічно генеруватися, наприклад залежно від номера рядка в списку елементів. В такому випадку, щоб отримати доступ до елементів, ми використовуємо в тому числі і регулярні вирази. Самі тест кейси вже формуються, як правило, з процедур, як конструктор. Ось так виглядає інтерфейс цієї програми:



Testfallsatz (група тест кейсів) є відображенням тих, які ми тестуємо (зверху вниз): Валютні сальдо, Руху за рахунками для Австрії, Самоадминистрирование, Категорія Кодів Призначення і CFONB (французькі стандарти). В кожній темі у нас кілька тест кейсів, ті у свою чергу можуть містити блок підготовки (Vorbereitung), тестові кроки, послідовності, і головне — виклик самих виконуваних процедур. Внизу ми можемо відстежити, як змінюються змінні під час виконання.

Таким чином головною задачею тестера на цьому етапі є конструювання виконуваних процедур, які повинні працювати швидко і покривати основні шляхи використовуються кінцевими користувачами в графічному інтерфейсі, і формування їх в тест кейси на основі узгодженого Excel документа/презентації. Іноді клікати по інтерфейсу занадто довго або не має сенсу робити це в кожній процедурі, тоді ми можемо використовувати скрипти або допоміжні класи Java, щоб, наприклад, створити швидко користувача або банківський рахунок.

Великою перевагою QF Test є можливість писати скрипти або в Jython (Java + Python), або в Groovy. Особисто я пишу тільки в Jython, так як мені подобається Python, на який він дуже схожий. Тільки зараз я згадаю, що KundenPortal складається з 2х частин: GUI і так званих Web-Services: оболонки, де багато дії можуть бути виконані без участі інтерфейсу, що набагато швидше, ніж кликати в самій програмі. Ось тільки шматочок скрипта, щоб не розгнівати просунутих програмістів, де створюється безпосередньо користувач в Web-Services.



Виконання тест кейсів, пошук і реєстрація помилок
Конструювання та виконання тест кейсів відбувається одночасно, до тих пір поки ми не отримуємо їх готову, стабільну версію. Під стабільністю тут розуміється, що тест кейс буде автоматично виконуватися до кінця і лише помилка або якась технічна проблема може перервати його виконання. Знайдені помилки ми заносимо в систему управління помилками, Trac:



Тестування після виправлення помилок і регресійні тести
Можна бачити, що вже знайдено більше 3000, це незважаючи на те, що програмісти теж тестують, перед тим як передати нам естафету. Таке високе число обумовлено в першу чергу безліччю різних форматів і достатньою складністю і багатогранністю інтерфейсів (незважаючи на те, що вони, як я і говорив, побудовані за схожим принципом), ну і, зрозуміло, нашої уважністю і в'їдливістю =) Поки що нам вдалося відловити майже всі баги. Наскільки мені відомо, клієнти поки знайшли тільки одного разу щось щодо серйозне в стадії тестування вже ними.

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

Ну і наостанок, я покажу загальну робочу середу:



Сам проект (KundenPortal) і BankRechner, з яким він взаємодіє, знаходиться в Eclipse Workspace з системою управліннями версій (SVN), де ми запитуємо:

a) Допоміжні Класи Java. Ми їх самі програмуємо, (може і не по фэншую, але своє завдання вони виконують), які викликаються з скриптів QF Test.
b) Поточні параметри тестових віртуальних машин: одномоментно тільки один KundenPortal і один BankRechner можливі (сonfig).
c) файли CSV (приклад праворуч — список користувачів), де міститься інформація про користувачів, клієнтів, рахунки, платіжних шаблони і так далі (знову ж для обох систем), ака тестові дані (повністю згенеровані нами, але мають правильні параметри, або навмисно неправильні для негативного тестування).
d) Test Suites, фактично файли QF Test (колекції тест кейсів або процедур для виконання): загальні (для певної версії або теми) і індивідуальні для кожного тестера, щоб можна спокійно займатися своєю темою і не робити зайву кількість комітів в загальні Test Suites.
e) Деякі скрипти, де, наприклад, визначається, які Test Suites будуть запущені, конфігурація запуску, розбиття жорсткого диска на підрозділи і т.д.

Після того, як всі тести знаходяться в зеленій зоні та ітерація успішно закінчена, ми організуємо спільну зустріч (всі програмісти і тестери), де йде спільне обговорення: що було добре, що не дуже, які труднощі і проблеми були під час проекту. Кожен співробітник повинен принаймні розповісти про 2х позитивних і про 2х негативних аспектах. На підставі цього ми адаптуємо побудова робочого процесу для наступної ітерації. Також на підставі отриманого досвіду ми заповнюємо нашу внутрішньофірмову Вікіпедію, де описуються основні кроки налаштування систем і Best Practices:



Ну і пара слів про характер роботи.

Робочий час, людські ресурси та ітерації так розплановані і розподілені, що на даний момент нам вдавалося дійти до фінішної прямої в один час з розробниками (з точністю до дня): тобто з нашого боку всі тести в зеленій зоні, з їх боку весь функціонал готовий, всі помилки виправлені, всі ToDos зроблені. Найголовніше — це час завжди збігалося з обіцяним клієнту. Це відрізняє німецький склад роботи, коли авральні режими не вітаються, а доводиться з самого початку працювати по-справжньому. Однак не можу сказати, що це мені не подобається, хоча історично я любив прокрастинировать, а потім не спати ночами. Також тут мало хто переробляє, 40 годин в тиждень – золотий стандарт, плюс вільної вибір часу роботи, за винятком намічених зборів (у середньому раз на тиждень для нижчих чинів, 2 рази в тиждень для менеджменту). Я зазвичай працюю в інтервалі 8-9 до 17-18. Також у нас 30 днів відпустки, що дорівнює 6 тижнів (вихідні не в рахунок), 1 день в подарунок при переїзді, 2 дні вільних для весілля (тільки власної!), 2 дні для чоловіків при народженні дитини. У фірмі приблизно половина людей має IT освіта, інша половина: економісти, фізики, математики.

В якості післямови хочеться відзначити, що кінцевим результатом впровадження випущеного продукту для банку є в тому числі і велике скорочення робочих місць внаслідок автоматизації багатьох процесів (KundenPortal робиться наголос на прискорення роботи з документацією та викорінення безлічі рутинних операцій). Так Deutsche Bank ще півроку тому анонсував скорочення 15 тисяч співробітників (100 тисяч). Це призводить до збільшення ефективності даного сектора та економіки в цілому (наприклад, у банківському секторі Швейцарії працює менше людей, ніж в Ощадбанку), але клеркам залишається тільки поспівчувати.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.