再試験チュートリアル：例とベストプラクティスを含む包括的ガイド

再テストは、前回のテスト中に機能が失敗した特定の機能を検証するプロセスです。実行時にいくつかのバグが報告されたテストケースが修正されたかどうかを確認するために行われます。

ソフトウェア開発ライフサイクルにおいて、最も重要な要素は、ソフトウェアの機能、パフォーマンス、セキュリティ、その他の側面をテストすることであり、ソフトウェアにエラーがないかどうかをチェックすることを含みます。しかし、最大の課題は、ターゲットオーディエンスと一致してソフトウェアの動作を検証することです。開発されたソフトウェアの有効性と信頼性を保証することが重要であり、ここで再テストが救世主として登場します。

ソフトウェアテストの主な目的は、ソフトウェアアプリケーション内のエラーやバグを特定することです。テストエンジニアは、それらを特定し、開発チームに報告してさらに評価する責任があります。その後、そのような問題が解決され、テストエンジニアに再確認のために送られます。

再テストは、ソフトウェアリリース中に追加の問題が発生しないことを保証します。このようなプロセスは、特定のテストケースセットを使用して手動で実行できます。再テストに含まれる複雑さに関係なく、これをソフトウェアテストの根本的な部分として理解し、高品質の製品を提供する必要があります。

再テストとは何ですか？

ソフトウェアをテストしている間にバグを見つけることがテストエンジニアの役割であるという事実に慣れているはずです。そのような取り組みの中で、彼らはエラーや問題を修正して開発者に送り返し、そのようなエラーや問題が修正されることを保証する責任があります。ここで再テストが登場します。もっと明確に理解しましょう。

ソフトウェア開発において、再テストは、開発者から提供されたビルドを検証するプロセスであり、エラーが修正されていることを確認するために行われます。簡単に言えば、「ビルド番号1」のソフトウェアをテストしていて、エラーが発生した場合、そのIDが例えばA1だったとします。その後、テスターはそのようなエラーをテストし、「ビルド番号2」と名付けられます。

言い換えれば、ビルド番号1で特定されたエラーが、ビルド番号2で再びテストされることで、開発者がエラーを修正したかどうかを確認することです。ここでテスターは、開発者によって修正された内容を検証するために失敗したケースを再テストします。

これは、以前のテスト時に機能していなかったテストケースが開発者によって修正されたデフェクトライフサイクルの一部であり、失敗したテストケースのテストが行われます。

再テストプロセスに関する詳細情報を得るために以下のポイントに従ってください：

• 報告されたバグに対応する失敗したテストケースが再テストされます。
• 再テストの別名は確認テストです。
• 新しいビルドで報告されたエラーに対して、その再現性を検証するために同様のテストデータおよびプロセスを使用すべきです。

A comprehensive example of the retest process will help you get a clearer picture.

なぜ再テストが重要なのか？

再テストはソフトウェアテスティングライフサイクルの一部であり、製品の効果的な提供に関連する多くの重要性をもっています。確かに、それは標準的なソフトウェアテスティングプロセスの主要部分です。しかし、さらに、それはリリース前のエンドユーザーに製品を提供する前に、その技術的および機能的パフォーマンスをスクリーニングする追加の保証レイヤーを提供します。

企業は、この競争が激しいソフトウェア開発市場において、高品質のデジタルアプリケーションを保証すべきです。これには、最終製品の品質に妥協してはなりません。

自動化されたテストプラットフォームは、リリースされた製品に対してより良いROIを得るのに役立つことが多いです。しかし、再テストはすべてのバグを検証することでより高い信頼性をもたらします。初期のテストプロセスと比較して、テストリソースに追加コストを追加することも、多大な時間を要することもありません。失敗したテストケースに関連する類似データを使用して、同じ環境で実行されることが知られています。

さらに、再テストプロセスは、特定のアプリケーションモジュールで発見された特定の問題やバグに対処します。そのため、新しいテスト環境を設定する必要はありませんし、エンドツーエンドのテストで製品の品質を確認するために余分な労力を費やす必要もありません。

再テストの例

上述の説明された例は表面的な情報を得るのに役立ちますが、以下では、そのプロセスについてより深い洞察を持つ同様の例を取り上げます。

シナリオ

ソフトウェア開発プロセスの一環として、ビルド2.0がリリースされました。そのテスト中に、チームは欠陥（例えば、欠陥2.0.1）を特定し、リリースしました。同様の欠陥2.0.1は、その欠陥がビルド2.1のリリースノートに記載されている場合には、ビルド2.1でテストされる必要があります。これにより、欠陥の修正が確認されます。

