テスト計画を作成する

完了

デプロイ計画では、さまざまなテストについて検討する必要があります。 これらの各テストは、明確に文書化されたプロセスに従って、非公式または公式に実施することができます。 デプロイによって、テストに求められることは少しずつ異なります。 テストによって、手動で行うもの (ユーザー受け入れテスト) と自動で行えるもの (ロード テスト) があります。

単体テスト: これはテストの最小のコンポーネントであり、1 つの測定単位です。 多くの場合、これは開発者の仕事と考えられています。 ただし、プロジェクトに関わる全員が自分の作業にこれを含める必要があります。 単体テストの例として、フォームに計算列を追加する要件がある場合などがあります。 このタスクをテスト チームに依頼する前には、想定どおりにフォームに列が追加されていることを確認し、想定どおりに計算が実行されることをテストします。

品質保証テスト: QA とも呼ばれます。これは、作業が期待どおりに行われているかどうかを第三者が確認して、タスクをテストすることを指します。 多くの場合、最小のコンポーネント (上記の単体テストのものなど) のテストや、ユーザー エクスペリエンス全体のテストが実施されます。

パフォーマンス テスト (ロード テストとも呼ばれます): 設定可能なものには、システムのパフォーマンスに影響を与えるものが多くあります。 たとえば、同時ユーザーの数が期待されているパフォーマンス (負荷) に影響する場合があります。これは、それらのユーザーの操作の組み合わせが原因の場合があります。また、個々のユーザーで、サブグリッドが多すぎるフォームの読み込みが遅いなどの問題が発生する場合もあります。 他のシステムとの統合もパフォーマンスに影響を与える場合があります。 パフォーマンス テストやロード テストは、ほとんどの場合、外部のツールを使用して実施します。

統合テスト: 統合したシステムが想定どおりに動作するかどうかを確認します。 また、不要な依存関係が生じていないかを確認します。

ユーザー受け入れテスト: これは、構築中のシステムの実際のユーザーから直接フィードバックを受け取る機会です。 ユーザー受け入れテストでは、構築したシステムがユーザーの求めるシステムであることを確認します。

使用するテストの正確な種類や計画にかかわらず、以下の点を考慮する必要があります。

単位テスト、ユーザー受け入れテスト、統合テスト、パフォーマンス テスト、QA テストなどのテストの種類の図。

テスト計画の使用

テスト計画は、テストの対象と対象外の項目を定め、合格に必要な考慮事項を伝達するためのプロジェクト計画の適用範囲を示した重要な文書です。 テスト計画は、ユーザー受け入れテストの前にバグを見つけるために技術リソースが実施するように設計します。

テスト計画では、少なくともプロジェクトの各ビジネス要件をテストする方法を示す必要があります。 それによって、各要件に対応および適合していることを示す機会を設けます。 テスト計画は、将来問題が発生した場合に、テスト時の理解に基づいて何がテストされたか、何が元の適用範囲から漏れていたかを知るための参考資料として役立ちます。 テスト計画では、実施するテストの詳細のレベルと、見つかった問題を解決して再テストするためのプロセスを定義する必要があります。

環境

テスト計画の要件によって、テストを正しく実施するために必要な環境が決まります。 テスト環境は、できるだけ運用環境の技術的な設定に近づける必要があります。 アプリケーションがデスクトップ、モバイル、オフラインなどの複数の形式で提供される場合は、それらのすべての環境でテストを行う必要があります。

テスト時に必要な環境が用意できない場合があります。 関係者は、その必要性と依存関係を認識し、それがどのように期限に影響するかを知ることが重要です。

セキュリティ

テスト計画の作成では、アプリケーションを使用するすべてのユーザーのペルソナを考慮し、適切なセキュリティ ロールからテストすることが重要です。 セキュリティに関する一般的な考慮事項には、関連するセキュリティ ロールの特定、列セキュリティ プロファイル、部署のメンバーシップ、チームのメンバーシップなどがあります。 テスト担当者の認証方法は、運用環境のユーザーと同じである必要があります。 たとえば、ユーザーが VPN を使用してアプリケーションにアクセスする場合は、VPN を使用してテストを行う必要があります。

依存関係

ルックアップ テーブルを作成するために必要な子行など、データの依存関係を考慮します。 テスト中に必要なデータが判明した場合は、必ずそれをメモして、ユーザー受け入れテストと運用環境へのロールアウト時にユーザーがそのデータを使用できるようにします。

特定のアカウントやカスタムの子列など、特定の列を参照するカスタマイズに注意してください。 ワークフローやビジネス ルールなどのカスタマイズが特定の列に依存している場合は、その列を移行して両方の環境で GUID が同じにする必要があります。 データ インポート ウィザードを使用すると、新しい環境に別の GUID でデータがレプリケートされます。

ソリューションの確認

Word や Excel のテンプレートなど、いくつかの設定は環境間で移動させることができないため、それぞれの環境で設定する必要があります。 それぞれの環境で完了する必要がある設定については、テスト時に特に注意する必要があります。

リソース

コンポーネントのテストでは、そのコンポーネントを作成または設定していないリソースを使用することがベスト プラクティスです。

計画、環境、セキュリティ、依存関係、設定などのテストの考慮事項の図。

テスト計画の構成要素

以下に、テスト計画の一般的な構成要素を示します。

  • 環境の要件

  • テストする機能

  • テストしない機能

  • テスト項目

    • 関連するビジネス要件

    • テストの手順

    • 期待される結果

    • 項目の合格/不合格

    • テストの日時

    • テスト担当者の氏名

    • テストに関する注意事項

  • テストのスケジュール

    • 依存関係

    • タイムライン

    • スケジュールに関するリスク

  • 不合格のテスト項目を修正して再テストするためのプロセス

適切なテスト計画は、テストの目的と適用範囲を説明し、技術的なレビューのプロセスを示し、機能の円滑なロールアウトを支援します。 テスト計画は、ユーザー受け入れテストへと続くものであり、ロールアウトの前に必要な変更を追跡する方法を備えている必要があります。