STLC-テストの実行

テストの実行は、コードを実行し、期待される結果と実際の結果を比較するプロセスです。テスト実行プロセスでは、次の要素を考慮する必要があります-

リスクに基づいて、このサイクルで実行するテストスイートのサブセットを選択します。
各テストスイートのテストケースをテスターに割り当てて実行します。
テストを実行し、バグを報告し、テストステータスを継続的にキャプチャします。
発生したブロッキングの問題を解決します。
ステータスを報告し、割り当てを調整し、計画と優先順位を毎日再検討します。
テストサイクルの結果とステータスを報告します。

テスト実行では、以下の点を考慮する必要があります。

このフェーズでは、QAチームは、準備されたテストケースに基づいてAUTの実際の検証を実行し、段階的な結果を期待される結果と比較します。
このフェーズの開始基準は、テスト計画とテストケース開発フェーズの完了です。テストデータも準備できている必要があります。
テスト環境のセットアップの検証は、テストの実行に正式に入る前に、スモークテストを通じて常に推奨されます。
終了基準には、すべてのテストケースの検証が成功する必要があります。欠陥はクローズまたは延期する必要があります。テストケースの実行と欠陥の要約レポートを準備する必要があります。

テスト実行のためのアクティビティ

このフェーズの目的は、本番/リリースに移る前にAUTをリアルタイムで検証することです。このフェーズからサインオフするために、QAチームはさまざまなタイプのテストを実行して製品の品質を確認します。この欠陥の報告と再テストに加えて、このフェーズでは重要なアクティビティもあります。このフェーズの重要な活動は次のとおりです-

システム統合テスト

製品/ AUTの実際の検証はここから始まります。システム統合テスト（SIT）は、準備された特定の要件/テストケースに対するシステムのコンプライアンスを評価するブラックボックステスト手法です。

システム統合テストは通常、システムのサブセットで実行されます。SITは、テストツールを最小限に使用して実行でき、交換された相互作用について検証され、個々のレイヤー内の各データフィールドの動作も調査されます。統合後、データフローには3つの主要な状態があります-

統合レイヤー内のデータ状態
データベースレイヤー内のデータ状態
アプリケーション層内のデータ状態

Note− SITテストでは、QAチームは品質を確保するためにできるだけ多くの欠陥を見つけようとします。ここでの主な目的は、できるだけ多くのバグを見つけることです。

欠陥報告

期待される結果が実際の結果と一致しない場合、ソフトウェアのバグが発生します。これは、コンピュータープログラムのエラー、欠陥、障害、または障害である可能性があります。ほとんどのバグは、開発者やアーキテクトによるミスやエラーから発生します。

SITテストの実行中に、QAチームはこれらのタイプの欠陥を発見し、関係するチームメンバーに報告する必要があります。メンバーはさらに行動を起こし、欠陥を修正します。レポートのもう1つの利点は、欠陥のステータスの追跡が容易になることです。欠陥の報告と追跡をサポートするALM、QC、JIRA、バージョン1、Bugzillaなどの人気のあるツールが多数あります。

欠陥レポートは、顧客からのフィードバックをテストまたは記録し、クライアントのフィードバックに基づいて欠陥を修正する製品の新しいバージョンを作成することにより、テスト対象のアプリケーションまたは製品の欠陥を見つけるプロセスです。

複雑でビジネスクリティカルなシステムには何百もの欠陥があるため、欠陥追跡もソフトウェアエンジニアリングの重要なプロセスです。最も困難な要因の1つは、これらの欠陥の管理、評価、および優先順位付けです。欠陥の数は一定期間にわたって増加し、それらを効果的に管理するために、欠陥追跡システムを使用して作業を容易にします。

欠陥マッピング

欠陥が報告されてログに記録されたら、関連する失敗/ブロックされたテストケースと、要件トレーサビリティマトリックスの対応する要件にマッピングする必要があります。このマッピングは、DefectReporterによって行われます。適切な欠陥レポートを作成し、製品の欠陥を分析するのに役立ちます。テストケースと要件が欠陥にマッピングされると、利害関係者は、優先度と重大度に基づいて欠陥を修正/延期するかどうかを分析して決定できます。

再テスト

再テストとは、以前に失敗したAUTに対するテストを実行して、問題が解決したかどうかを確認することです。欠陥が修正された後、同じ環境条件下でシナリオをチェックするために再テストが実行されます。

再テスト中、テスターは機能の変更された領域で詳細を探しますが、回帰テストはすべての主要な機能をカバーして、この変更によって機能が壊れていないことを確認します。

回帰試験

すべての欠陥がクローズ、延期、または拒否のステータスになり、テストケースのいずれも進行中/失敗/実行なしのステータスになると、システム統合テストは完全にテストケースと要件に基づいていると言えます。ただし、コードの変更や欠陥の修正によって機能が破損していないことを確認するには、1回のクイックテストが必要です。

回帰テストは、コードの変更によって影響を受けたテストを再実行することで構成されるブラックボックステスト手法です。これらのテストは、ソフトウェア開発ライフサイクル全体を通じて可能な限り頻繁に実行する必要があります。

回帰テストの種類

Final Regression Tests−「最終回帰テスト」は、一定期間変更されていないビルドを検証するために実行されます。このビルドは、展開または顧客に出荷されます。
Regression Tests −通常の回帰テストを実行して、欠陥修正または拡張のための最近のコード変更によって、ビルドがアプリケーションの他の部分を破壊していないかどうかを確認します。

アクティビティブロック図

次のブロック図は、このフェーズで実行される重要なアクティビティを示しています。また、前のフェーズからの依存関係も示しています-