リスクベースのテスト

医学、保険、銀行などの業界で情報製品の品質を確保するには、他のテスト方法とともに、リスクベースのテストを使用することが重要です。 検証のために、作成されるソフトウェアの最も危険な領域が選択されます。 これにより、ネガティブなシナリオを予測し、顧客のビジネス目標を成功裏に実施できます。



この記事では、SimbirSoftでどのようにリスクを処理したか（インターネット取得システムや他のプロジェクトを例に使用）、および顧客プロジェクトで使用するリスク評価と管理の方法について説明します。

プロジェクト開始時のリスク

はじめに、銀行セクター向けの開発における実践の例を示します。



顧客の提案：個人向けの銀行のWebバージョンに焦点を合わせる。



確認したリスク：モバイルクライアントバンクとは対照的に、個人向けのWebバージョンの需要が低いために視聴者が失われる可能性があります。



私たちの議論：モバイル版とウェブ版による視聴者のレビューと分布に基づくユーザー設定の統計。



結論：携帯電話は常に手元にあるため、個人にとってはモバイル版の方が便利です。 操作は高速で、認証システムにより便利なすべてのサービスにアクセスできます。 この場合、最も一般的な機能の限られたセットへの迅速なアクセスが重要です。



法人にとって、提供される機能の完全性、大量の情報をアップロード、印刷、および操作する能力が重要です。 このため、Webバージョンの方が便利です。



私たちのソリューション：個人向けのモバイルクライアントバンクに集中すること。

プロジェクトの作業の開始時に、テスト戦略を正しく選択することが重要です。 それが重要である理由とその選択方法の例を見てみましょう。

テスト戦略はビジネス目標を満たす必要があります

遅かれ早かれ、すべての企業はテストプロセスを整理する必要に直面し、その戦略の構築がソフトウェア開発の重要な段階であることを理解するようになります。 時々-自分の苦い経験を​​通して。 大規模プロジェクトの開発におけるテストと戦略選択の役割を過小評価することは特に危険です。 テストプロセスは、プロジェクトのビジネス目標と詳細に従って選択する必要があります。そうしないと、1か月または1年で肯定的な結果が得られません。



たとえば、銀行のモバイルおよびWebアプリケーションのテストを検討してください。 プロジェクトの開始時に、詳細レベルの低い要件に基づいた戦略を選択しました。 チェックリストを使用して、テスト時間を短縮し、テストベースをサポートしました。 機能の成長、取得、SMS承認、通知の追加、より複雑なシステムにより、チェックリストはタスクに対応できなくなりました。 時間が経つにつれて、ますます多くのQAスペシャリストがチームに加わり、情報を送信し、行動を調整する必要がありました。 製品の複雑さにより、変更は関連する機能に影響する可能性があります。つまり、回帰のリスクが増加します。 回帰テストの自動化の必要性が高まっていたため、テストケースに切り替えました。



結論：プロジェクト、その仕様または開発段階に応じて、テスト戦略が変わります。



最高品質の製品を確保するには、プロジェクトの目標に合わせて戦略を選択する必要があります。 彼女は、「何」、「どこ」、「いつ」をテストするのかという質問に答えます。 戦略に応じて、いつでもどこにいるか、将来どこに来るかを知っています。



ビジネス目標は、顧客データのセキュリティと、生産段階のソフトウェア自体を確保することです。 セキュリティは開発プロセスから始まり、テスト段階まで続きます。



たとえば、プロジェクトの1つで、開発およびテスト用の安全な環境を作成し、すべての要件を満たし、データの保護に役立つインフラストラクチャを展開しました。 各QAスペシャリストがテストインフラストラクチャにアクセスするために、認定トークンと名前ベースのフラッシュドライブをリクエストしました。 したがって、ソフトウェアセキュリティにおけるプロジェクトのビジネス目標を確保し、クライアントデータとユーザーデータの機密を保持しました。



テスト戦略により、特定のプロジェクトにとって本当に重要な側面に重点を置くことができます。 モバイルゲームや複雑な銀行のCRMシステムをリリースするには、さまざまなテスト方法が必要なのは当然です。

