ソフトウェア テストにおけるワークフロー テストとは? 例付き
トーマス・ハミルトン
⚡ スマートサマリー
ワークフローテストは、アプリケーション内のあらゆる手順が、それが構築されたビジネスプロセスを反映していることを確認するもので、最初のアクションから最終結果までの各段階、引き継ぎ、依存関係をチェックします。
ワークフローテストとは何ですか?
ワークフローテスト ワークフローテストとは、各ソフトウェアワークフローが与えられたビジネスプロセスを正確に反映しているかどうかを確認するソフトウェアテストの一種です。ワークフローとは、望ましい結果を生み出す一連のタスクであり、通常は複数の段階またはステップで構成されます。あらゆるビジネスプロセスにおいて、これらの連続したステップをテストすることをワークフローテストと呼びます。
重要なのは範囲の違いです。 テストケース ある関数が正しい答えを返すかどうかを問う。ワークフロー テストでは、実際のユーザーが実行する順序で実行された 10 個の関数が、ビジネスが期待する結果をもたらすかどうかを問う。そのため、ワークフロー テストはプロセス指向の項目に分類される。 ソフトウェアテストの種類 ユニットレベルの手法ではなく、カタログ方式を用いる。
ワークフローテストの例
例えば、システムがユーザーのプラットフォームにインストール可能であり、正しく動作することを確認してください。
より具体的な例として、オンライン注文が挙げられます。顧客は商品をカートに追加し、割引コードを適用し、配送オプションを選択し、支払いを行い、確認メールを受け取ります。一方、倉庫にはピッキング指示が送信されます。これらの各ステップは個別に成功しても、一連の流れとして失敗する可能性があります。例えば、割引が支払いステップで適用されなかったり、倉庫へのメッセージがキューから送信されなかったりする場合があります。
ワークフローテストは段階的に実施されます。以下にワークフローテストの実施方法を説明します。
- 開始フェーズこのフェーズには、初期テスト計画とプロトタイプテストが含まれます。
- 詳細化フェーズこのフェーズには、テストアーキテクチャのベースライン設定が含まれます。
- 建設段階このフェーズでは、各ビルドにおいて重要なテストが実施されます。
- 移行段階このフェーズには以下が含まれます 回帰テスト そして修正内容を再テストする。
ワークフローテストの実施方法
上記のフェーズモデルは、作業が行われるタイミングを示しています。以下のシーケンスは、テスターが各フェーズ内で実際に行う作業内容を示しています。
- ビジネスプロセスをマッピングする。 ビジネスが実際に行っているワークフローを正確に描きます。すべての意思決定ポイント、承認、部門間の引き継ぎを含めます。ビジネスアナリストは通常、正確なマップを作成するための最速の手段であり、 ビジネスアナリスト ドキュメントは、地図の検証に使用される参照資料です。
- 入退出基準を設定する。 ワークフロー開始前にシステムが満たすべき状態と、ワークフローが完了したことを証明する状態を記録してください。この両方がないと、テスト担当者間で実行が成功したかどうかの判断が分かれてしまいます。
- テストケースを設計する。 ワークフローの各パスごとにケースを記述し、画面ごとに記述しないでください。手順に番号を付け、それぞれの期待される結果を記述し、欠陥を特定できるように各ケースに一意の識別子を付けてください。 trac元の道に戻った。
- 現実的なテストデータを準備する。 架空の値ではなく、匿名化された生産形式のレコードを再利用しましょう。割引コード、税制規則、住所フォーマットなどは、合成データが実際の欠陥を隠蔽する典型的な例です。
- まずプライマリパスを実行してください。 意図的に何らかの操作を中断する前に、ワークフローが最初から最後まで正常に完了することを確認してください。ここで失敗すると、その後に発生するすべての否定的な結果が無効になります。
- 意図的に連鎖を断ち切る。 途中でキャンセルしたり、判断ポイントで無効な値を送信したり、セッションをタイムアウトさせたり、承認を拒否したりする。興味深い欠陥は、主要な経路ではなく、こうした中断された経路に潜んでいる。
- 報告、修正、再テスト。 各不具合は、その不具合が発生したステップに紐づけて記録し、修正後にワークフロー全体を再実行してください。修正されたステップによって、不具合の発生箇所がチェーンのさらに下流の段階に移動することがよく起こります。
リリースごとに繰り返される安定したワークフローは、自動化に最も適した候補です。なぜなら、同じ手順が毎回同じように実行され、スクリプトは数回のサイクルで費用対効果を発揮するからです。
ワークフロー テストを実行するのは誰ですか?
ワークフローのテストは、単一の担当者がプロセス全体を把握できないため、共同作業となります。4つの担当者がそれぞれ責任を負いながら、テストの負担を分担します。
- テストエンジニア
- テストの目標とスケジュールを計画する
- テストケースと手順を定義する
- テスト結果を評価する
- コンポーネントエンジニア
- テストコンポーネントの開発
- テスト手順の一部を自動化する
- 統合テスター
- パフォーミング 統合テスト 欠陥の報告
- システムテスター
- パフォーミング システムテスト 欠陥の報告
ワークフローでテストする内容
ソフトウェアのワークフローはビジネス要件定義書に記載されており、その文書がカバレッジに関する信頼できる情報源となります。ワークフローのテストには、システムテストおよび統合テストの一部も含まれます。
ワークフロー全体を徹底的に検証するとは、ユーザーが見る画面だけでなく、それ以上のものを検証することです。
- シーケンス： 手順は文書に記載された順序で実行され、手順を省略したり、順番を間違えて繰り返したりすることはできません。
- データ引き渡し: チェーンの初期段階で入力された値は、最終段階および下流のシステムまでそのまま保持されます。
- 役割と権限: 各ステップは、その実行を許可された役割を持つユーザーのみが利用できます。
- 中断された経路: キャンセル、タイムアウト、拒否、再試行はすべて、ワークフローを定義された状態にします。
- アーティファクト： ワークフローテストモデルは、テストケース、テスト手順、テストコンポーネント、テストサブシステムを網羅しており、これらのそれぞれが順番に検証されます。
- 通知： メール、アラート、キューメッセージは、正しい内容で、正しいステップで一度だけ送信されます。
ワークフローテスト、エンドツーエンドテスト、システムテスト
これら3つの手法は重複する部分が多く混同されやすいものの、それぞれ異なる問いに答えるものである。表はそれらの境界を明確に示している。
| 側面 | ワークフローテスト | エンドツーエンドのテスト | システムテスト |
| 質問への回答 | そのソフトウェアは業務プロセスに合致しているか？ | この一連のプロセスは、接続されているすべてのシステムで正常に機能しますか？ | 組み立てられたシステムは、その要件を満たしていますか？ |
| 補償単位 | 1つのビジネスプロセスを段階的に | フロントエンドからバックエンドまでの単一のユーザー体験 | 完全なアプリケーションビルド |
| 主な参考文献 | ビジネス要件ドキュメント | ユーザー体験マップ | システム要件仕様 |
| 典型的なオーナー | ビジネスアナリストの意見を取り入れたテストエンジニア | 自動化エンジニアまたは品質保証エンジニア | システムテスター |
実際にはワークフロー テストは仕様であり、 エンドツーエンドテスト は、 システムテスト ワークフローが実行される安定したビルドを提供する。
ベストプラクティスと共通の課題
ワークフローテストから価値を得ているチームは、概して同じような少数の習慣に従っている。
- 収益リスクや規制リスクを伴うワークフローを、発生頻度の低いワークフローよりも優先的に処理する。
- すべての手順と期待される結果を、平易で明確な言葉で説明してください。
- 再利用可能で現実的なテストデータセットを保持することで、異なる環境間でも実行結果を比較可能にする。
- 各ワークフローについて、有効な入力と無効な入力の両方を用いて、各判断ポイントでテストしてください。
- 基となる業務プロセスに変更があった場合は、直ちにテストケースを更新してください。
繰り返し発生する障害は、どれも同じように予測可能だ。
- 文書化されていないプロセス： ワークフローは人々の頭の中に存在するため、テスターは前提に基づいて検証を行っていることになる。
- 実行時間が長い： 承認プロセスを含むワークフローは数時間かかる場合があり、そのため手動で実行できる頻度が制限される。
- 環境ドリフト: サプライチェーンの下流システムは機能不全に陥っていたり、古くなっていたりするため、欠陥は本番環境になって初めて顕在化する。
- 脆い自動化： 画面レイアウトに関連付けられたスクリプトは、処理自体が変更されていない場合でも、インターフェースが変更されると必ず動作しなくなる。
- データ衝突: 並列実行では同じレコードが消費されるため、製品の欠陥のように見える障害が発生する。
