Stlc-quick-guide
STLC-概要
STLCは、ソフトウェアテストライフサイクルの略です。 STLCは、ソフトウェアまたは製品の品質を保証するためにテストチームが実行する一連のさまざまなアクティビティです。
- STLCは、ソフトウェア開発ライフサイクル（SDLC）の不可欠な部分です。 ただし、STLCはテスト段階のみを扱います。
- STLCは、要件が定義されるか、SRD（ソフトウェア要件ドキュメント）が利害関係者によって共有されるとすぐに開始されます。
- STLCは、品質の高いソフトウェアを確保するための段階的なプロセスを提供します。
- STLCの初期段階では、ソフトウェアまたは製品の開発中に、テスターはテストの範囲、開始基準と終了基準、およびテストケースを分析および定義できます。 これにより、テストサイクル時間が短縮され、品質が向上します。
- 開発段階が終了するとすぐに、テスターはテストケースの準備が整い、実行を開始します。 これは、初期段階でバグを見つけるのに役立ちます。
STLCフェーズ
STLCには次の異なるフェーズがありますが、すべてのフェーズに従うことは必須ではありません。 フェーズは、ソフトウェアまたは製品の性質、テストに割り当てられた時間とリソース、および従うべきSDLCのモデルに依存します。
STLCには6つの主要なフェーズがあります-
- 要件分析-SRDの準備が整い、利害関係者と共有されると、テストチームはAUT（テスト対象アプリケーション）に関する高レベルの分析を開始します。
- テスト計画-テストチームは戦略とアプローチを計画します。
- テストケースの設計-範囲と基準に基づいてテストケースを開発します。
- テスト環境のセットアップ-統合環境が製品を検証する準備ができたとき。
- テスト実行-製品のリアルタイム検証とバグの発見。
- テスト終了-テストが完了すると、マトリックス、レポート、結果が文書化されます。
比較-STLCとSDLC
この章では、STLCとSDLCの比較の要因を理解します。 次の点を考慮して、STLCとSDLCを比較してみましょう。
- STLCはSDLCの一部です。 STLCはSDLCセットのサブセットであると言えます。
- STLCは、ソフトウェアまたは製品の品質が保証されるテスト段階に限定されます。 SDLCは、ソフトウェアまたは製品の完全な開発において非常に重要な役割を果たします。
- ただし、STLCはSDLCの非常に重要なフェーズであり、最終製品またはソフトウェアはSTLCプロセスを経ることなくリリースできません。
- STLCは、既知の欠陥が修正されるか、ソフトウェアに新しい機能が追加されるSDLCのメンテナンスフェーズであるリリース後/更新サイクルの一部でもあります。
次の表は、フェーズに基づいてSDLCとSTLCを比較する要因を示しています-
| Phase | SDLC | STLC |
|---|---|---|
| Requirement Gathering |
|
|
| Design |
|
|
| Development |
|
|
| Environment Set up |
|
|
| Testing |
|
|
| Deployment/Product Release |
|
|
| Maintenance |
|
|
STLC-テストの基本原則
テストの一般的な目的は、できるだけ早くバグを見つけることです。 そして、バグが修正されたら、期待どおりに動作し、他の機能を破壊しないことを確認してください。
これらの目標を達成するために、ソフトウェアテストには7つの基本原則が与えられています-
テストが示すもの
テストでは欠陥が存在することを示すことができますが、製品に欠陥がないことを証明する方法はありません。 テスト段階では、テスト対象のアプリケーションが指定された要件に基づいて動作していることを確認し、アプリケーションの未発見の欠陥の可能性を減らすのに役立ちます。 しかし、欠陥が見つからない場合でも、それが絶対に正しいという意味ではありません。 AUTは終了基準と一致し、SRDに従って要件を維持していると想定できます。
徹底的なテストは可能ですか？
些細な場合を除き、入力のすべての組み合わせおよび可能な組み合わせの100％のカバレッジまたはテストは不可能です。 徹底的なテストの代わりに、リスク分析と優先順位を使用してテストの範囲を定義します。 ここで、ほとんどのリアルタイムシナリオは、最も可能性の高いネガティブシナリオも含めることを検討できます。 これは、障害の追跡に役立ちます。
初期テスト
テスト活動はできるだけ早く開始し、テスト戦略で定義された目標と期待される結果に焦点を当てる必要があります。 テストの初期段階は、要件の欠陥または設計レベルの矛盾を識別するのに役立ちます。 これらのタイプのバグが初期段階で捕捉されると、時間を節約でき、費用対効果も高くなります。 テストを早い段階で開始する理由に対する答えは非常に単純です。SRDを受け取ると、テスターはテストの観点から要件を分析し、要件の不一致に気付くことができます。
欠陥クラスタリング
以前の製品の欠陥分析に基づくと、ほとんどの欠陥は、アプリケーションにとって重要な小さなモジュールのセットから特定されていると言えます。 これらのモジュールは、複雑さ、異なるシステムの相互作用、または他の異なるモジュールへの依存性に基づいて識別できます。 テスターがこれらの重要なモジュールを特定できる場合、これらのモジュールにさらに焦点を当てて、考えられるすべてのバグを特定できます。 調査では、AUTの20％の機能から10個の欠陥のうち8個が特定されていることがわかりました。
農薬パラドックス
農薬のパラドックスとは何か–農薬が作物に頻繁に使用される場合、昆虫が特定の種類の抵抗性を発現し、徐々に散布された農薬が昆虫に効果がないように思われます。
同じ概念がテストにも適用できます。 ここでは、昆虫は虫であり、農薬は何度も実行するために使用されるテストケースです。 同じテストケースのセットが何度も実行されると、これらのテストケースは特定の時間枠の後に無効になり、テスターは新しい欠陥を特定できなくなります。
これらの条件を克服するために、テストケースを時々修正およびレビューし、新しい異なるテストケースを追加する必要があります。 これは、新しい欠陥の特定に役立ちます。
テストはコンテキストに依存
この原則は、2つの異なるタイプのアプリケーションは、両方のアプリケーションが同じ性質になるまで同じアプローチを使用してテストできないことを示しています。 たとえば、テスターがWebベースのアプリケーションとモバイルアプリケーションに同じアプローチを使用している場合、これはまったく間違っており、製品リリースの品質が低下するリスクが高くなります。 テスターは、アプリケーションの種類と性質に応じて、さまざまなアプローチ、方法論、手法、カバレッジを使用する必要があります。
エラーの欠如-誤acy
この原則は、アプリケーションまたはシステムが安定するまで欠陥を見つけて修正し、時間がかかり、リソースを使い果たしてしまうことを示しています。 欠陥の99％を修正した後でも、アプリケーションが不安定になるリスクが高くなります。 最初の重要なことは、アプリケーションの安定性と環境の前提条件を検証することです。 これらの2つの条件が満たされた場合にのみ、詳細なテストを開始できます。
STLC-要件分析
要件分析はSTLCの最初のフェーズであり、SRD/SRSがテストチームと共有されるとすぐに開始されます。 STLCの要件分析を理解するために、次の点を考慮しましょう。
- このフェーズのエントリ基準は、SRS（ソフトウェア要件仕様）の提供です。また、アプリケーションアーキテクチャが便利であることも推奨されます。
- このフェーズでは、QAチームは、テスト対象とテスト方法をより高いレベルで分析します。
- QAチームは、要件を理解するためにクエリや説明が必要な場合に、ビジネスアナリスト、システムアーキテクチャ、クライアント、テストマネージャー/リードなどのさまざまな利害関係者をフォローアップします。
- 要件は、パフォーマンス、セキュリティ、ユーザビリティなどのように機能的または非機能的である場合があります。 または機能的および非機能的の両方。
- このフェーズの終了基準は、RTM文書、自動化実現可能性レポート、および要件にさらに具体的に当てはまる場合は質問のリストを完成させることです。
要件分析のために実行されるアクティビティ
このフェーズでQAチームが実行する3つの主要なアクティビティがあります。 アクティビティは以下で説明されています。
スコープの定義
QAチームは、テストの範囲を高レベルで特定し、さまざまな機能モジュールに分割します。 チームは、実行に必要なテストの種類（煙テスト、健全性テスト、機能テスト、回帰テストなど）も特定します。 QAチームは、テストが実行されることになっている前提条件と環境の詳細を分析します。 チームは、テストの優先順位に関する詳細を収集し、検証するモジュールのシーケンスに焦点を当てます。 また、モジュールが矛盾し、機能が他のモジュールと一緒に引き継がれない場合の要件の欠陥も識別します。
RTMを準備する
要件トレースは、要件と、それらの要件を実装および検証するために開発された作業成果物との間のリンクを文書化するプロセスです。 RTMは、要件分析ですべての要件を追跡し、単一のドキュメントに記録します。 これらはすべて、ライフサイクルの終わりに提供されます。
マトリックスは、プロジェクトの範囲と生成される成果物の基礎となるため、プロジェクトの最初に作成されます。
Matrixは、成果物の出力を調べることで要件を前方に追跡し、製品の特定の機能に対して指定されたビジネス要件を確認することで要件を追跡するため、双方向です。
自動化分析
要件フェーズでは、QAチームが回帰テストの自動化の範囲を分析します。 自動化がスコープに追加される場合、チームは、使用可能なツール、自動化としてカバーされる機能、自動化開発に関係する時間枠およびリソース割り当てを決定します。 この分析が完了すると、QAチームは自動化実現可能性レポートをさまざまな関係者に提供し、サインオフを提供します。
STLC-入場と退場の基準
この章では、STLCのさまざまなレベルでの入場および退場基準を確認します。 基準を理解するには、次の点を考慮する必要があります。
理想的には、QAチームは、現在のフェーズの終了基準が満たされるまで、次のフェーズに進まないでください。 エントリ基準には、前のフェーズの終了基準の完了を含める必要があります。
リアルタイムでは、終了基準が満たされるまで次のフェーズを待つことはできません。 これで、前のフェーズの重要な成果物が完了したら、次のフェーズを開始できます。
STLCの各フェーズでは、エントリと終了の基準を定義する必要があります。
エントリー基準
STLCフェーズのエントリ基準は、特定の条件として定義できます。または、STLCフェーズのいずれかに入る前に、STLCの特定のフェーズを開始するために必要なすべてのドキュメントを提示する必要があります。
エントリ基準は、タスクの実行を許可する条件のセットであるか、これらの条件のいずれかがない場合、タスクを実行できません。
エントリ基準を設定する際、プロセスを開始するためにエントリ基準項目が利用可能になる時間枠を定義することも重要です。
インスタンスの場合、テストケース開発フェーズを開始するには、次の条件を満たす必要があります-
- 要件文書が利用可能でなければなりません。
- アプリケーションフローの完全な理解が必要です。
- テスト計画文書の準備ができているはずです。
終了基準
STLCフェーズの終了基準は、現在のフェーズを完了して次のフェーズに進む前に完了する必要があるアイテム/ドキュメント/アクション/タスクとして定義できます。
終了基準は一連の期待です。これは、STLCフェーズを完了する前に満たす必要があります。
インスタンスの場合、テストケース開発フェーズを完了するには、次の期待を満たす必要があります-
- テストケースを作成してレビューする必要があります。
- テストデータを特定して準備する必要があります。
- 該当する場合、テスト自動化スクリプトを準備する必要があります。
STLC-受け入れ基準
承認基準とは、要件ドキュメントに記載されている機能、モジュール、およびアプリケーションの予想される動作を意味します。 ソフトウェアシステムが要件の仕様を満たしているかどうかを判断するのは、検証段階/チェックポイントです。 このテストの主な目的は、ビジネス要件に対するシステムのコンプライアンスを評価し、必要な基準を満たしているかどうかを確認することです。
合格基準は一連のステートメントであり、予想される合否結果について明確に言及しています。 受け入れ基準は、機能要件と非機能要件の両方を指定します。 これらの要件は、「満足または期待される動作の条件」を表します。部分的に受け入れられることはありません。基準が満たされているか、満たされていません。
これらの基準は、機能/モジュールの境界とパラメーターを定義し、機能/モジュールが完了して期待どおりに機能しているかどうかを判断します。
高レベルの受け入れ基準は、テスト計画レベルで言及されています。 受け入れ基準は、テストケースレベルで検証または予想される結果のポイントのリストに変換されます。
受け入れ基準は、次の属性に基づいて定義されています-
- 機能の正確さと完全性
- データの整合性
- データ変換
- 使いやすさ
- パフォーマンス
- 適時性
- 機密性と可用性
- インストールおよびアップグレード機能
- スケーラビリティ
- ドキュメンテーション
STLC-テスト計画
テスト計画は、アプリケーションのテストに使用される戦略、使用されるリソース、テストが実行されるテスト環境、テストの制限、およびテストアクティビティのスケジュールの概要を示します。 通常、品質保証チームリーダーがテスト計画の作成を担当します。
テスト計画には何が含まれますか？
テスト計画には以下が含まれます。
- テスト計画ドキュメントの紹介。
- アプリケーションのテスト中の前提。
- アプリケーションのテストに含まれるテストケースのリスト。
- テストする機能のリスト。
- ソフトウェアのテスト中に使用される一種のアプローチ。
- テストする必要がある成果物のリスト。
- アプリケーションのテスト用に割り当てられたリソース。
- テストプロセス中のリスク。
- 達成されるべきタスクとマイルストーンのスケジュール。
テスト計画の重要なポイント
STLCのテスト計画では、次の点を考慮する必要があります。
- 理想的には、テストアナリスト（リード）/マネージャーがテスト戦略/テスト計画文書を準備します。
- 分析は、アプリケーション関連のデータ/情報により重点を置いています。
- これは、実際のテストタスクの最初のフェーズです。
- このフェーズでは、「テストする対象」および「テストに必要なリソース」に回答します。
- このフェーズの基本的な入力基準は、要件トレーサビリティマトリックスと一緒に要件ドキュメント（不明確/欠落/明確化された要件の更新バージョン）を提供することです。
- 自動化が範囲内にある場合、このフェーズに入る前に、自動化実現可能性レポートを準備する必要があります。
- このフェーズの終了基準は、テスト戦略/テスト計画ドキュメントとテスト作業量の見積もりドキュメントの完成です。
テスト計画フェーズの側面
このフェーズの主な目的は、テスト計画/テスト戦略ドキュメントを準備することです。 成果物の範囲、工数の見積もり、リソース計画の3つの主要な側面が含まれています。
成果物の範囲
成果物の範囲を超えて結論を出すには、次のアクティビティを実行する必要があります-
- 適切なエンゲージメントと配信モデルを特定します。
- テストの目的、テストの範囲、テストフェーズ、およびアクティビティを定義します。
- ビジネス要件とシステム要件を確認して、テストの実行可能性を特定します。
- テストプロセス、テストのタイプ、および手順を定義します。
- 欠陥管理と変更管理手順を定義します。
- テストツール、テクニック、およびベストプラクティスを特定します。
- リスク分析を定義します。
- 自動化ソリューションを定義し、該当する場合は自動化の適切な候補を特定します。
工数見積もり
推定は、推定値または近似値を見つけるプロセスです。これは、入力データが不完全、不確実、または不安定であっても、何らかの目的に使用できる値です。
見積もりにより、特定のシステムまたは製品を構築するのにどれだけのお金、労力、リソース、時間がかかるかが決まります。 推定はに基づいています-
- 過去のデータ/過去の経験
- 利用可能なドキュメント/知識
- 仮定
- 特定されたリスク
テスト推定の4つの基本的な手順は次のとおりです-
- AUT（テスト対象アプリケーション）のサイズの推定。
- 人月または人時間での労力の推定。
- 暦月のスケジュールの推定。
- 合意された通貨でのプロジェクトコストの推定。
リソースプラン
リソース計画は、テスト段階の重要な要素です。 これらの計画は、テストチームが特定のタスクを完了するのにかかる時間に反比例します。 リソースの数を増やしても、一定の制限の完了までの日数は減りますが、その後はリソースが飽和し、リソースを増やしても大きな影響はなく、完了日数が減らない可能性があります。
リソースリクエスター（通常はプロジェクトマネージャー）は、リソースを要求し、作業量とコストを追跡するためのリソース計画を作成します。 リソースマネージャーは、プランが使用される前に、リソースプランを変更および承認できます。
リソースプランの通常のワークフローは次のとおりです-
- プロジェクトマネージャーによる計画
- プロジェクトマネージャーからのリクエスト
- リソースマネージャーによる承認/変更/拒否
- 完了-リソースマネージャーによるサインオフ後のリクエストのクローズ
STLC-テストケース開発
テスト計画の準備が整うと、QAチームはテストケースの開発を開始します。 このフェーズの主な目的は、個々のユニットのテストケースを準備することです。 これらの機能的および構造的テストケースは、テスト計画で言及されている機能、検証のポイント、および検証をカバーしています。
STLCのテストケース開発では、次の点を考慮する必要があります。
- このフェーズでは、QAチームは段階的なアプローチでテストケースを作成します。 その後、テストケースは、変更が必要な場合にテストケースを確認または修正した後、ビジネスアナリストによって承認されます。
- テストケースの準備ができたら、QAチームは前提条件に基づいてテストデータを準備します。
- このフェーズのエントリ基準は、テスト計画のアクティビティを終了し、テスト計画を準備することです。
- このフェーズの終了基準は、テストケースをサインオフし、テストデータを準備し、自動化の範囲内であればテストスクリプトを準備することです。
- テストケースは、要件トレーサビリティマトリックスとマッピングして、何かが欠けている場合に要件のカバレッジをフォローアップする必要があります。
テストケース開発フェーズのアクティビティ
以下は、テストケース開発フェーズで実行される3つのアクティビティです-
テストシナリオの特定
シナリオは、複雑なシステムのテストと評価を容易にします。 次の戦略は、良いシナリオを作成するのに役立ちます-
- 考えられるユーザー、ユーザーの行動、目的を列挙します。
- ハッカーの考え方でユーザーを評価し、システムの悪用の可能なシナリオをリストします。
- システムイベントと、システムがそのような要求をどのように処理するかをリストします。
- メリットをリストし、エンドツーエンドのタスクを作成してチェックします。
- 同様のシステムとその動作について読んでください。
- 競合他社の製品とその前身に関する苦情の調査。
テストケース作成
テストケースは、特定の要件に対するコンプライアンスを検証するために特定のテストシナリオ用に開発された、テストデータ、前提条件、期待される結果、および事後条件を含むドキュメントです。
テストケースは、テスト実行の開始点として機能します。 入力値のセットが適用された後。アプリケーションには最終的な結果があり、実行終了条件とも呼ばれるエンドポイントにシステムを残します。
テストデータの準備
テストデータは、テストウェアでテストを実行するために使用されます。 テストデータは、欠陥を発見するために正確かつ網羅的である必要があります。 これらの3つの目的を達成するために、以下に示すように段階的なアプローチが続きます-
- テストリソースまたは要件を特定する
- テストする条件/機能を特定する
- 優先テスト条件を設定する
- テストの条件を選択する
- テストケースの処理の期待される結果を決定する
- テストケースを作成する
- 試験条件を文書化する
- 実施テスト
- 変更に基づいてテストケースを検証および修正する
アクティビティブロック図
次の図は、テストケース開発の一部を形成するさまざまなアクティビティを示しています。
STLC-テスト環境のセットアップ
テスト環境は、ソフトウェア、ハードウェア、およびネットワークが構成されたテストの実行をサポートする要素で構成されます。 テスト環境の構成は、環境/構成に関連する問題を発見するために、本番環境を模倣する必要があります。
テスト環境のセットアップでは、次の点を考慮する必要があります。
- テストが実行されるハードウェアとソフトウェア環境の組み合わせです。
- これには、ハードウェア構成、オペレーティングシステム設定、ソフトウェア構成、テスト端末、およびテストを実行するためのその他のサポートが含まれます。
- これは、テストプロセスの最も重要な側面です。 利用できない、または環境の設定に誤りがあると、すべてのテスト作業が台無しになります。
- 実際には、QAチームは適切なテスト環境がないと実際の作業を開始できません。
- これは独立したアクティビティであり、テストケースの開発とともに開始できます。
- 最も一般的には、このアクティビティは技術的な面で開発者が実行しますが、要件条件は顧客/ビジネスアナリストが実行できます。
- テスト環境の準備は、スモークテストによって検証され、QAチームによって実行されます。
- 理想的には、このフェーズのエントリ基準は、テスト計画の準備、煙テストケースの準備、およびテストデータの準備であると言えます。
- このフェーズの終了基準は、テスト環境を準備し、期待される結果で煙テストを正常に実行することです。
テスト環境のセットアップのために実行されるアクティビティ
このフェーズでは、次のアクティビティが実行されます。
設計テスト環境
テスト環境の設計では、次の要素が重要な役割を果たします。
- バックアップを取るためにテスト環境でアーカイブが必要かどうかを判断します。
- ネットワーク構成を確認します。
- 必要なサーバーオペレーティングシステム、データベース、その他のコンポーネントを特定します。
- テストチームが必要とするライセンスの数を特定します。
環境のセットアップ
環境のセットアップ要件を分析し、セットアップのソフトウェアおよびハードウェア要件のリストを準備します。 テスト環境のセットアップの公式確認を取得し、テスト環境にアクセスするように構成します。
煙テスト
環境がセットアップされ、QAチームが環境にアクセスできるようになったら、テスト環境のビルドの安定性を検証するために、スモークテストをすばやく実行する必要があります。 結果が予想どおりである場合、QAチームは次のフェーズに進むことができます。それ以外の場合は矛盾を指摘し、修正後の展開を待ちます。
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-欠陥ライフサイクル
バグライフサイクル（バグライフサイクルとも呼ばれます）は、欠陥の旅であり、欠陥がその寿命中に通過するサイクルです。 ソフトウェアテストプロセスによって管理され、使用するツールにも依存するため、組織やプロジェクトごとに異なります。
欠陥ライフサイクル-ワークフロー
次の図は、欠陥ライフサイクルのワークフローを示しています。
欠陥ライフサイクルの状態
以下は、欠陥ライフサイクルのさまざまな状態です。
- 新規-発生し、まだ検証されていない潜在的な欠陥。
- 割り当て済み-対処する開発チームに対して割り当てられています。
- アクティブ-欠陥は開発者によって対処されており、調査が進行中です。 この段階では、2つの可能な結果があります-遅延または拒否。
- テスト/修正済み/再テストの準備完了-不具合は修正され、テストの準備ができています。
- 検証済み-再テストされ、QAによってテストが検証された欠陥。
- Closed -QA再テスト後に閉じることができる欠陥の最終状態、または欠陥が重複しているか欠陥ではないと見なされる場合に閉じることができる。
- 再開-欠陥が修正されない場合、QAは欠陥を再開/再開します。
- 延期-特定のサイクルで欠陥に対処できない場合、将来のリリースに延期されます。
- 拒否-次の3つの理由のいずれかで欠陥を拒否できます。重複欠陥、欠陥ではなく、再現不能。
STLC-欠陥分類
欠陥は、QAチームの観点から*優先度*として、開発の観点から*重大度*（修正するコードの複雑さ）として分類されます。 これらは、時間枠と欠陥を修正するために必要な作業量で重要な役割を果たす2つの主要な分類です。
優先度とは何ですか？
優先度は、欠陥を解決する順序として定義されます。 通常、優先ステータスはQAチームによって設定され、開発チームが障害を修正するための時間枠に言及して障害を提起します。 優先度のステータスは、エンドユーザーの要件に基づいて設定されます。
たとえば、会社のロゴが会社のWebページに誤って配置されている場合、優先度は高くなりますが、重大度は低くなります。
優先リスト
優先度は、次の方法で分類することができます-
- 低-この欠陥は、重大な欠陥が修正された後に修正できます。
- 中-欠陥は後続のビルドで解決する必要があります。
- 高-欠陥はアプリケーションにかなりの影響を与え、修正されるまで関連モジュールを使用できないため、欠陥はすぐに解決する必要があります。
- 緊急-欠陥はアプリケーションまたは製品に深刻な影響を及ぼし、修正されるまで製品を使用できないため、欠陥はすぐに解決する必要があります。
重大度とは何ですか？
重大度は、アプリケーションの欠陥の弱さ、および開発の観点から修正するコードの複雑さとして定義されます。 *これは、製品の開発面に関連しています。 重大度は、システムの欠陥がどれほど悪い/重大であるかに基づいて決定できます。 重大度ステータスは、欠陥による機能の逸脱についてのアイデアを提供できます。
例-フライト運営ウェブサイトの場合、予約に対するチケット番号の生成の欠陥は、重大度が高く、優先度も高いです。
重大度リスト
重大度は、次の方法で分類できます-
- *重大/重大度1 *-欠陥はアプリケーションの最も重要な機能に影響を与え、QAチームは修正せずにテスト中のアプリケーションの検証を続行できません。 たとえば、アプリ/製品が頻繁にクラッシュします。
- *メジャー/重大度2 *-欠陥は機能モジュールに影響を与えます。 QAチームはその特定のモジュールをテストできませんが、他のモジュールの検証を続行します。 たとえば、フライトの予約が機能していません。
- *中/重大度3 *-障害には単一の画面または単一の機能に関連する問題がありますが、システムはまだ機能しています。 ここでの欠陥は機能をブロックしません。 たとえば、Ticket＃は、最初の5文字と最後の5文字が数字であるような適切な英数文字に従わない表現です。
- *低/重大度4 *-機能には影響しません。 表面的な欠陥、フィールドのUIの不整合、またはUI側からのエンドユーザーエクスペリエンスを改善するための提案である可能性があります。 たとえば、[送信]ボタンの背景色が[保存]ボタンの背景色と一致しません。
STLC-テストサイクルの閉鎖
テストが終了したことを確認するには、テスト終了条件に対するチェックが非常に重要です。 テストプロセスを終了する前に、製品の品質がテスト完了基準に照らして測定されます。
このフェーズのエントリ基準は、テストケースの実行が完了し、テスト結果が利用可能であり、欠陥レポートの準備ができていることです。
テスト完了の基準には以下が含まれます-
- 指定されたカバレッジが達成されました。
- showstoppers または重大な欠陥なし
- 中優先度または低優先度の既知の欠陥はほとんどありません。 これらは製品の使用には影響しません。
このフェーズの終了基準は、テスト終了レポートの提供と、後でクライアントがサインオフするマトリックスの準備です。
ここで、*テストサイクルの終了に関連するアクティビティ*について説明します。
テスト完了レポート
テスト完了レポートはプロセスであり、これにより、テストメトリックが要約形式でレポートされ、関係者が更新されます。 これにより、情報に基づいた決定を下すことができます。
テスト完了レポートには、次の情報が含まれます。
- テスト概要レポート識別子
- 概要
- 分散
- 要約結果
- 評価
- 計画的取り組みと実際の取り組み
- サインオフ
優れたテスト完了レポートは、品質を示し、顕著なリスクを測定し、テストされたソフトウェアのレベルを識別します。
テスト完了マトリックス
テストが完了すると、さまざまなマトリックスが収集され、テストレポートが作成されます。 レポートを準備するための基準は次のとおりです-
- 実行されたテストの数
- 合格したテストの数
- 失敗したテストの数
- 各モジュールに基づいて失敗したテストの数
- 実行サイクル中に発生したテスト欠陥の数
- 受理されたテスト欠陥の数
- 拒否されたテスト欠陥の数
- 延期されたテスト欠陥の数
- アクティブな欠陥のステータス
- ビルドの品質指標の計算
試験結果
テストケースの実行、欠陥の再テスト、回帰テストケースの実行中に、*テスト結果を保存*し、テスト実行の完了をサポートするためにテストサイクル終了ドキュメントとともに生成できます。
アーティキュレートは、スクリーンショット、データベースクエリ結果、記録、ログファイルなどです。