銀行のテスト戦略

SimbirSoftの業務では、あらゆる開発手法を使用しましたが、柔軟性のある技術は常に優先事項です。 また、いくつかの理由でそれらを使用できない場合でも、チームはベストプラクティスを採用し、日常業務に適用します。 テストはプロセス全体の有機的な部分になり、ワークフロー全体に統合されます。 この場合、製品の品質だけでなく、作業プロセス全体の品質にも責任があります。



使用するテクノロジー：

• 内部リリースの柔軟な計画と準備。
• ユーザーストーリーの準備;
• 集会の開催。
• 回顧を行う。

完全な力で、テスト戦略は複雑なビジネスロジックを持つプロジェクトで明らかになります。 たとえば、銀行の情報サポート用ソフトウェア、インターネット取得システムの構築、自動取引プラットフォーム。 このようなプロジェクトでは、適切なテスト戦略を適用することが重要です。エラーの価格が実際の損失につながり、企業の評判に大きな影響を与える可能性があるためです。



また、テストの主な目的-欠陥検索とコンプライアンスのためのソフトウェア検証-が追加される場合があります。 たとえば、銀行にとって中央銀行の新しい要件を迅速に実装することが重要です。 これは、重要なタスクに必要な品質のタイムリーなテストが主な目標に追加されることを意味します。



最近、銀行プロジェクトで、連邦法の変更に直面しました-VAT率が18％から20％に増加しました。 法律の変更に適応するために、フォーム、インターフェイスの置換だけでなく、いくつかの計算式のロジックの変更も含まれるため、多くの予備作業が行われました。 多くのプラットフォームで正しい表示を確保する必要がありました。 また、繰延支払機能では、18％および20％の率の移行期間を考慮する必要がありました。



次に、戦略を構築する方法と、リスクベースのテストを頻繁に選択する理由について詳しく説明します。

リスクベースのテストの長所

特定の目的のために選択されたいくつかのテスト戦略があります。

• 要件に基づいて;
• 系統的;
• リアクティブ戦略;
• アドバイザリー戦略。

複雑なビジネスロジックを持つプロジェクトを扱う場合、テストのベースとなるシステムの設計で厳しい要件を決定する必要があります。 適切なツールは、要件ベースのテストです。



要件ベースの戦略の1つのタイプは、リスクベースのテストです。 さらに、最もリスクにさらされるシステムの機能の部分が最初にテストされます。 リスクは、システムの誤動作によるマイナスの可能性のある結果です。 結果は、機会と否定性などの2つの要素が存在する場合のリスクです。



リスクには2つのタイプがあります。



1.製品リスク



管理および非管理が可能です。 上記の例では、管理可能なリスクに直面しました：機能の急速な成長と複雑さ、それに関連して回帰の確率が増加しました。 ここでは、理解しやすいテストベースとその後の自動化によって問題を解決しました。 影響を与えられないリスクは、外部システムへの依存と、統合プロセスでのそれらの障害です。 ここでは、システムへの影響を減らすための対策を示します。 たとえば、バックアップの使用、例外的なケースの処理、ユーザーへの警告の表示。



2.プロジェクトのリスク



たとえば、プロジェクトで、顧客が以前に分散チームと働いていなかったという事実に直面したため、使用されたワークフローが要件を満たさず、追加のコミュニケーションの問題を作成しました：理解不足、タスクの重複、相互に排他的なタスクのパフォーマンスなど。 プロセスの再構築と改善に同意しました。ワークフローを修正し、すべてのチームメンバーを紹介し、集会、プレゼンテーション、回顧展を開催しました。 その結果、作業は正しい方向に進みました。



リスクベースのアプローチにより、特定の数のリスクを短時間で構成して、優先度の高いリスクをテストし、テストおよびテストされたケースに関するメトリックを顧客に提供して、計画および完了したケースの数と欠陥の数を表示できます。



プロジェクトでのリスクベースのアプローチの実装は、4つの段階で行われます。



