Тестирование банковских продуктов что это

Тестирование систем банковского ритейла

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

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

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

Банковский ритейл:

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

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

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

#1) Открытие сберегательного банковского счета в местной валюте.

#2) Открытие сберегательного счета в иностранной валюте.

#3) Открытие текущего счета.

#4) Перевод с одного счета на другой.

#5) Кассовые операции — пополнение счета.

#6) Кассовые операции — снятие денег со счета.

#7) Добавление получателя и перевод средств в каналах банкинга.

Сценарии позитивных тестов для банковских приложений:

1) Подтверждение доступности сведений о клиенте в приложении перед оформлением счета.

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

3) Перед открытием сберегательного или текущего банковского счета проводится подтверждение двумерного кода.

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

4) При открытии счета необходимо должным образом проверить выбранную валюту (местную или зарубежную).

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

6) Для почтового перевода проверки валюты по дебету и кредиту отличается.

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

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

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

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

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

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

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

14) Проверка получения сообщений по завершении транзакции в других каналах банкинга.

15) Проверка дополнительных данных, которые были получены при выдачи ссуды.

16) Проверка дополнительных данных, которые не были получены при выдачи ссуды.

Негативные сценарии тестирования:

1) Проверка создания счета с помощью неверных клиентских данных.

2) Проверка создания счета — при этом следует не ввести двумерный код или не заполнить любое из обязательных полей.

3) Проверка создания сберегательного счета — ввод двумерного кода как текущего счета или наоборот.

4) Проверка создания счета в местной валюте — ввод счета в иностранной валюте и наоборот.

5) Проверка почтового перевода — с помощью валюты дебета и валюты кредита и Это будет обычный перевод со счета, а не почтовый.

6) Проверка кассовой транзакции (снятие средств) — ввод кредитной суммы и наоборот.

7) Проверка кассовой транзакции с помощью неверных номиналов.

К примеру, если кредитная или дебетная сумма составляет 150, тогда следует ввести номинал для 100 как 1 и номинал для 50 как 2. Система не должна разрешить проведение транзакции.

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

К примеру, если название счета «Маша» и номер счета 12345, тогда для тестирования этого сценария можно использовать произвольное название «Рома» как название счета, и номер счета как 12345. Система не должна разрешить добавление нового получателя счета т.к. как название счета нового получателя и номер не совпадают.

9) Проверка возможности добавления получателя в других каналах банкинга с помощью предоставления неверного IFSC-кода.

10) Проверка возможности добавления получателя в других каналах банкинга без предоставления каких-либо обязательных данных.

11) Проверка перевода средств в других каналах без предоставления каких-либо обязательных данных.

12) Проверка получения сообщения с помощью предоставления неверного номера мобильного телефона.

13) Проверка дополнительных данных при создании небезопасной ссуды.

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

14) Не предоставление дополнительных данных при создании безопасной ссуды.

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

Тестирование эффективности:

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

2) Проверка пользователя — вход в приложение для банковского ритейла в течение нескольких секунд за счет предоставления верных ID и пароля.

3) Проверка входа в приложение при отключенном сервере.

Тестовые сценарии для проверки безопасности

1) Попытка входа в приложение с помощью предоставления верного ID и пароля, проверка на предмет наличия шифрования поля для пароля.

2) Проверка входа в приложение с помощью предоставления неверного ID пользователя или пароля.

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

Советы по тестированию приложения для банковского ритейла:

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

Источник

Финансовая сфера

Пять правил настройки тестирования банковских IT-продуктов

Чек-лист хирурга — контрольный перечень вопросов, на основании которых проверяется, правильно ли выполнена та или иная работа, — снижает вероятность послеоперационных осложнений и смертей почти на 5%

Директор по производству (CPO) компании Umbrella IT

IT-чек-лист — QA (Quality Assurance) — в финансовой сфере в теории решает схожие задачи — минимизирует влияние человеческого фактора, сокращает time to market банковских продуктов и повышает их безопасность и качество. Как эффективно настроить тестирование, за счет чего это сделать и к каким результатам это приведет? Представляю топ-лист «рецептов», проверенных Umbrella IT на практике

1. Привлекайте тестировщиков с сильной технической экспертизой и вовлекайте их в работу над продуктом.

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

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

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

2. Пусть тестировщики осваивают специфику вашего сектора и становятся в нем экспертами.

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

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

3. Не экономьте на тестировщиках и оборудовании

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

вкладываемся в парк устройств: тестирование на эмуляторах уместно только до определенного момента. В реальной жизни с продуктом будут работать тысячи пользователей с самых разных устройств, и особенности этих устройств необходимо учитывать. Например, iPhone с его «бровью», Samsung S10 с его вырезом под фронтальную камеру или Samsung с процессором Exynos и процессором Qualcomm могут по-разному работать с приложением. Плюс нужна проверка кейсов взаимодействия с другими приложениями: что будет, например, если на смартфон позвонят, когда приложение открыто, или если сработает будильник. Нужно определить целевые устройства и проверять реальные пользовательские сценарии на реальных, физических устройствах.

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

4. Не отделяйте процессы тестирования от процессов разработки

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

5. Внедрите стандарты тестирования и следите за их соблюдением

тестируем новый функционал параллельно разработке: уходим от схемы, когда 1) производится релизная сборка и только затем — тестирование всего релиза в целом с последующим устранением выявленных багов; 2) в тестовой среде одновременно залито много нестабильных, нетестированных задач, и это усложняет локализацию багов;

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

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

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

сокращается время на исправление багов и увеличивается объем функционала, который тестируется в рамках одного спринта, в итоге ускоряется вывод продукта на рынок.

Источник

Как устроено тестирование «тяжелого» банковского софта в немецкой фирме

Добрый день, Хабр. В этой статье я хочу показать жизненный цикл тестирования клиентского портала разрабатываемого изначально для крупнейшего немецкого банка (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 тысяч). Это приводит к увеличению эффективности данного сектора и экономики в целом (к примеру в банковском секторе Швейцарии работает меньше людей, чем в Сбербанке), но клеркам остается только посочувствовать.

Источник