STLC-テスト実行

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

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

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

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

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

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

システム統合テスト

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

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

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

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

欠陥報告

予想される結果が実際の結果と一致しない場合、ソフトウェアのバグが発生します。コンピュータープログラムのエラー、欠陥、障害、または障害の可能性があります。ほとんどのバグは、開発者または設計者が犯した間違いやエラーから発生します。

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

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

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

欠陥マッピング

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

再テスト

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

再テスト中、テスターは機能の変更された領域で詳細を探しますが、リグレッションテストはすべての主要な機能をカバーし、この変更により機能が破損しないことを確認します。

回帰試験

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

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

回帰テストの種類

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

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

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

テスト実行

Stlc-test-execution

目次