リスクの特定 -この段階では、リスクを特定し、それらのリストを取得する必要があります。

リスク評価 -ここではリストを分析し、優先度別に分類します。

リスクの軽減 -この段階で、リスクをどの程度深くテストするかを決定します。

リスク管理 -ここで、彼らとどのように働き続け、それらを通り抜け、新しいリスクを特定するかを決定します。



リスクは、ブレインストーミングセッション中に利害関係者のグループによって特定され、評価されます。 チームには、顧客、開発者、マネージャーまたはプロジェクトマネージャー、アーキテクト、QAスペシャリストからのシステムに関するビジネスアナリストまたは知識のキャリアを含める必要があります。 情報セキュリティの専門家、現在のシステムを直接操作する従業員、リスクを特定して評価するプロセスに没頭しているビジネスアナリストが関与しています。



インターネット取得システムのテストの例によるリスクベースのアプローチを検討してください。

リスクを扱う（インターネット取得システムの例）

次の要件を特定します。

D1。1秒あたり1000のシステムへの同時接続を提供します。

D2。 トランザクションセキュリティ。

D3。 トランザクションへのアクセスは、トランザクションを行う人のみが利用できるようにする必要があります。

D4。 SET（Secure Electronic Transaction）標準の提供とサポート。



製品リスクとして、以下を区別できます。

RP1。 同時接続によるシステムクラッシュ。

RP2。 トランザクション中のSQLインジェクションの使用。

RP3。 URLのパラメーターを変更する際の、他の誰かのトランザクションへのアクセス。

RP4。 トランザクション時に銀行との接続が失われた場合のデータの損失。

RP5。 SET（Secure Electronic Transaction）システムを提供する際の無効な証明書の使用。



組織的なリスクとして：

RO1。 外部システムのアクセス不能による開発システムの崩壊。

RO2。 テスト環境では検出できない再現困難なケースの存在。



したがって、各リスクは論理的にはシステム内の要件に基づいていますが、それに限定されるわけではありません。 リスクは要件を補完し、システムを操作するときに発生する可能性がある追加のケースを識別します。



プロジェクトの目的とシステム要件に応じて、リスクを軽減または補償できます。 リスクが少なくとも1回はテストケースでカバーされていることが認められます。



1.製品リスクごとに 、各要件と各リスクを少なくとも1つのテストケースでカバーするという条件で、テストケースRP1〜RP4のセットを準備します。 テストの目的に応じて、テストケースのセットは特定の詳細レベルに拡張されます。



2.組織のリスクごとに、開発中の製品に対するリスクの影響を軽減できる対策のリストが用意されています。

リスク評価と管理手法

リスクの評価と管理には、軽量の方法（PRAM、PRISMA）とより正式な方法（FMEA、FTA）のいくつかの方法があります。



FMEAモデルを使用して、プロジェクトチームは、システムのすべてのプロセス、コンポーネント、システムのモジュールを特定します。システムの障害またはエラーは、製品品質の低下につながる可能性があります。 ブレインストーミング中、システムのリスクは、重大度、優先度、確率の3つの指標によって決定されます。 次に、リスクごとにリスク優先度が計算され、指標に応じてテストの深さが設定されます。



FTAモデルでは、システムのビジネスプロセスに欠陥をもたらす可能性のあるすべての理由が段階的に決定されます。 分析は、最高レベルから最低レベルに進みます。 FMEAとFTAの違いは、最初のアプローチではシステムの機能に焦点を当て、2番目のアプローチではビジネスプロセスに焦点を当てることです。



これらの形式的で重いアプローチに加えて、より柔軟で非公式なアプローチがあります。 たとえば、PRAM（Pragmatic Analysis and Risk Management）およびPRISMA（Product Risk Management）メソッド。 リスクと要件に基づいて戦略をうまくかつ簡単に組み合わせます。 基本的に、これらのアプローチは入力として要件仕様を使用しますが、利害関係者も関与できます。