実行プロセス

バグのライフサイクルに従えば、バグが記録されると、開発チームに直ちに共有または報告されます。その後、そのステータスは「新規」とマークされます。これからは、開発チームがバグを受け入れるか拒否するかが問われます。

バグが受け入れられると、開発者はそれを修正し、次の段階でリリースします。そのステータスは「QA準備完了」とマークされます。現在、テスターはバグを検証し、その解決策を理解するためにバグの再テストを行います。したがって、再テストは計画されたテストであると言えます。

テスターは前回のビルドで使用したのと同じテストケースとテストデータを使用します。バグが発見されない場合、そのステータスは「修正済み」とマークされます。反対に、ステータスは「未修正」のままです。その後、デフェクトリトライテスティングドキュメントが開発チームと共有されます。

再テストに関する良い洞察を得るためには、その主要な特徴を知ることが重要です。これは、テストを多様化するだけでなく、ソフトウェアの品質構築の次元を拡大するのにも役立ちます。

再テストの特徴

ソフトウェアテスティングにおけるトップノッチなユーザーエクスペリエンスは反復的なプロセスに従います。このため、再テストプロセスの重要な側面に関する情報を保持することで、より良いアプリケーションの提供が可能になります。

以下はその主な特徴です。

• 前回と同じドキュメントで実装され、新しいビルドでプロセスが進行します。
• 特定のテストケースが失敗と見なされる場合に実行されます。
• 完全なソフトウェアがその品質を検証するために再テストを必要とする場合に発生します。
• 再テストされているテストケースを自動化することは不可能です。
• 再テストプロセスは開発チームに依存しており、バグの受理または拒否の責任があります。
• テスターは機能の変更された側面について詳細な検討を行います。

いつ再テストを実行すべきか？

テスターとして、いつ再テストを行うべきかを決定することが重要です。この答えは簡単です。まず、テストが必要なプロジェクトのサイズと機能を考慮する必要があります。

例えば、組織が様々な製品に分散された広範な製品ラインを保有している場合、再テストは通常のことになります。その理由は、ソフトウェアアプリケーションのタイムリーなリリースの必要性があり、これが他のシステムの部分に様々な方法で影響を与える可能性があるためです。

再テストをプロセスとして使用できる状況がいくつかあります。そのいくつかは以下に説明されています。

拒否されたバグの検出時

テスターが発行したバグが開発者によって拒否され、「再現不可能」とマークされることがたびたびあります。このような場合、同じバグに対して再テストが行われ、開発者にその問題が再現可能で有効であることを知らせます。

リリースノートで明示されたバグ修正の必要性

ソフトウェア開発プロセスでは、開発チームが新しいビルドをリリースする際、再テストが行われます。ここで、テスターは以前に報告されたバグをテストし、それらの修正を確認します。

顧客のリクエスト

ソフトウェアの品質は、すべての組織にとって大きな関心事です。これを確保するために、顧客は特定のユースケースについてリテストを実行するよう依頼することがあります。

その他のシナリオ

バグが修正されるたびに、開発者が追加のテストケースを作成することに注意することが重要です。これは、テストケースを書く時間をバグを修正する時間よりも多く費やすべきであることを示しています。しかし、コードベースに自信があるにもかかわらず、リリース時にアプリケーションの重要な部分をリテストすることが依然として重要です。

例えば、新しい機能が予期しない動作を引き起こし、最初の瞬間にバグを検出することが難しくなる場合があります。これは、テスト中やユーザーフィードバックに基づいてそのような問題が明らかになった場合にのみ可能です。この状況では、新しく特定されたバグについての懸念を克服するために「リテスト」を実施する必要があります。

リテストの利点

ソフトウェアアプリケーションの品質は、リテストプロセスの成功に依存します。ソフトウェア開発ライフサイクルにおけるアプリケーションの安定性を保証します。

その主な利点は以下の通りです。

• バグが修正されたかどうかを確認します。
• 開発された製品およびアプリケーションの品質を向上させます。
• アプリケーションまたは製品の動作がユーザーの期待に沿っていることを保証します。
• 特定の問題に対処するため、バグを修正する時間が少なくなります。
• 新しいビルドで同じデータとプロセスで動作するために機能します。
• 新しいテスト環境のセットアップを必要としません。

再テストプロセスにはいくつかの利点があるが、欠点もいくつかあります。以下のセクションからこれを理解しましょう。

再テストの欠点

A retest process also has some drawbacks, which can hamper or create challenges in the testing process. Knowing such limitations will help you address those while retesting to avoid any issues.

それらが何であるか理解しましょう：

