ドイツの会社での「重い」銀行ソフトウェアのテストはどうですか

こんにちは、Habr。 この記事では、ドイツ最大の銀行（ドイツ銀行）、さらにドイツ語圏の主要銀行（UBS-スイス、Raifeissen-オーストリア）、および欧州EBICS標準に従って動作する他の銀行向けに最初に開発されたクライアントポータルのテストのライフサイクルを示したいと思います。



最初に、少しの背景。



私の名前はアレクサンダーです。 2009年に、理論物理学および実験物理学部のモスクワ工学物理学研究所を卒業しました。 多くの技術者のように、研究中に、IT分野でパートタイムで積極的に働いていました。最初は手動テスト（Microsoft OfficeおよびWindows Vista）、次に1C（プログラマーコンサルタント）です。 これらすべてがすぐに私を退屈させ、私は再び物理学に目を向けることに決めました。 以前に英語を学び、TOEFLとGREの試験に合格した後、彼は博士課程でアメリカの大学院に行き始めました。 私は1つの（中級）大学にのみ文書を送信し、そこから肯定的な回答がすぐに十分に届きました。 同時に、フランスですでに博士号を取得していた友人は、若い科学者のためにヨーロッパの空席サイトに広告を書くことを勧めました。そして、ドイツから突然2つの招待状を受け取りました。 結局、私の選択はドイツに有利になりました。 私の選択を決定した主な要因をリストします：ロシアに近いこと（ベルリン-モスクワの2時間のフライト）、米国と比較して長期休暇、博士号は5-6の代わりに平均3-4年続き、さらに私はラムシュタインのおかげでドイツが好きでした。



PhDは十分に高速で飛行しました（わずか3年以上）。 いくつかの達成結果と4つの公開された記事にもかかわらず、私は自分のトピックの不人気（固体物理学）、科学界での非常に高い競争（1教授あたり平均30人のポスドク）、およびまた、ポジションを求めて世界中を動き回る必要性が常にあります。 ドイツで自分自身を見て、多かれ少なかれドイツ語を学んだ後（私の推定によると、勉強の人件費は英語の2倍です）、地元の労働市場に頼ることに決めました（私の博士号はドイツの教育を受けていると擁護しました、つまり、私はドイツに住んでもっと仕事を探すことができました1年以内）。 しかし、仕事を見つけるのは簡単ではありませんでした。多くの場合、私は「再教育」を受けていました。証明書も現地での経験もありませんでした。 私はPythonでプログラミングする方法を少ししか知らなかったので、純粋に発達的な立場に陥ることはありませんでした。特にドイツでは、1Cはまだ悪いスタートです。 その結果、選択肢が十分に絞り込まれました。データ分析、または私の経験を念頭に置いて、IT分野に飛び込むための最初のステップとしてのテストです。 100人以上の履歴書が送られましたが、仕事の検索は6か月以上続きました。これはおそらく、夏と秋にここに採用する新入社員がほとんどいないためかもしれません。



その結果、2015年の冬に、私はハンブルクの中規模IT企業（ドイツ全土で約500人、ハンブルグで200人）に就職しました。 その後、ブルーカードを発行しました（このいわゆるブルー/ブルーカードに関する最近の投稿がありました：ところで、ドイツは欧州連合全体からそのようなカードの87％を発行しました。これは外国人にとって労働市場の相対的なアクセシビリティと仕事があるという事実を示しています）来年の初めにすでに居住許可を取得することができます。 デザインは非常にシンプルで、契約書のコピーとドイツ語の証明書（レベルB1）を持ってくるだけです。



最初から、彼らは私に新しいプロジェクトを投げかけました。クライアントポータル、そしてKEPAで 、これはSEPA標準に従って動作します。



KundenPortalは、当社の別の製品であるBankRechner （別名銀行決済センター）とペアになっていることに注意することが重要です： BankRechnerは 、他の企業のクライアントポータルからを含むすべての支払いを蓄積し、分析および税レポートのための後続の計算を実行するプログラムです。 ソフトウェアの「重さ」は、最大の銀行が何千もの顧客と連携しており、それぞれが膨大な数のドキュメントをシステムに入力できるという事実に起因しています。 当然、これらはすべてテラバイトのデータベース（Oracle）を備えた非常に強力なサーバー（Unix）で機能します。 そのため、この場合の負荷テストは重要です。



