ソフトウェアテスト方法論: QAモデル

ソフトウェアテスト手法とは何ですか?

ソフトウェア テスト方法は、テスト対象アプリケーションがクライアントの期待を満たしていることを証明するために使用される戦略とテストの種類として定義されます。 テスト方法には、AUT を検証するための機能テストと非機能テストが含まれます。 テスト方法の例は次のとおりです。 単体テスト, 統合テスト, システムテスト, 性能試験 各テスト方法には、定義されたテスト目的、テスト戦略、および成果物があります。

お願い: ソフトウェア テストはあらゆる開発方法論に不可欠な部分であるため、多くの企業では開発方法論とテスト方法論という用語を口語的に使用しています。 したがって、テスト方法論は、上記のテスト方法論の定義に対して、ウォーターフォール、アジャイル、その他の QA モデルを指すこともあります。 さまざまな種類のテストに関する議論は、読者に価値をもたらしません。 したがって、さまざまな開発モデルについて説明します。

テスト手法 vs テストの種類 vs テスト戦略

上記の注記は、業界における真の曖昧さを示唆している。3つの用語は会話では区別なく使われるが、プロジェクト文書上ではそれぞれ異なる意味を持ち、それらを混同すると、間違った質問に答えるテスト計画が作成されることになる。

契約期間	質問に答える	によって決定されました	例
テスト方法	テストは開発サイクルの中で、いつ、どのように組み込まれるべきか？	使用されている開発モデル	ウォーターフォール、反復型、アジャイル、エクストリームプログラミング
テストの種類	製品のどの側面が検証されているのですか？	リスクと要件の範囲	ユニット、統合、システム、パフォーマンス、セキュリティ
テストレベル	ソフトウェアはどの程度の深さまで検査されるのか？	ビルド階層における位置	コンポーネント、統合、システム、受け入れ
テスト戦略	品質に対する当社の組織的なアプローチとはどのようなものですか？	QAリーダーシップは、プロジェクト全体に適用されます。	リスクベース、自動化優先、シフトレフト
テスト計画	このプロジェクトでは、具体的に何を、いつ、誰がテストするのでしょうか？	テストマネージャー、プロジェクト固有	範囲、スケジュール、リソース、開始基準および終了基準

役立つ経験則：方法論がリズムを​​定め、タイプがターゲットを定め、 テスト計画 その取り組みを記録する。以下のセクションでは、その方法論について検討する。

ウォーターフォールモデル

それは何ですか？

滝モデル、ソフトウェア開発は、要件分析、設計などのさまざまなフェーズを経て進行します – 順次.

このモデルでは、前のフェーズが完了した場合にのみ次のフェーズが開始されます。

テストアプローチとは何ですか?

ウォーターフォール モデルの最初のフェーズは要件フェーズであり、テストを開始する前にすべてのプロジェクト要件が完全に定義されます。 このフェーズでは、テスト チームはテストの範囲、テスト戦略についてブレインストーミングを行い、詳細なテスト計画を作成します。

ソフトウェアの設計が完了して初めて、チームはテスト ケースの実行に進み、開発されたソフトウェアが期待どおりに動作することを確認します。

この方法論では、テスト チームは前のフェーズが完了した場合にのみ次のフェーズに進みます。

優位性	デメリット
このソフトウェア エンジニアリング モデルは、計画と管理が非常に簡単です。 したがって、要件が明確に定義され、事前に記載されているプロジェクトは、ウォーターフォール モデルを使用して簡単にテストできます。	ウォーターフォール モデルでは、前のフェーズが完了した後でのみ次のフェーズを開始できます。 したがって、このモデルは計画外の出来事や不確実性に対応できません。
	この方法論は、要件が頻繁に変更されるプロジェクトには適していません。

反復型開発

それは何ですか？

このモデルでは、大規模プロジェクトを小さな部分に分割し、各部分に対してウォーターフォールモデルの反復を複数回実施します。反復の最後に、新しいモジュールが開発されるか、既存のモジュールが強化されます。このモジュールはソフトウェアアーキテクチャに統合され、システム全体がまとめてテストされます。

テストアプローチとは何ですか?

反復が完了するとすぐに、システム全体がテストの対象になります。 テストからのフィードバックはすぐに利用可能になり、次のサイクルに組み込まれます。 後続の反復で必要なテスト時間は、過去の反復で得た経験に基づいて短縮できます。

優位性	デメリット
反復開発の主な利点は、各サイクルの終了時にテストのフィードバックがすぐに利用できることです。	このモデルでは、各サイクルの終了時に成果物や労力などに関するフィードバックを提供する必要があるため、通信のオーバーヘッドが大幅に増加します。

アジャイル方法論

それは何ですか？

従来のソフトウェア開発方法論は、ソフトウェア要件がプロジェクト全体を通じて一定であるという前提で機能します。しかし、複雑さが増すにつれて、要件は何度も変更され、継続的に進化します。時には、顧客自身が何を望んでいるのかよくわからないこともあります。反復モデルはこの問題に対処しますが、それでもウォーターフォール モデルに基づいています。

アジャイル手法では、ソフトウェアは増分的かつ迅速なサイクルで開発されます。 プロセスやツールよりも、顧客、開発者、クライアント間の対話が重視されます。 アジャイル手法では、広範な計画よりも変化への対応に焦点を当てます。

テストアプローチとは何ですか?