• 欠陥の検証のために新しいビルドが必要です。
• 再テストのテストケースは、開始されるときにのみ取得できます。
• テストケースを自動化して再テストすることは不可能です。
• 失敗したテストケースの再テストには追加の時間と労力が必要です。
• バグが特定されたり修正されたりした場合を除いて、再テストがテストプロセスの一部として保証されることはありません。

再テストの欠点に対処すると、再テストは一部のテスターにとって難しいかもしれないと言えます。特に新しいテスターは、問題を修正するための代替方法を探そうとします。ここで彼らを混乱させるのは、リグレッションテストという用語です。しかし、リグレッションテストと再テストには大きな違いがあります。

リグレッションテストと再テストの違いは何ですか？

ソフトウェアテストに新しい場合、「再テスト」と「リグレッションテスト」という用語は同じように思えるかもしれません。しかし、それらは関連しているが異なるという事実です。このセクションでは、再テストプロセスがリグレッションテストとどのように異なるかを探ります。

まず、回帰テストとリテストは、ソフトウェア開発プロセスにおけるソフトウェア検証の一部です。リテストは主に開発の特定のフェーズの終わりに行われます。言い換えれば、作業中の製品が以前のテストからのバグでいっぱいでないことを確認したい場合は、リテストを行います。対照的に、回帰テストはコードの特定の側面の正確な動作を確認するために、開発のいずれかのフェーズで実行できます。

特定の状況では、テスターは以前のテスト出力やレポートを読むだけでリテストを実行し、問題とその修正をチェックできます。包括的な調査も、以前のケースを個別にチェックして、適切に処理されていることを確認することで行うことができます。ただし、回帰テストは主にテスト計画に基づいて実行され、最新のバージョンから開始して各アプリケーションバージョンで実行されます。このようなアプローチでは、すべてのアプリケーションの変更が適切にテストされていることを確認する必要があります。

次に、回帰テストとリテストプロセスの違いに関するいくつかの重要なポインターを示します。

例を使って回帰テストとリテストを理解する

回帰とリテストの違いは、次の例で説明できます。

たとえば、銀行のWebアプリケーションのログインページに問題があり、顧客がアカウント詳細にアクセスできないとします。彼らは再びログインしようとしましたが、アカウントにログインできませんでした。サポートチームは問題を調査し、そのようなことが再発しないことを確認しました。

開発チームは、すべてのブラウザでアカウントページへのログインを成功させるために、コードレベルで変更を行いました。ただし、ここでのテストは、ログインページだけでなく、コードの変更が銀行のWebアプリケーションの他の機能に影響を与えないことを確認することも含まれます。ここで行われるテストは、アプリケーションの変更をテストします。これはリグレッションテストと呼ばれます。

変更に対応する問題を再確認すると、テストチームはページにログインしようとしましたが、失敗しました。サポートチームは、関係する開発者と連絡を取り、問題を説明しました。しかし、開発者は問題が解決したと伝えました。QAチームは、問題が解決されたかどうかを確認するためにWebアプリケーションの動作をテストします。これは再テストと呼ばれます。

したがって、再テストはソフトウェアテストプロセスで不可欠であり、その動作を確認するための前提条件です。

再テストプロセスの重要性について説明し、ソフトウェアテストとの関係についてのアイデアを与えました。まず、ソフトウェアテストでのその一般的な用途をいくつか理解しましょう。以下は、ソフトウェアテストでの再テストの用途のいくつかです。

• 特定のエラーやバグの修正に適用され、確認が必要です。
• 最終的な機能を検証するために、システム全体の動作をチェックします。
• システムの特定の部分の品質をチェックします。

再テストのフェーズ

再テストプロセスは手動アプローチを含みます。また、ソフトウェアアプリケーションのテストの主要フェーズも考慮します。

以下は、再テストプロセスに関与するフェーズです。

1. テストケースの選択 

テストケース選択は、テストスイートから特定のテストケースを実行し、ソフトウェア内のエラーの修正が行われたかどうかを監査する手法です。一般的に、テストケースは再利用可能と廃棄されるという2つのカテゴリに分けられ、再利用可能なテストケースは再テストに使用されます。

2. テストケースの適用

再テストプロセスの主な焦点は、テストケースの予想される出力を比較することです。したがって、標準的な事前実行結果シートを持つテストケースを適用する必要があります。

3. 時間の見積もり

テストケースを特定する際、テスターは再テストに関与する総実行時間を考慮すべきです。テストケースの評価のような要因が余分な時間を追加する可能性があります。

4. モジュールの追跡