クライアントに最初に提示されたプロジェクト（ほぼ2年前）には基本的な機能しかありませんでした。 その後、当社のマネージャーとクライアント銀行の間で積極的な交流を始めました。 クライアントは、必要な機能を説明する、いわゆるCR （変更要求）の形式で希望を作成します。 当然、これは単なるウィッシュリストではありませんが、すべてがEBICS標準に基づいて、法的側面とセキュリティの概念に基づいて、両側のZahlungsverkehr（支払い輸送/トランザクション）の有能な人々によって調整されます。 これらの側面は私の能力の領域ではないため、括弧の外に置きます。



さらに、これらの（異なる顧客からの）CRは単一のリストに蓄積されます。 このリストの実行により、反復が定義されます（製品のバージョンでもあります）。 この場合、一般的なバージョンサイクルは3〜6か月です。 このリストに基づいて、技術プロジェクトマネージャーは、それを実装する方法を説明するコンセプトを作成し、いわゆる「フェアのテーマ」でプログラマーが選択するトピックにすべてを分割します（通常、2人のプログラマーが安全性と経験の交換のために1つのトピックに分類されますトピックの最後に、それらは再び混合され、再びペアリングされます）。 コンセプトと一貫性のあるGUIテンプレート（ モックアップ ）に基づくプログラマーは、すべてをコードで実装します。 コードが許容可能な割合で準備が整うと、テスター間でトピックが配布されます。 テスターの数が少ないため、いくつかのトピックを選択することもできます。 開発者の場合と同様に、考え方は似ています：最大の機能を知り、お互いを保証する必要があります。 一方で、この方法はプログラムに関するすべてを知っており、迅速に切り替えることができるという点で複雑ですが、一方で、退屈することはなく、常に新しいことを学んでいます（財政や国の銀行システムについてさえ）。さまざまな角度から問題をテストします。これにより、バグを検索する際の効率が向上し、直感も向上します。 現在の反復では、すでに約10のトピックがあります。



初期段階では、プロジェクトには約10人の開発者と3人のテスターがいました（さらに、そのうち2人は仕事に就き、もう1人はIT教育を受けていました）。 現在、プロジェクトには約30人の開発者と6人のテスターがおり、さらに、さまざまなブラウザーで手動テストを行う新入生もいます。 経験を積んだ唯一のテスター（すでに約15年）はFrau Frauke（そのような名前）であり、私たちのTimlidになりました。 ドイツ語での最初の問題や、自動テストの経験が不足しているにもかかわらず、彼女はすぐに私を最新の状態にしてくれました。 会社の主な言語はドイツ語です。これは主に国の構成によるものです。私はオフィスで最初の外国人の一人でした。 したがって、スクリーンショットは必要に応じて説明付きでドイツ語で表示されます。 行きましょう。





方法論の観点から、私たちが持っているものを具体的に言うことは不可能です。 Vモデル、アジャイルなどからのこのような寄せ集め、およびサイクルは、およそ次のとおりです。 準備、テストケースの開発、テストケースの実装、テストの実行とバグの特定、反復テストおよび回帰テスト。



銀行のクライアントポータルとは何かを理解するために、古いバージョンのスクリーンショットを表示します（申し訳ありませんが、著作権）。 ライセンスオプションに応じて、すでに多数のメニュー項目があります。 インターフェイスのテーマと色は通常、クライアントバンクの一般的なスタイルに適合しています。







これは、特定のタイプの支払いデータ（DTAZV）のエントリを示しています。 支払いは、同じ名前のセクションに入力されます。同じ名前のセクションは、Erfassungセクションにあります（システムでのデータの入力/記録）。 上記のサブセクションは、アカウント情報（アカウント移動）と呼ばれます。 以下はEBICS機能です。



すべてのインターフェイスは同じスタイルで設計され、コントロール、同じアクションを異なる方法で繰り返す機能などの点で類似したロジックによって統合されています。 このプログラムを使用すると、書類自体、銀行への送信、応答と文書ステータスの受信、銀行口座のステータスの分析、レポートの生成とアップロードなど、書類のライフサイクル全体を追跡できます。 もちろん、これはすべて、ユーロ圏のルールと形式、および各銀行の国家的特性に準拠し、さらに暗号化と暗号化を取り入れています。 これにより、より多くの設定、ライセンスオプション、データベースオプション、サーバー上のソフトウェアオプション、および管理者と他のロールの頭脳システムがもたらされます（これにより、各レベルにいくつかの亜種と数百の権限とロールを持つ少なくとも3レベルの管理者が提供されます。次に、適用レベルに分割されます）。