増分テストはアジャイル開発手法で使用されるため、プロジェクトのすべてのリリースが徹底的にテストされます。 これにより、システム内のあらゆるバグが次のリリースまでに確実に修正されます。

優位性	デメリット
要件に準拠するために、いつでもプロジェクトを変更することが可能です。	クライアントとの絶え間ないやり取りは、クライアント自身、ソフトウェア開発チーム、テスト チームを含むすべての関係者に時間的プレッシャーがかかることを意味します。
この増分テストによりリスクが最小限に抑えられます。

エクストリームプログラミング

それは何ですか？

エクストリーム プログラミングは、短い開発サイクルを信条とするアジャイル手法の一種です。プロジェクトは単純なエンジニアリング タスクに分割されます。プログラマーは単純なソフトウェアをコーディングし、顧客にフィードバックを求めます。 Rev顧客からフィードバックされたポイントが取り入れられ、開発者は次のタスクに進みます。

エクストリーム プログラミングの開発者は通常、ペアで作業します。

エクストリームプログラミング 顧客の要件が常に変化する場所で使用されます。

テストアプローチとは何ですか?

エクストリーム プログラミングは、次のように説明されるテスト駆動開発に従います。

1. 加える テストケース まだ開発されていない新機能を検証するためのテストスイート
2. すべてのテストを実行すると、機能がまだコーディングされていないため、追加された新しいテスト ケースは明らかに失敗するはずです。
3. 特徴/機能を実装するコードを作成する
4. テスト スイートを再度実行します。 今回は、機能的にコーディングされているため、新しいテスト ケースはパスするはずです。

優位性	デメリット
漠然としたソフトウェア設計しか考えていない顧客は、エクストリームプログラミングを利用できる。	ソフトウェア開発チームとクライアントの間でのミーティングにより、さらに時間がかかります。
小規模リリースの継続的なテストと継続的な統合により、ソフトウェア コードが高品質で提供されることが保証されます

Vモデルとスパイラルモデル

ほとんどのプロジェクトではさらに2つのモデルが登場し、全体像を完成させる。なぜなら、それぞれがウォーターフォール型アプローチの弱点を異なる方法で克服しているからである。

V型モデル。 検証と妥当性確認とも呼ばれるVモデルは、開発の各フェーズに対応するテストフェーズを、V字の2つの腕として表します。要件は受け入れテストと、高レベル設計はシステムテストと、低レベル設計は統合テストと、コーディングは単体テストと対応します。このモデルの利点は、テスト設計がコーディング後ではなく、各開発フェーズと並行して開始されるため、受け入れテストを作成する担当者が、欠陥が発生する数ヶ月前に曖昧な要件を発見できる点です。弱点はウォーターフォールモデルから受け継いだもので、要件が安定していることを前提としています。

スパイラルモデル。 スパイラルループ方式は、明示的なリスク分析を中心に反復処理を繰り返す。各ループは、目標設定、リスクの特定と解決、開発とテスト、そして次の反復計画という4つの活動から構成される。そのため、テストはリスクが最も高い箇所に集中し、均等に分散されることはない。航空宇宙産業や銀行の中核システムなど、リスクの発見が遅れた場合のコストが甚大となる大規模で高額な長期プロジェクトに適している。小規模なWebプロジェクトでは、各ループで正式なリスク分析を行うオーバーヘッドは、ほとんどの場合正当化されない。

どちらのモデルもウォーターフォール型の規律とアジャイル型の応答性の中間に位置します。リリース頻度がどちらよりも重要な場合、 DevOps パイプラインはテストを継続的インテグレーションに組み込むことで、すべてのコミットが自動的に検証されるようにします。

どのソフトウェア方法論を選択するべきですか?

ソフトウェア開発とそれに対応するテストに利用できる方法論は数多くあります。 それぞれのテスト技術と方法論は特定の目的のために設計されており、それぞれに相対的な長所と短所があります。

特定の方法論の選択は、プロジェクトの性質、クライアントの要件、プロジェクトのスケジュールなどの多くの要因によって決まります。

テストの観点から見ると、一部の方法論では開発ライフサイクルの早い段階でテスト入力を推進しますが、他の方法論ではシステムの実用モデルが準備できるまで待機します。

ソフトウェアのテスト方法を設定するにはどうすればよいですか?

ソフトウェア テスト方法は、ソフトウェア コードをテストするためだけに設定すべきではありません。 全体像を考慮し、プロジェクトの主な目標をテスト方法で満たす必要があります。 この評判の良いリストを参照してください ソフトウェアテストサービスプロバイダー プロジェクトの目標に合わせた効果的なテスト戦略の確立を支援してくれる人。

スケジュール管理

現実的なスケジュール設定は、テスト手法の実装を成功させるための鍵であり、スケジュールはチームのすべてのメンバーのニーズを満たす必要があります。

定義された成果物

チームのメンバー全員が同じ認識を保つためには、明確に定義された成果物を提供する必要があります。 成果物には、曖昧さのない直接的なコンテンツが含まれている必要があります。

テストアプローチ

スケジューリングが完了し、定義された成果物が利用可能になると、テスト チームは適切なテスト アプローチを策定できるようになります。 定義文書と開発者会議では、プロジェクトに使用できる最適なテスト手法についてチームに示す必要があります。

レポート作成

透明性のあるレポートを実現するのは非常に困難ですが、このステップがプロジェクトで使用されるテストアプローチの有効性を決定します。

よくあるご質問