テスト管理プロセス

テスト管理プロセスは、テストの開始からテストの終了までの一連の活動 それはテストに規律を与えます。 テストプロセスに続くときそれは最初に私達に計画を与えます。 テストプロセスはプロジェクト周期中のテストを計画し、制御するために設備を提供する。 これは、プロジェクト全体のテストを追跡し、監視するのに役立ちます。 利害関係者間のテストの透明性を提供し、将来の参照のために実施されたテストを維持します。 実施されているテストの詳細の深いレベルを提供します。 すべての係争物受寄者に前のプロジェクトおよびポストのプロジェクトのテストの活動の明確な理解を与えます。多くのツール（qTest、JIRA、Team Service、TestLinkなどのツール）があります。)テストプロセスを管理するために利用できる。 テストプロセスはテストの必要に従って別様に定義され、練習することができます。 テストプロセスの典型的な活動は次説明されています。

テスト計画は、テストを実行するための最初のスケッチとして機能しました。 テストはテスト計画に従って追跡され、監視されています。 それはソフトウェアのために遂行される面およびテスト挑戦の前の映像を与える。 テスト計画を維持することで、計画の変更を管理することができます。新しいプロジェクトを開始するときは、以前のテストで学んだ教訓に基づいて、改善を得るためにテスト計画を改善する必要があります。 テスト計画は、テストする必要がある特定の要件、範囲、機能および非機能要件、リスクと軽減、テストアプローチ、テストスケジュールと成果物とスケジュール、範囲と仮定、テストチームと割り当て、テスト環境、テストアクティビティメカニズム、およびテストのためのその他の特別な注意事項の概要を説明します。

2) テストデザイン：

テストデザインは、テストを実装する方法を提供します。 通常、テストケースを作成するには、システムの入力と期待される出力を使用し、テストの実行に必要なテストケースを選択します。 テスターは、期待される結果を設定するための明確な理解と適切な知識を持っている必要があります。 これによって、テストの適用範囲は定義され、テスターはシナリオを逃さない。 テスト設計手法には、静的テストと動的テストの2つのタイプがあります。 静的テストは主に文書のような成果物に実行せずにテストするために使用され、動的テストはシステムを実行することによってテストされます。

テストケース（テストケース文書内の要素）:

• プロジェクト/テストタイトル、テスト実行者、テスト実行日、ソフトウェアのバージョン、テスト環境
• テストケース番号
• テスト概要
• ステップ
• プリコンディション
• ポストコンディション
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• テストデータ
• 実際の結果
• 期待される結果
• テスト結果
• 注

3) テスト実行:

実際のシステム結果を期待される結果に対して実行およびテストする方法は、テスト実行です。 テストの実行は、手動で、自動化スーツを使用して行うことができます。 実行中にテスターは、ソフトウェアのユーザーのニーズがソフトウェアで占有されていることを確認する必要があります。 テストの実行は、テスト設計中に作成された文書を段階的なプロセスとして参照することによって行われます。 テスターは、テストケースの実行中に追跡を維持する必要があります。

静的テストの例:

• 要件仕様書をテストします。
• 設計文書のテスト
• ユーザーガイドのテスト

動的テストの例:

• 単体テスト
• 機能テスト
• 統合テスト

4) Exit Criteria:

Exit criteriaテストの実行を停止するタイミングを決定します。 終了基準は、テスト計画フェーズ中に定義され、テスト実行フェーズでマイルストーンとして使用されます。 テスターは最初に終了基準を設定する必要があり、終了基準はプロジェクトの実行中にも変更される可能性があります。 出口の規準を決定する顧客の必要性、システム安定性および満たされた機能のような要因がある。 テスターが終了基準に達すると、テストは停止されます。 以下は、いくつかの一般的な終了基準です。

• すべての重大な欠陥は閉じています。
• すべての報告された欠陥と閉じられ、検証されました。
• が実行され、ユーザーが主に使用していた領域をカバーしました。
• システムはすべての要件を満たしていました。
• すべての重要な機能がテストされ、期待どおりに動作します。

5) テスト報告:

テスト報告は特定のテスト周期のためのテストプロセスそして結果の映像を与えます。 テストレポート内の要素を定義するには、最初に考慮する必要があるのは、テストレポートの対象者が誰であるかです。 たとえば、プロジェクトマネージャーがテストの高レベルの画像を見たいと思う場合、中間の人々はより詳細を表示したいと思うでしょうし、クライアントは、要件ベース、機能ベースなどの基準でテストレポートを期待します。 テストレポートは、毎日、毎週、月などのように定期的に準備され、伝達されます。 これは、さまざまな段階と時間で送信する必要があります。将来的には、テストレポートのプロジェクト結果を分析し、レッスンを学習適用する必要があります。 テストレポートには、テストの実行状況、完了率、実行されたテストケース対計画、テスト環境、リソース別のテスト実行、リスクと緩和がある場合、欠陥の概要、テス

テストカバレッジレポート: （テストカバレッジレポートの要素)

• 完了した割合
• テストシナリオ
• ソフトウェアエリア
• テスト済みリソース
• テスト日
• テスト結果

欠陥要約レポート:(欠陥要約レポートの要素)

• 重大度別の欠陥
• 優先度別の欠陥
• 割り当てられた開発者別の欠陥
• 機能別の欠陥
• ソフトウェア領域別の欠陥
• 開欠陥および閉欠陥

リ: （リスク軽減レポートの要素)

• 特定されたリスク
• 尤度
• リスクレベル
• リスクタイプ
• 緩和計画

結論：

この記事では、テスト管理プロセスについて学びました。出口の規準およびテスト報告。