選択された支払い文書の種類：Auftragsart（AZV）は、この選択された支払いの種類（DTAZV）にのみ可能な数十のオプションの1つであるため、組み合わせに関する幅広い分野があります。 当然、この場合、自動テストは最前線にあり、その主なフェーズ、および準備と関連ソフトウェアについて説明します。

準備する

プログラマーがテストの準備が整った最初のモジュールを埋める前は、私たちの部署は怠けていません。 すでにリリースされた以前のバージョン（クライアントによって異なる場合があります）を、主に自動化されたSmokeテスト（基本機能が毎日テストされるとき）でテストします。



次に、新しいイテレーション（サイクルが平均3-6か月続くことを思い出します）のために、テストのために仮想マシンを準備し、必要なソフトウェア（ブラウザーの新しいバージョン、プラグインなど）をインストールし、コンセプトを読んで分析し、テストに重要なものを見つけ、可能性を見つける必要があります弱点、最初のテストデータの生成、またはクライアントから受信したデータの準備。

テストケースの設計

ここでは非常に保守的です。すべてのアイデアをテストケースにまとめ、テストの主な側面をカバーし、メモや質問とともにExcelドキュメントに簡単に入力しようとします。 次に、プロジェクトマネージャー、テストチームの責任者、トピックに関連するプログラマーおよびテスターの間で、個人的な会議（約1時間）が開催されるか、ビデオ会議（一部が別の都市に配置されます）が行われます。 テスターのタスクは、このドキュメントを提示し、テストの内容と方法を説明することです。 必要に応じて、GUIレイアウト（モックアップ）を表示するか、プログラム自体を起動して、プレゼンテーションに同行します。 質問への回答、両側からの説明、重要なまたは脆弱な場所へのプログラマーの指示、彼らの意見、希望および提案が記録され、実際にテストケースを作成する時が来ました。

実装/プログラミングケーステスト

彼女/それは2つの主要部分で構成されています：

a） TestLinkプログラムのテストケースの具体的な説明、つまり実際にはドキュメント。

b） QFテストプログラムでのテストケースの自動化。

説明は再びドイツ語ですが、厳密に判断しないでください。







ご覧のとおり、バージョンとテーマごとの内訳がありますが、現時点ではほぼ700のテストケースがあります。



以前は、有名なHP Quality Centerが会社のテストの主要製品でした。 現在、標準はQF Test>であり、これは本質的にCaptcha-Replayファミリーに属します。つまり、プログラムでユーザーアクションを記録することができます（クリック、GUIでのデータ入力など、再利用）。 特定の一連のアクションが手順で収集されます。 通常、インターフェイス要素には独自のIDがあり、これを使用して要素を参照します。 たとえば、アイテムのリストの行番号に応じて、IDを動的に生成することもできます。 この場合、要素にアクセスするために、正規表現も使用します。 テストケース自体は、コンストラクターのように、ルールからプロシージャとして既に形成されています。 このプログラムのインターフェースは次のとおりです。







Testfallsatz （テストケースグループ）は、テストするトピック（上から下）の反映です：通貨残高、オーストリアのアカウントの動き、自己管理、宛先コードカテゴリ、CFONB（フランスの標準）。 各トピックには、いくつかのテストケースがあり、その中にはトレーニングブロック（Vorbereitung）、テストステップ、シーケンス、そして最も重要な実行可能プロシージャ自体の呼び出しが含まれます。 以下では、実行時に変数がどのように変化するかを追跡できます。



したがって、この段階でのテスターの主なタスクは、迅速に動作し、エンドユーザーがグラフィカルインターフェイスで使用するメインパスをカバーする実行可能なプロシージャを設計し、合意されたExcelドキュメント/プレゼンテーションに基づいてテストケースを形成することです。 時々、インターフェースをクリックしすぎるか、各手順でこれを行う意味がない場合、スクリプトまたは補助Javaクラスを使用して、たとえば、ユーザーまたは銀行口座をすばやく作成できます。



QF Testの大きな利点は、 Jython （Java + Python）またはGroovyでスクリプトを作成できることです。 個人的には、Pythonが好きなので、Jythonでしか書いていません。Pythonは非常によく似ています。 ちょうど今、KundenPortalは2つの部分で構成されていることに言及します。GUIと、いわゆるWebサービス：シェル。インターフェイスなしで多くのアクションを実行でき、プログラム自体をクリックするよりもはるかに高速です。 以下は、ユーザーがWebサービスで直接作成される上級プログラマーを怒らせないためのスクリプトの一部です。

テストケースの実行、エラーの検索と登録

