Добрый день, Хабр.
В этой статье я хочу показать жизненный цикл тестирования клиентского портала, разработанного изначально для крупнейшего немецкого банка (Deutsche Bank), а затем для ведущих банков немецкоязычной Европы (UBS – Швейцария, Raifeissen – Австрия), а также для другие банки, работающие по европейскому стандарту ЭБИКС .
Сначала немного предыстории.
Меня зовут Александр.
В 2009 году я окончил МИФИ, факультет теоретической и экспериментальной физики.
Во время учебы я, как и многие технари, активно работал в IT-сфере: сначала ручное тестирование (Microsoft Office и Windows Vista), а затем 1С (Программист-консультант).
Все это мне быстро наскучило и я решил снова обратиться к физике.
Предварительно выучив английский и сдав экзамены TOEFL и GRE, он начал поступать в аспирантуру в США на степень доктора философии.
Мне удалось отправить документы только в 1 (средний) вуз, откуда достаточно быстро пришел положительный ответ. В то же время мой друг, который уже нашел должность доктора философии во Франции, порекомендовал мне написать объявление на европейском сайте вакансий для молодых ученых – и я неожиданно получил 2 приглашения из Германии.
В итоге мой выбор пал в пользу Дойчланда.
Перечислю основные факторы, определившие мой выбор: близость страны к России (2-часовой перелет Берлин-Москва), длительный отпуск по сравнению с США, аспирантура длится в среднем 3-4 года вместо 5-6, плюс Мне понравился немецкий язык, благодаря Rammstein. Докторантура пролетела довольно быстро (чуть больше 3 лет).
Несмотря на некоторые достигнутые результаты и 4 опубликованные статьи, дальше себя в науке я не видел по причине: непопулярности моей темы (физика твердого тела), очень высокой конкуренции в научном сообществе (в среднем 30 постдоков на 1 профессорскую должность), а также а также постоянная необходимость перемещаться по миру в поисках должностей.
Пожив в Германии и выучив более-менее немецкий язык (трудозатраты на изучение, по моим оценкам, в 2 раза выше английского), я решил обратиться к местному рынку труда (докторская степень была защищена как получение Немецкое образование, то есть я мог бы жить в Германии и искать работу в течение 1 года).
Однако найти работу оказалось сложно: во многих случаях меня «переучивали», у меня также не было ни сертификатов, ни местного опыта работы.
На чисто должности разработчика я не претендовал, так как программировать на Python умел лишь немного, а 1С все равно был плохим стартом, особенно в Германии.
В результате выбор был весьма сужен: анализ данных или, учитывая мой опыт, тестирование как первый шаг к прыжку в сферу ИТ.
Несмотря на более сотни разосланных резюме, поиск работы продолжался более полугода, возможно, еще и потому, что летом и осенью здесь набирают мало новых сотрудников.
В итоге зимой 2015 года я получил должность в средней IT-компании в Гамбурге (около 500 сотрудников по всей Германии, 200 в Гамбурге).
Далее я подал заявку на получение Blue Card (недавно был пост об этой так называемой Blue/Blue Card: кстати, Германия выдала 87% всех таких карт со всего Евросоюза, что говорит об относительной доступности рабочей силы рынок для иностранцев и сам факт того, что есть работа), что позволит вам получить вид на жительство уже в начале следующего года.
Регистрация очень простая, достаточно принести копию договора и немецкий сертификат (уровень В1).
С самого начала меня бросили в новый проект: клиентский портал, далее КунденПортал , работаем по стандартам СЕПА .
Важно отметить, что KundenPortal работает в паре с другим продуктом нашей компании: БанкRechner , он же банковский расчетный центр: программа, аккумулирующая все платежи, в том числе с клиентских порталов других компаний, и осуществляющая последующие расчеты для анализа и составления налоговой отчетности.
«Тяжесть» программного обеспечения связана с тем, что крупнейшие банки работают с многими тысячами клиентов, каждый из которых может ввести в систему огромный массив документов.
Естественно, все это работает на очень мощных серверах (Unix), с терабайтными базами данных (Oracle).
В результате нагрузочное тестирование в этом случае имеет решающее значение.
Изначально представленный клиенту проект (почти 2 года назад) имел лишь базовый функционал.
Далее началось активное взаимодействие между менеджерами нашей компании и банками-клиентами.
Клиенты выражают свои пожелания в форме так называемых ЧР s (Запросы на изменение), где описан требуемый функционал.
Естественно, это не просто пожелания, а все согласовывается компетентными в области Zahlungsverkehr (Перевозка платежей/транзакций) с обеих сторон на основе стандарта EBICS и с проработкой юридической стороны и концепций безопасности.
Эти аспекты не входят в мою компетенцию, поэтому оставлю их за скобками.
Далее эти CR (от разных клиентов) собираются в единый список.
Выполнение этого списка определяет итерацию (то есть версию продукта).
В нашем случае типичный цикл выпуска составляет от 3 до 6 месяцев.
На основе этого списка технический руководитель проекта создает Концепция , где он описывает, как это должно быть реализовано и делит всё на темы, которые выбирают программисты на так называемой «Ярмарке тем» (обычно на 1 тему закрепляются 2 программиста для подкрепления и обмена опытом, по завершению темы они смешиваются снова и снова объединяются в пары).
Программисты на основе Концепции и согласовали шаблоны графического интерфейса ( Мокапы ) реализовать все в коде.
Когда код готов на какой-то приемлемый процент, темы распределяются между тестировщиками.
Так как тестировщиков меньше, то получаем несколько тем, тоже по выбору.
Идея та же, что и в случае с разработчиками: мы должны знать максимальный функционал и подстраховать друг друга.
С одной стороны этот метод сложен тем, что нужно знать все о программе и уметь быстро переключаться, но с другой стороны, нам не скучно, постоянно узнаешь что-то новое (даже о финансах и национальных банковских системах), а также можно посмотреть на проблемы тестирования с разных сторон, что повышает эффективность и даже интуицию при поиске ошибок.
В текущей итерации у меня уже около 10 тем.
На начальном этапе в проекте было около 10 разработчиков и 3 тестировщика (причем двое из них только начали работать; другой тестировщик, правда, имел IT-образование).
Сейчас в проекте около 30 разработчиков и 6 тестировщиков, плюс приезжие студенты, которые проводят ручное тестирование в различных браузерах.
Единственным тестировщиком с опытом (уже около 15 лет) была фрау Фрауке (так ее зовут), которая стала нашим Team Lead. Она быстро ввела меня в курс дела, несмотря на мои первоначальные проблемы с немецким языком, а также отсутствие опыта в автоматизированном тестировании, о котором пойдет речь.
Основной язык компании — немецкий, в первую очередь из-за национального состава: я был одним из первых иностранцев в офисе.
Поэтому скриншоты будут показаны на немецком языке с пояснениями при необходимости.
Итак, начнем.
Небольшое примечание для тестировщиков: Мы проводим следующие виды тестирования: а) Черный ящик б) Функциональный в) Модульность, системность и интеграция д) Регрессия Юзабилити и локализация не входят в обязанности нашего отдела.
Тесты JUnit и нагрузочное тестирование выполняются разработчиками.
С методологической точки зрения невозможно сказать конкретно, что мы имеем.
Такая вот мешанина модели V, Agile и т.п.
, а циклы примерно такие: подготовка, разработка тест-кейсов, реализация тест-кейсов, выполнение тестов и выявление ошибок, повторное и регрессионное тестирование.
Чтобы дать представление о том, что такое банковский клиентский портал, покажу скриншот старой версии (извините, авторские права).
Теперь там уже куча пунктов меню в зависимости от варианта лицензирования.
Темы и цвета интерфейса обычно подстраиваются под общий стиль клиент-банка.
Здесь показано, что вы вводите платежные данные определенного типа (DTAZV).
Платеж вводится в одноименный раздел, который в свою очередь находится в разделе Erfassung (ввод/регистрация данных в системе).
Подраздел выше называется Kontoinformationen (Движения по счету).
Ниже приведены функции EBICS. Все интерфейсы выполнены в одном стиле и объединены схожей логикой в плане управления, возможности повторения одного и того же действия разными способами и так далее.
Программа позволяет отслеживать полный жизненный цикл оформления документов, включая: само их оформление, отправку в банк, получение ответа и статус документов, анализ состояния банковских счетов, формирование и выгрузку отчетов.
Все это, естественно, с соблюдением правил и форматов Еврозоны и национальных особенностей каждого банка, плюс приправленное криптографией и шифрованием.
Это приводит к большему количеству настроек, вариантов лицензирования, опций баз данных, опций ПО на серверах, а также умопомрачительной системе администраторов и других ролей (есть как минимум 3 уровня администраторов с несколькими подтипами на каждом уровне и пару сотен прав и ролей, которые в свою очередь разделены по уровням применимости).
Выбранный тип платежного документа: Auftragsart (AZV) — один из десятков возможных вариантов именно для этого выбранного типа платежа (DTAZV), поэтому перед нами широкое поле для комбинаторики.
Естественно, в этом случае в центре внимания становится автоматическое тестирование, основные этапы которого, а также подготовку и сопутствующее программное обеспечение я опишу.
Подготовка
Пока программисты не напишут первые модули, готовые к тестированию, наш отдел не бездействует. Мы тестируем уже выпущенные предыдущие версии (которые могут отличаться для разных клиентов) в первую очередь посредством автоматизированных Smoke-тестов (когда базовый функционал тестируется ежедневно).Далее для новой итерации (напомню, цикл длится в среднем 3-6 месяцев) мы должны подготовить виртуальные машины к тестированию, установить необходимое программное обеспечение (новые версии браузеров, плагинов и т.д.), прочитать и проанализировать Продумайте концепцию, оцените, что важно для тестирования, найдите возможные слабые места, сгенерируйте первые тестовые данные или подготовьте полученные данные от клиента.
Разработка тестового примера
Здесь мы достаточно консервативны: все наши идеи формируем в тест-кейсы, стараясь охватить основные аспекты тестирования и кратко заносим их в документ Excel, с примечаниями и вопросами.Далее организуется либо личная встреча (около 1 часа), либо видеоконференция (наша команда частично находится в другом городе) между руководителем проекта, руководителем группы тестирования, программистами и тестировщиками, имеющими отношение к теме.
Задача тестировщика — представить этот документ, объяснить, что и как он собирается тестировать.
При необходимости сопровождаем презентацию просмотром макетов графического интерфейса (Mockups) или запуском самой программы.
Ответы на вопросы, пояснения с обеих сторон, указания программистов на важные или уязвимые по их мнению места, пожелания и предложения фиксируются и приходит время создавать тест-кейсы в реальности.
Тестовые примеры реализации/программирования
Она/оно состоит из 2 основных частей: а) Конкретное описание тестовых случаев в программе ТестСсылка , то есть собственно документирование.б) Автоматизация тест-кейсов в программе QF-тест. Описание опять же на немецком языке, прошу не судить строго.
Как видите: есть разбивка по версиям и темам; на данный момент у нас есть почти 700 тестовых случаев.
Раньше основным продуктом тестирования компании был известный Центр качества HP. Теперь стандартом стал QF Test> , который по сути принадлежит семейству Капча-повтор , то есть в программе есть возможность записывать действия пользователя (нажатие, ввод данных в GUI и т.п.
и повторно использовать).
Определенный набор действий собран в процедуры.
Обычно элементы интерфейса имеют свои собственные идентификаторы, которые мы используем для ссылки на элемент. Идентификаторы также могут генерироваться динамически в зависимости, например, от номера строки в списке элементов.
В этом случае для доступа к элементам мы также используем регулярные выражения.
Сами тест-кейсы уже формируются, как правило, из процедур, типа конструктора.
Вот как выглядит интерфейс этой программы: 
Тестфолзац (группа тестовых примеров) представляет собой отображение тем, которые мы тестируем (сверху вниз): балансы в иностранной валюте, движения по счетам в Австрии, самоуправление, коды назначения категорий и CFONB (французские стандарты).
В каждой теме у нас есть несколько тест-кейсов, которые в свою очередь могут содержать блок подготовки (Vorbereitung), шаги тестирования, последовательности и самое главное — вызов самих исполняемых процедур.
Ниже мы можем проследить, как изменяются переменные во время выполнения.
Таким образом, основная задача тестировщика на этом этапе — спроектировать исполняемые процедуры, которые должны работать быстро и охватывать основные пути, используемые конечными пользователями в графическом интерфейсе, и сформировать их в тест-кейсы на основе согласованного Excel-документа/презентации.
Иногда клик по интерфейсу занимает слишком много времени или нет смысла делать это в каждой процедуре, тогда мы можем использовать скрипты или вспомогательные классы Java, чтобы, например, быстро создать пользователя или банковский счет. Большим преимуществом QF Test является возможность писать скрипты либо в Джитон (Java + Python) или в Groovy. Лично я пишу только на Jython, так как мне нравится Python, на который он очень похож.
Только сейчас упомяну, что KundenPortal состоит из 2-х частей: GUI и так называемых Web-Services: оболочки, в которой многие действия можно выполнять без участия интерфейса, что гораздо быстрее, чем кликать в самой программе.
Вот лишь кусок скрипта, чтобы не злить продвинутых программистов, где пользователь создается прямо в Web-Services. 
Выполнение тест-кейсов, поиск и регистрация ошибок
Построение и выполнение тест-кейсов происходит одновременно, пока мы не получим их готовую, стабильную версию.Стабильность здесь означает, что тестовый пример будет автоматически выполнен до конца и только ошибка или какая-то техническая проблема может прервать его выполнение.
Вносим найденные ошибки в систему управления ошибками, Трак : 
Тестирование после ошибок и регрессионные тесты
Как видите, уже найдено более 3000, это при том, что программисты тоже проводят тестирование, прежде чем передать эстафету нам.Столь высокая цифра обусловлена, прежде всего, множеством различных форматов и достаточной сложностью и универсальностью интерфейсов (несмотря на то, что, как я уже говорил, они построены по схожему принципу), и, конечно же, нашей внимательностью и дотошностью = ) На данный момент нам удалось отловить почти все ошибки.
Насколько я знаю, клиенты пока только один раз обнаружили что-то относительно серьёзное на стадии тестирования.
После того, как программисты исправляют ошибки, мы снова запускаем наши автоматизированные тесты, в том числе оставляем работу на ночь.
Утром уже можно анализировать ошибки и проблемы.
Также мы проводим регрессионное тестирование, то есть повторно тестируем места, где ошибки могли и не быть выявлены, но изменения в коде могли привести к изменениям в работе программы, в том числе к появлению ошибок.
И напоследок я покажу вам общую рабочую обстановку: 
Сам проект (KundenPortal) и BankRechner, с которым он взаимодействует, находятся в Eclipse Workspace с контролем версий (SVN), где указываем:
а) Вспомогательные классы Java. Мы сами их программируем (может и не по фэншуй, но свою задачу они выполняют), которые вызываются из скриптов QF Test.
б) Текущие параметры тестовых виртуальных машин: одновременно возможны только один KundenPortal и один BankRechner (конфиг).
в) CSV-файлы (пример справа — список пользователей), содержащие информацию о пользователях, клиентах, счетах, шаблонах платежей и так далее (опять же для обеих систем), т. е.
тестовые данные (полностью сгенерированные нами, но имеющие правильные параметры или намеренно неправильные при отрицательном тестировании).
г) Test Suites, собственно QF Test файлы (сборники тест-кейсов или процедур для выполнения): общие (для конкретной версии или темы) и индивидуальные для каждого тестировщика, чтобы вы могли спокойно работать над своей темой и не делать лишнего количества коммитов в общие наборы тестов.
д) Некоторые скрипты, где, например, определяется, какие Test Suites будут запускаться, конфигурация запуска, разбиение жесткого диска на подразделы и т.п.
После того, как все тесты оказались в зеленой зоне и итерация успешно завершена, мы организуем совместное собрание (всех программистов и тестировщиков), где происходит общее обсуждение: что было хорошо, что не очень, какие есть сложности и проблемы.
были во время проекта.
Каждый сотрудник должен рассказать как минимум о 2 положительных и 2 отрицательных аспектах.
На основании этого мы адаптируем дизайн рабочего процесса для следующей итерации.
Также на основе полученного опыта наполняем нашу внутреннюю Википедию, где описаны основные этапы настройки систем и Best Practices: 
Ну и несколько слов о характере работы.
Рабочее время, человеческие ресурсы и итерации настолько спланированы и распределены, что на данный момент нам удалось прийти к финишу одновременно с разработчиками (в день): то есть с нашей стороны все тесты находятся в зеленой зоне.
С их стороны весь функционал готов, все ошибки исправлены, все ToDos выполнены.
Самое главное, чтобы время всегда совпадало с тем, что было обещано клиенту.
Это отличает немецкий способ работы, когда чрезвычайные режимы не приветствуются, а работать надо по-настоящему с самого начала.
Однако не могу сказать, что мне это не нравится, хотя исторически мне нравилось откладывать дела на потом, а потом не спать по ночам.
Также здесь мало кто работает сверхурочно, 40 часов в неделю — золотой стандарт, плюс свободный выбор рабочего времени, за исключением плановых совещаний (в среднем раз в неделю для нижних чинов, 2 раза в неделю для руководства).
Обычно я работаю с 8-9 до 17-18. Также у нас есть 30 дней отпуска, что равно 6 неделям (выходные не в счет), 1 день в подарок при переезде, 2 дня бесплатно на свадьбу (только свою!), 2 дня мужчинам при рождении ребенка.
ребенок.
В компании примерно половина людей имеет IT-образование, другая половина — экономисты, физики и математики.
В послесловии хотелось бы отметить, что конечным результатом внедрения выпущенного продукта для банка является, помимо прочего, большое сокращение рабочих мест за счет автоматизации многих процессов (KundenPortal делает акцент на ускорении работы с документации и избавляя от многих рутинных операций).
Так Deutsche Bank полгода назад объявил о сокращении 15 тысяч сотрудников (из 100 тысяч).
Это приводит к повышению эффективности этого сектора и экономики в целом (например, в швейцарском банковском секторе работает меньше людей, чем в Сбербанке), но клеркам можно только посочувствовать.
Теги: #автоматическое тестирование #разработка #Германия #поиск работы за рубежом #тестирование ИТ-систем
-
Почему Подставки Для Ноутбука Важны
19 Oct, 24 -
Надежны Ли Блоги Как Источники Информации?
19 Oct, 24 -
Я. Субботник В Киеве
19 Oct, 24 -
Очень Странный Тренинг
19 Oct, 24
