Добрый день, Хабр. В этой статье я хочу показать жизненный цикл тестирования клиентского портала разрабатываемого изначально для крупнейшего немецкого банка (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 или, памятуя про свой опыт, тестирование в качестве первого шага, чтобы запрыгнуть в IT сферу. Несмотря на более чем сотню разосланных резюме, поиск работы продолжался более полугода, возможно в том числе и потому, что тут летом-осенью набирают мало новых сотрудников.
В итоге зимой 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 лет уже) была фрау Фрауке (такое имя), которая и стала нашим Тимлидом. Она быстро ввела меня в курс дела, несмотря на мои первоначальные проблемы в немецком, а также отсутствие опыта в автоматизированном тестировании, о котором и пойдет речь. Основной язык фирмы — немецкий, в первую очередь благодаря национальному составу: я был одним из первых иностранцев в офисе. Поэтому скриншоты будут показаны на немецком языке с пояснениями в случае необходимости. Итак, поехали.
С точки зрения методологии нельзя сказать конкретно, что у нас. Такая сборная солянка из 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 тысяч). Это приводит к увеличению эффективности данного сектора и экономики в целом (к примеру в банковском секторе Швейцарии работает меньше людей, чем в Сбербанке), но клеркам остается только посочувствовать.
Вначале немного предыстории.
Меня зовут Александр. В 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 или, памятуя про свой опыт, тестирование в качестве первого шага, чтобы запрыгнуть в IT сферу. Несмотря на более чем сотню разосланных резюме, поиск работы продолжался более полугода, возможно в том числе и потому, что тут летом-осенью набирают мало новых сотрудников.
В итоге зимой 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 тесты и нагрузочное тестирование выполняют разработчики.
а) Черный ящик
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 тысяч). Это приводит к увеличению эффективности данного сектора и экономики в целом (к примеру в банковском секторе Швейцарии работает меньше людей, чем в Сбербанке), но клеркам остается только посочувствовать.