テストケースの作成と実行は、既製の安定したバージョンが得られるまで同時に行われます。 ここでの安定性とは、テストケースが最後まで自動的に実行され、エラーまたは何らかの技術的な問題によってのみ実行が中断されることを意味します。 エラー管理システムTracに入力されたエラーを見つけました：

バグ後テストと回帰テスト

バトンを渡す前にプログラマーもテストするという事実にもかかわらず、3000以上がすでに発見されていることがわかります。 このような高い数は、主に多くの異なる形式とインターフェイスの十分な複雑さと汎用性によるものです（私が言ったように、それらは同様の原則に基づいて構築されているという事実にもかかわらず）、そしてもちろん、私たちの注意力と腐食性=）ほぼすべてのバグをキャッチします。 私の知る限り、テスト段階で比較的深刻な問題を発見したのは一度だけです。



プログラマーがバグを修正した後、夜間に仕事を辞めるなど、自動テストを再度実行します。 朝にはすでにエラーや問題を分析できます。 また、回帰テストも実行します。つまり、エラーが検出されなかった可能性のある場所を再テストしますが、コードの変更により、バグの出現などプログラムの変更が発生する可能性があります。



最後に、一般的な作業環境を示します。







プロジェクト自体（KundenPortal）とそれが相互作用するBankRechnerは、バージョン管理システム（SVN）を備えたEclipseワークスペースにあります。



a）ヘルパーJavaクラス。 QFテストスクリプトから呼び出される、自分でプログラムを作成します（風水用ではないかもしれませんが、タスクを実行します）。

b）テスト仮想マシンの現在のパラメーター：同時に、1つのKundenPortalと1つのBankRechnerのみが可能です（config）。

c）CSVファイル（右側の例はユーザーのリスト）。ユーザー、顧客、アカウント、支払いテンプレートなどに関する情報（両方のシステムについて）、テストデータ（完全に生成されますが、正しいパラメーターを使用して、または意図的に）陰性検査の場合は間違っている）。

d）テストスイート、実際には、QFテストファイル（テストケースまたは実行手順のコレクション）：共通（特定のバージョンまたはトピック用）および各テスターごとに個別であるため、トピックに冷静に対処し、一般的なテストスイートに過度にコミットすることはありません。

e）たとえば、起動するテストスイート、起動構成、ハードディスクのパーティション分割などを決定するスクリプト



すべてのテストがグリーンゾーンになり、イテレーションが正常に完了した後、合同会議（すべてのプログラマーとテスター）を組織します。そこでは、プロジェクト中に何が良かったのか、何が難しかったのか、一般的な議論が行われます。 各従業員は、少なくとも2つの肯定的な側面と2つの否定的な側面について話す必要があります。 これに基づいて、次の反復のためにワークフローの構築を適合させます。 また、私たちの経験に基づいて、システムとベストプラクティスをセットアップするための基本的な手順を説明する社内ウィキペディアに記入します。







さて、作品の性質についてのいくつかの言葉。



労働時間、人的資源、イテレーションが非常に計画され、配布されているので、開発者と同時にフィニッシュラインに到達することができました（最大1日）。つまり、私たちの側から、グリーンゾーンのすべてのテスト、彼らの側からすべての機能準備が完了し、すべてのバグが修正され、すべてのToDoが作成されました。 最も重要なことは、今回が常に約束されたクライアントと一致したことです。これは、緊急モードが歓迎されないドイツの職場を区別しますが、最初から本物で働かなければなりません。しかし、私はそれが気に入らないとは言えませんが、歴史的には先延ばしにしてから夜寝るのが好きでした。また、ここでそれを処理する人はほとんどいません。週40時間がゴールドスタンダードであり、スケジュールされた会議を除いて、就業時間を自由に選択できます（平均して低ランクの場合は週に1回、管理の場合は週に2回）。私は通常8-9から17-18の範囲で働いています。また、30日間の休暇があります。これは6週間（週末はカウントされません）、1日は引越しの贈り物、2日間は結婚式（無料）、2日間は男性の出産です。会社の従業員の約半分はIT教育を受けており、残りの半分は経済学者、物理学者、数学者です。



あとがきとして、銀行にリリースされた製品を導入することの最終結果は、多くのプロセスの自動化による雇用の大幅な削減にもなります（KundenPortalは、文書化による作業の高速化と多くの日常業務の根絶に重点を置いています）。それで、ドイツ銀行は半年前に1万5千人の従業員の削減を発表した（10万人から）。これにより、このセクターと経済全体の効率が向上します（たとえば、スイスの銀行セクターで働く人の数は、ズベルバンクよりも少なくなります）が、事務員は同情しかできません。