テストへの参加
テストは、要件を機能にマッピングするプロセス以上の役割を果たします。 これらのタイプのテストをビルドして実行することは重要ですが、ソリューションには他にもテストが必要な多くの側面があります。 テストで使用される測定基準を問わずプロセスはかなり似ています。
通常、テスト プロセスは次のようなフローで行われます。
- 計画。 全体的なテスト戦略を確認します。 テスト計画を作成します。 基準メトリックに対して必要な分析を実行します。 スコープの内外にある主要な業務シナリオを特定します。 要件を文書化していない場合は、文書化します。
- 準備。 必要な環境、パフォーマンス テスト、ユーザーの権限テストなどを設定します。移行テストの前後に、移行のために受信したデータを確認します。 高レベルのシステム要件を検証します。 必要なスクリプトを作成します。
- 実行。 テスト スクリプトを実行します。 結果を分析し、潜在的なボトルネックを特定します。 障害と動作を確認します。
- レポート。 レポート計画、結果、アクション プランの詳細な評価を準備します。
数種類のテスト
一般に、業務コンサルタントは、これらのテスト タイプごとにある程度の能力を備えているのが一般的です。 それぞれが、結果を左右する可能性があり、業務コンサルタントの幅広いスキルは、品質チームが成功するための大きなリソースとなります。
テスト タイプ
説明
単体テスト
これらのテストは、資産は実装プロセスを通じて構築される中で、アプリ ビルダーまたはコード開発者が実行します。 これらの単体テストは、機能を実際に構築している人が実行する必要があります。これには、開発者、業務コンサルタント、ビジネス アナリストなどが含まれます。
機能テスト/システム テスト
これらのテストでは、実装が要件を満たしており、欠陥がないことを確認します。 機能テストは、顧客またはパートナー チームのリソースによって手動で実行することも、自動化することもできます。
承認テスト
これらのテストは、エンド ユーザーが正式な承認を得るために実行し、システムの使いやすさをテストします。 通常、承認テストは、機能をロールアウトする前の最終チェックとして実行します。 初期の展開では、このテストはプロジェクトの終了時に実施されますが、アジャイルな反復展開では機能が各スプリントでリリースされる場合があるため、プロジェクト全体を通じて承認テストを実施する必要があります。 このテストは、一般的に UAT (ユーザー受け入れテスト) と呼ばれます。
回帰テスト
このテストでは、変更されていない機能が引き続き正常に機能するかどうかを評価します。通常は、システムが更新されたときに実行されます。 顧客は、現在の構成が更新後に最適に機能することを確認するために、主要なプラットフォームの更新 (年 2 回) 前に回帰テストを計画する必要があります。 回帰テストは自動化できます。
統合テスト
目標は、すべての統合システムが連携してうまく機能することを確認することです。 統合テストでは、統合されたサードパーティのサービスやデータを含めて、すべてがうまく連携していることを検証します。 このテストは、統合の初期開発後に実施されます。
パフォーマンス テスト
このテストでは、予想されるピーク時の負荷とピーク時のトランザクション ボリュームを使用してシステムのパフォーマンスを確認します。通常は、Go-live 実施前、または多数のシステム ユーザーのグループを追加でオンボードする前に、自動化して実行します。
データ検証テスト
このテストは、データ品質を維持するためにデータの移行を検証します。通常は、顧客データについて把握している対象分野の専門家と密接に協力して、統合を構築した担当者または顧客のリソースがテストを実施します。 これらの専門家には、データの移行と変換について理解し、移行したデータが適切なコンテキストで有効であることを確認できることが求められます。 このプロセスには、行数などの標準のチェックや、列が正しくマップされていることを確認するための、移行されたデータのサブセットのスポットチェックなどが含まれます。 このプロセスは、データ移行テストと呼ばれることもあります。
ディザスター リカバリー テスト
このテストでは、障害によってシステムがダウンした場合の動作を確認します。 重大なディザスター リカバリーは Microsoft が対処しますが、障害発生後に業務を再開するための計画を用意しておく必要があります。 たとえば、ソース コードが最新の状態であることを確認することで、障害発生時には、開発環境を正常に再作成できます。
Go-live テスト
このテストは完全な Go-live プロセスの予行演習を含んでおり、通常は Go-live 前に実行します。
テストにおける業務コンサルタントのロール
実際のテスト プロセスへの参加に加え、テスト計画の作成や、少なくともそれらの確認への準備が必要です。 このプロセスでは、プロジェクトのライフサイクルの最初から最後まで、期待値が一致していることを確認することで、ジョブをより良いものにできます。 また、システムを構築・設定している自身のアクションによりテストプランを検証することで、品質管理チームの役に立ちます。
記載されているテストのいずれかに関わることもありますが、業務コンサルタントは以下のようなことに関わることが多いでしょう。
機能テスト
機能テストの目標は、ソリューションの品質評価を得るためにテスト チームが使用する一連のユーザー チャンピオンとテスト ケース シナリオについて、顧客が戦略を明確にしていることを確認することです。
機能テストの重要な部分は、Go-live 前と Go-live 後の両方で引き続き導入される変更により、変更されていない部分が継続して機能することを確認することです。 完全な機能テストのスイートのうち、各リリースまたは更新について、定期的に実行する回帰テストのサブセットを特定する必要があります。
統合テスト
正しく機能するビジネス プロセスの実装の最も重要な要素であり、全体的な導入に大きな影響を及ぼします。 顧客は、システムに統合されている他のアプリケーションの所有者とやり取りすることを計画する必要があります。 このテストによって、必要に応じて問題を修正したり、変更を加えたりするための明確なロールと責任を定義することも求められます。
各統合には、定義が必要な独自のテスト アプローチが存在する可能性があります。 テスト チームは、各統合シナリオをテストする方法について、早期の段階から検討する必要があります。 チームは、テストをサポートするように、必要な統合を構成できることを確認する必要があります。
統合テストの重要な側面は、統合に出入りするデータに焦点を絞ることです。 データ検証テストのセクションの説明の多くは、統合に関与するデータにも適用できます。
ユーザー受け入れテスト
ユーザー受け入れテストは、Go-live 後の新システムの受け入れと同様、Go-live の承認を得るために重要です。 また、Go-live 後の機能強化の一環として計画できる機能に関する要望のバックログを提供する場合もあります。
顧客は、ユーザー チャンピオン、つまり重要なユーザーを初期の段階で特定し、プロジェクトのライフサイクル全体でこれらのユーザーの関与を維持する必要があります。 顧客はこのようなグループに加えてユーザー コミュニティとも協力してアプリケーションをテストする必要があります。 この定義は、Go-live を行うかどうかの意思決定にロールアップされるため、適切なユーザー承認基準のテスト戦略を明確に定義する必要があります。