軽量のリスク分析方法は、正式な方法と非常によく似ています。 それらは技術的または商業的リスクに焦点を合わせ、リスクの発生確率とこの確率に影響する要因を評価します。



ただし、これらの方法で使用される2つの要素は、リスクの可能性とその影響のみです。 さらに、これらのアプローチでは、簡素化された定性的判断とスケールを使用して意思決定を行います。



私たちのチームは、柔軟で軽量な方法を使用し、PRAMとPRISMAのアプローチを彼らの目標に適合させます。

リスクベースのテストの使用方法

たとえば、プロジェクトの1つで、機能する可能性のあるプロジェクトおよび製品のリスクを特定します。 これを行うために、分析にはアナリスト、開発者、およびQA（チームの代表者1人）が関与します。



製品でリスク表が形成されます。 それらは、リスクが発生する確率の評価と、システムへの潜在的な影響を5段階で評価します。 表1-最も強い影響力、5-最も弱い影響力。 また、確率1-高確率、5-低確率。

製品リスクへの取り組みを継続する方法

さらに、それらのそれぞれについて、テストケースによる製品リスクカバレッジのトレースが発生します。



次のチェックを選択します。



TC1。 システムへの1000を超える接続による負荷チェック

TC2。 1000システム接続の負荷テスト

TC3。 トランザクション中にSQLインジェクションを入力します

TC4。 他のデータを代用して、成功したトランザクションページでSQLインジェクションを入力します

TC5。 トランザクションの作成時に入力可能なフィールドにXSS（クロスサイトスクリプティング）スクリプトを入力する

TC6。 トランザクション中の切断されたインターネット接続のシミュレーション

TC7。 検証ステップでトランザクションセッションを終了する

TC8。 トランザクション中の期限切れの証明書の検証







したがって、優先度チェックはTC2、TC4、TC5です。



TC6とTC8の影響は大きいものの、可能性は低いため、チェックの優先順位は低くなりますが、チェックも必要です。



TC7は、どの要件にも適用されませんが、システムの安定した動作で可能になる否定的なシナリオのテストを拡張します。

プロジェクトリスクをどのように処理し続けるか

また、プロジェクトリスクに対するアクションも決定します。これにより、追加の手段と決定を割り当てます。



リスク「RO2。 テスト環境で検出できない再現困難なケースの存在 ''、次のことができます：

• すべての外部システムと組み合わせて、実際のアプリケーション環境にできるだけ近い運用前スタンドを準備します。
• すべての隣接システムを通過し、トランザクション検証を提供するエンドツーエンドのテストスクリプトを記述します。
• すべての優先度チェックを行った後、システムの基本要件にエラー推測技術を使用し、「システムクラッカー」の役割の追加チェックにスクリプトを使用します。

緊急計画

製品またはプロジェクトのいずれかが機能する場合に備えて、アクションプランを作成することが重要です。 場合によっては、プロジェクトのバックアップシステムの設定を保存できます。 リスクを最小限に抑えることは常に可能とは限りませんが、少なくともその結果を減らすことは可能です。 記事「クリスマスストーリー」はこのトピックに関するものでした。リスクがどのように機能するか、その確率はゼロになる傾向があります。



たとえば、トランザクション中のデータ損失を完全に排除する必要がありますが、すべてのケースが面倒すぎると考えてください。 したがって、このような場合に対処する方法が必要です。 セキュリティのオプションの1つは、より詳細なロギングの開発です。 これにより、トランザクション中に問題が発生した場合に、前のアクションへの永続的なロールバックポイントが提供されます。

おわりに

リスクベースのテストを使用すると、最もリスクの高い領域をテストケースでカバーできるため、その影響とトリガーされる可能性を減らすことができます。 これは、複雑なビジネスロジックと高いエラーコストを伴うシステムにとって最も成功する戦略です。 このソリューションは、銀行セクター、保険会社、医療プロファイルの複雑な内部CRMシステムに適しています。 リスクベースのアプローチにより、プロジェクトリスクも処理します。これにより、テストおよびプロジェクト管理の全体的なプロセスが改善されます。