テストケースが失敗した場合、エラーに対応するモジュールを特定することは大きな課題です。そのため、ソフトウェア部分は個別の異なるモジュールに分割されます。

これを行うために、特定の個別モジュールのための小さなテストケースが実装されます。予期される結果を示さないモジュールは、欠陥モジュールとしてマークされます。このようにして、欠陥モジュールの追跡が達成されます。

5. モジュールの再テスト

欠陥モジュールが修正されるまで再テストします。

6. モジュールの再統合

欠陥モジュールの修正後、テストケースの完全な統合がソフトウェアに適用されます。さらに、ソフトウェアの動作がチェックされます。

リターステストの実行方法

ソフトウェアアプリケーションのリターステストは、手動によるアプローチのみで行うことができます。上記のセクションで強調されているように、主な理由は特定の欠陥に焦点を当てるためです。したがって、自動化方法よりも正確に行うことができる手動テストアプローチが適切です。

リターストを実行するためには、テストチームはソフトウェアアプリケーションの現在のステータスに関する豊富な知識を持っている必要があります。このソフトウェアの動作に関する知識と、バグを修正して効果的にする方法は、手動アプローチを容易にします。

テスターは、アプリケーションで行われた変更を検証するために、テストケースを手動で実行します。これは、そのような変更が新たな欠陥を引き起こさないこと、および特定された失敗したケースが新しいリリースで排除されていることを確認するために行われます。ソフトウェアへの変更を修正し、欠陥を修正し、ソフトウェアテストサイクルを完了した後に手動のリターストを実行できます。

手動でリターストを実行するには、以下の手順に従ってください。

1. ソフトウェアアプリケーションへの変更とリターストが必要な領域を特定します。
2. 変更に応じてリターストが必要なテストケースを確認し、更新します。
3. 開発されたテストケースは手動で実行する必要があります。
4. 実際の出力を期待される結果と比較し、変更が新たな欠陥を引き起こさないことを評価します。
5. 欠陥が特定された場合は、それを文書化し、開発チームに報告します。
6. すべての不具合が修正されるまで、手動のリターストプロセスを繰り返します。

しかし、なぜリトライテストが自動化されたアプローチで行えないのか疑問に思うかもしれません。これにはいくつかの理由があります。以下のセクションから考えを得ましょう:

リトライテストは自動化できないのでしょうか？

アプリケーションのリトライテストを自動化アプローチで行うことはできません。以下に示すのは、一般的な理由です:

• 複雑性: 失敗したケースのいくつかは、ソフトウェアの複雑さのために発生する可能性があります。したがって、そのような失敗したケースは自動化が難しいです。
• 予期しない結果: ソフトウェアで行われた変更が予期しない結果をもたらす可能性があります。そのような状況での失敗ケースは、結果を確認するために手動テストが必要です。
• コストとリソース: リトライテストプロセスの自動化は、追加のハードウェアとソフトウェアを使用することを伴うため、コストがかかる可能性があります。ソフトウェアの微小な変更に対するコストを正当化するのは難しいです。
• 時間の制約: リトライテストプロセスの自動化は、膨大な時間を要することがあり、期限に対するプレッシャーがある場合、手動アプローチが最善の選択です。

リトライテストを行う際に考慮すべき点

これまでのところ、リトライテストプロセスの重要性とその実行方法を理解しました。ただし、リトライテストにおける有効な考慮事項の存在に注意が必要です。以下は、考慮すべきポイントです。

• リトライテストプロセスは、最初のレポートに基づいて問題が修正された場合に新しいソフトウェアビルドを作成する必要があります。
• ソフトウェアを再テストする際に、コードレベルでの変更が行われる可能性があります。そのため、アプリケーションのリリース前にリグレッションテストを実施することが不可欠です。
• 問題の修正後にのみ、再テストのカバレッジと範囲を知ることができます。その結果、再テストにおいてリグレッションのように自動化を実行することはできません。
• 再テストで発見された問題が解決されない場合、アプリケーションの開発時間が増大する可能性があります。根本原因を究明するために、より包括的かつ戦略的な評価が必要です。

しかし、再テストプロセスで遭遇する課題にも関わらず、組織はテスティング手法に注意を払うべきです。これは、クラウド上で再テストを実行することでより効果的に行えます。詳細について見ていきましょう。

クラウド上での再テストの実行方法

再テストプロセスを自動化することは常に実現可能ではなく、ソフトウェアの品質を保証するために手動テストが必要です。ただし、場合によっては時間がかかり、スケーラブルなプロセスではありません。クラウドテスティングプラットフォームは、テストインフラに関する課題を克服するのに役立ちます。