Software-testing-quick-guide

ソフトウェアテスト-概要

テストとは何ですか？

テストとは、指定された要件を満たしているかどうかを確認するために、システムまたはそのコンポーネントを評価するプロセスです。 簡単に言えば、テストとは、実際の要件に反して、ギャップ、エラー、または要件の欠落を特定するためにシステムを実行することです。

ANSI/IEEE 1059規格によれば、テストは次のように定義できます-既存の条件と必要な条件（欠陥/エラー/バグ）の違いを検出し、ソフトウェア項目の機能を評価するソフトウェア項目を分析するプロセス。

誰がテストしますか？

それは、プロセスとプロジェクトの関連する利害関係者に依存します。 IT業界では、大企業には、特定の要件に照らして開発されたソフトウェアを評価する責任を持つチームがあります。 さらに、開発者は*単体テスト*と呼ばれるテストも実施します。 ほとんどの場合、次の専門家は、それぞれの能力内でシステムのテストに関与しています-

• ソフトウェアテスター
• ソフトウェア開発者
• プロジェクトリーダー/マネージャー
• エンドユーザー

ソフトウェアテスター、ソフトウェア品質保証エンジニア、QAアナリストなど、経験と知識に基づいてソフトウェアをテストする人には、会社ごとに異なる指定があります。

サイクル中はいつでもソフトウェアをテストすることはできません。 次の2つのセクションでは、SDLC中にテストを開始するタイミングと終了するタイミングを示します。

テストを開始するタイミング

テストを早期に開始することで、クライアントに配信されるエラーのないソフトウェアを作り直して作成するためのコストと時間を削減できます。 ただし、ソフトウェア開発ライフサイクル（SDLC）では、要件収集フェーズからテストを開始し、ソフトウェアの展開まで継続できます。

また、使用されている開発モデルにも依存します。 たとえば、ウォーターフォールモデルでは、テスト段階で正式なテストが行​​われます。ただし、インクリメンタルモデルでは、すべてのインクリメント/イテレーションの最後にテストが実行され、最後にアプリケーション全体がテストされます。

テストは、SDLCのすべての段階で異なる形式で行われます-

• 要件収集フェーズでは、要件の分析と検証もテストと見なされます。
• 設計を改善する目的で設計段階で設計をレビューすることもテストと見なされます。
• コードの完成時に開発者が実行するテストもテストとして分類されます。

テストを停止するタイミング

テストは終わりのないプロセスであり、ソフトウェアが完全にテストされていると主張することはできないため、いつテストを停止するかを決定することは困難です。 次の側面は、テストプロセスを停止するために考慮されるべきです-

• 期限のテスト
• テストケースの実行の完了
• 特定のポイントまでの機能およびコードカバレッジの完了
• バグ率が特定のレベルを下回り、優先度の高いバグが特定されない
• 経営判断

検証と検証

これらの2つの用語は、ほとんど同じ意味で使用している人にとって非常にわかりにくい用語です。 次の表は、検証と検証の違いを示しています。

Sr.No.	Verification	Validation
1	Verification addresses the concern: "Are you building it right?"	Validation addresses the concern: "Are you building the right thing?"
2	Ensures that the software system meets all the functionality.	Ensures that the functionalities meet the intended behavior.
3	Verification takes place first and includes the checking for documentation, code, etc.	Validation occurs after verification and mainly involves the checking of the overall product.
4	Done by developers.	Done by testers.
5	It has static activities, as it includes collecting reviews, walkthroughs, and inspections to verify a software.	It has dynamic activities, as it includes executing the software against the requirements.
6	It is an objective process and no subjective decision should be needed to verify a software.	It is a subjective process and involves subjective decisions on how well a software works.

ソフトウェアテスト-神話

以下に、ソフトウェアテストに関する最も一般的な神話のいくつかを示します。

神話1：テストは高すぎる

現実-ソフトウェア開発中にテストに支払う費用を少なくするか、後でメンテナンスや修正に費用を支払うということわざがあります。 初期のテストは多くの面で時間とコストの両方を節約しますが、テストなしでコストを削減すると、ソフトウェアアプリケーションの設計が不適切になり、製品が役に立たなくなる可能性があります。

神話2：テストには時間がかかる

現実-SDLCフェーズでは、テストに時間がかかることはありません。 ただし、適切なテスト中に特定されたエラーの診断と修正は、時間がかかりますが生産的な作業です。

神話3：完全に開発された製品のみがテストされる

現実-間違いなく、テストはソースコードに依存しますが、要件の確認とテストケースの開発は、開発されたコードから独立しています。 ただし、開発ライフサイクルモデルとしての反復的または増分的なアプローチにより、完全に開発されたソフトウェアへのテストの依存性を減らすことができます。

神話4：完全なテストが可能

現実-完全なテストが可能であるとクライアントまたはテスターが考えると問題になります。 すべてのパスがチームによってテストされている可能性がありますが、完全なテストの発生は不可能です。 ソフトウェア開発ライフサイクル中にテストチームやクライアントによって実行されることは決してなく、プロジェクトの展開後に実行される可能性のあるシナリオもあります。

神話5：テスト済みのソフトウェアにはバグがない

現実-これは、クライアント、プロジェクトマネージャー、および管理チームが信じている非常に一般的な神話です。 優れたテストスキルを備えたテスターがアプリケーションをテストしたとしても、ソフトウェアアプリケーションが100％バグのないことを絶対確実に主張することはできません。

神話6：欠落した欠陥はテスターが原因

現実-テストを実行した後でもアプリケーションに残っているバグをテスターに​​責めるのは正しいアプローチではありません。 この神話は、時間、コスト、および要件を変更する制約に関連しています。 ただし、テスト戦略では、テストチームがバグを見逃す可能性もあります。

神話7：テスターは製品の品​​質に責任を負う

現実-テスターまたはテストチームのみが製品の品質に責任を持つべきであるというのは非常に一般的な誤解です。 テスターの責任には、利害関係者に対するバグの特定が含まれ、バグを修正するかソフトウェアをリリースするかは彼らの決定です。 その時点でソフトウェアをリリースすると、テスターはエラーのせいになるため、テスターに​​より多くの圧力がかかります。

神話8：時間を短縮するために、可能な限りテストオートメーションを使用する必要がある

現実-はい、テスト自動化によりテスト時間が短縮されるのは事実ですが、ソフトウェア開発中はいつでもテスト自動化を開始することはできません。 テストオートマトンは、ソフトウェアが手動でテストされ、ある程度安定しているときに開始する必要があります。 さらに、要件が変化し続ける場合、テストの自動化は使用できません。

神話9：誰でもソフトウェアアプリケーションをテストできる

現実-IT業界以外の人々は、誰でもソフトウェアをテストでき、テストは創造的な仕事ではないと考えています。 しかし、テスターはこれが神話であることをよく知っています。 代替シナリオを考えて、潜在的なバグを調査する目的でソフトウェアをクラッシュさせようとすることは、それを開発した人には不可能です。

神話10：テスターの唯一の仕事はバグを見つけること

現実-ソフトウェアのバグを見つけることはテスターの仕事ですが、同時に特定のソフトウェアの専門家でもあります。 開発者は自分に割り当てられた特定のコンポーネントまたは領域についてのみ責任を負いますが、テスターはソフトウェアの全体的な動作、依存関係、およびあるモジュールの別のモジュールへの影響を理解しています。

ソフトウェアテスト-QA、QC、テスト

テスト、品質保証、品質管理

品質保証、品質管理、テストの違いを突き止めるとなると、ほとんどの人は混乱します。 それらはある程度相互に関連していますが、同じアクティビティと見なすことができますが、それらを区別する際立ったポイントが存在します。 次の表に、QA、QC、およびテストを区別するポイントを示します。

Quality Assurance	Quality Control	Testing
QA includes activities that ensure the implementation of processes, procedures and standards in context to verification of developed software and intended requirements.	It includes activities that ensure the verification of a developed software with respect to documented (or not in some cases) requirements.	It includes activities that ensure the identification of bugs/error/defects in a software.
Focuses on processes and procedures rather than conducting actual testing on the system.	Focuses on actual testing by executing the software with an aim to identify bug/defect through implementation of procedures and process.	Focuses on actual testing.
Process-oriented activities.	Product-oriented activities.	Product-oriented activities.
Preventive activities.	It is a corrective process.	It is a preventive process.
It is a subset of Software Test Life Cycle (STLC).	QC can be considered as the subset of Quality Assurance.	Testing is the subset of Quality Control.

監査と検査

監査-組織またはチーム内で実際のテストプロセスがどのように実行されるかを決定する体系的なプロセスです。 一般的に、これはソフトウェアのテスト中に含まれるプロセスの独立した検査です。 IEEEによると、組織が実装して従う文書化されたプロセスのレビューです。 監査の種類には、法令遵守監査、内部監査、システム監査が含まれます。

検査-エラーまたはギャップを特定することにより、アーティファクトの正式または非公式の技術レビューを伴う正式な手法です。 IEEE94によると、検査は正式な評価手法であり、ソフトウェア要件、設計、またはコードを作成者以外の人またはグループが詳細に検査して、障害、開発標準の違反、およびその他の問題を検出します。

正式な検査会議には、計画、概要準備、検査会議、リワーク、フォローアップのプロセスが含まれる場合があります。

テストとデバッグ

テスト-修正せずにソフトウェアのバグ/エラー/欠陥を識別することを含みます。 通常、品質保証のバックグラウンドを持つ専門家がバグの特定に関与します。 テストはテスト段階で実行されます。

デバッグ-問題/バグの特定、分離、修正が含まれます。 ソフトウェアをコーディングする開発者は、コード内でエラーが発生するとデバッグを行います。 デバッグは、ホワイトボックステストまたは単体テストの一部です。 デバッグは、単体テストを実行している開発段階で、または報告されたバグを修正する段階で実行できます。

ソフトウェアテスト-ISO標準

世界中の多くの組織は、ソフトウェアの品質ニーズを改善するためにさまざまな標準を開発および実装しています。 この章では、品質保証とテストに関連して広く使用されている標準の一部について簡単に説明します。

ISO/IEC 9126

この標準は、ソフトウェアアプリケーションの品質を決定するために次の側面を扱います-

• 品質モデル
• 外部指標
• 内部指標
• 使用中のメトリックス

この標準は、次のようなソフトウェアの品質属性のセットを提示します-

• 機能性
• 信頼性
• 使いやすさ
• 効率
• 保守性
• 移植性

上記の品質属性はさらにサブファクターに分割され、標準を詳細に検討する際に検討できます。

ISO/IEC 9241-11

この規格の第11部では、指定されたユーザーが製品を使用して、指定された使用状況で有効性、効率性、満足度を指定した目標を達成できる範囲を扱います。

この標準は、ユーザビリティコンポーネントとそれらの間の関係を記述するフレームワークを提案しました。 この標準では、ユーザビリティはユーザーのパフォーマンスと満足度の観点から考慮されます。 ISO 9241-11によれば、使いやすさは使用のコンテキストに依存し、コンテキストが変わると使いやすさのレベルも変わります。

ISO/IEC 25000：2005

ISO/IEC 25000：2005は一般に、ソフトウェア品質要件と評価（SQuaRE）のガイドラインを提供する標準として知られています。 この標準は、ソフトウェア品質要件とその評価に関連するプロセスの編成と強化に役立ちます。 実際には、ISO-25000は2つの古いISO標準を置き換えます。 ISO-9126およびISO-14598。

*SQuaRE* は次のようなサブパートに分割されます-

• ISO 2500n-品質管理部
• ISO 2501n-品質モデル部門
• ISO 2502n-品質測定部
• ISO 2503n-品質要件部
• ISO 2504n-品質評価部

SQuaREの主な内容は次のとおりです-

• 用語と定義
• 参照モデル
• 一般的なガイド
• 個々の部門ガイド
• 要件エンジニアリングに関連する標準（つまり、 仕様、計画、測定、評価プロセス）

ISO/IEC 12119

この標準は、クライアントに配信されるソフトウェアパッケージを扱います。 クライアントの生産プロセスに焦点を当てたり、対処したりしません。 主な内容は、次の項目に関連しています-

• ソフトウェアパッケージの要件のセット。 *指定された要件に対して、提供されたソフトウェアパッケージをテストする手順。

その他

QAとテストプロセスに関連する他の標準のいくつかは以下に記載されています-

Sr.No	Standard & Description
1	IEEE 829* ソフトウェアテストのさまざまな段階で使用されるドキュメントの形式の標準。
2	IEEE 1061 品質要件を確立し、プロセスとソフトウェア品質メトリックの製品を特定、実装、分析、および検証するための方法論。
3	IEEE 1059 ソフトウェア検証および検証計画のガイド。
4	IEEE 1008 単体テストの標準。
5	IEEE 1012 ソフトウェアの検証と検証の標準。
6	IEEE 1028 ソフトウェア検査の標準。
7	IEEE 1044 ソフトウェア異常の分類の標準。
8	IEEE 1044-1 ソフトウェア異常の分類のためのガイド。
9	IEEE 830 システム要件仕様を開発するためのガイド。
10	IEEE 730 ソフトウェア品質保証計画の標準。
11	IEEE 1061 ソフトウェア品質のメトリックと方法論の標準。
12	IEEE 12207 ソフトウェアのライフサイクルプロセスとライフサイクルデータの標準。
13	BS 7925-1 ソフトウェアテストで使用される用語の語彙。
14	BS 7925-2 ソフトウェアコンポーネントテストの標準。

ソフトウェアテスト-テストの種類

このセクションでは、SDLC中にソフトウェアをテストするために使用できるさまざまなタイプのテストについて説明します。

手動テスト

手動テストには、自動化されたツールやスクリプトを使用せずに、ソフトウェアを手動でテストすることが含まれます。 このタイプでは、テスターがエンドユーザーの役割を引き継ぎ、ソフトウェアをテストして、予期しない動作やバグを特定します。 ユニットテスト、統合テスト、システムテスト、ユーザー受け入れテストなど、手動テストにはさまざまな段階があります。

テスターはテスト計画、テストケース、またはテストシナリオを使用してソフトウェアをテストし、テストの完全性を確認します。 テスターがソフトウェアのエラーを特定するために、手動テストには探索的テストも含まれます。

自動化テスト

テストの自動化とも呼ばれる自動化テストは、テスターがスクリプトを作成し、別のソフトウェアを使用して製品をテストする場合です。 このプロセスには、手動プロセスの自動化が含まれます。 自動テストは、手動、迅速、繰り返し実行されたテストシナリオを再実行するために使用されます。

自動化テスト

回帰テストとは別に、自動化テストは、負荷、パフォーマンス、ストレスの観点からアプリケーションをテストするためにも使用されます。 手動テストと比較して、テスト範囲が拡大し、精度が向上し、時間と費用が節約されます。

自動化するもの

ソフトウェアのすべてを自動化することはできません。 ログインフォームや登録フォームなど、ユーザーがトランザクションを実行できる領域、多数のユーザーが同時にソフトウェアにアクセスできる領域は自動化する必要があります。

さらに、すべてのGUIアイテム、データベースとの接続、フィールド検証など。 手動プロセスを自動化することで効率的にテストできます。

自動化するタイミング

テスト自動化は、ソフトウェアの次の側面を考慮して使用する必要があります-

• 大規模で重要なプロジェクト
• 同じ領域を頻繁にテストする必要があるプロジェクト
• 要件が頻繁に変更されない
• 多くの仮想ユーザーで負荷とパフォーマンスのためにアプリケーションにアクセスする
• 手動テストに関して安定したソフトウェア
• 時間の可用性

自動化する方法は？

自動化は、VBスクリプトや自動化されたソフトウェアアプリケーションなどのサポートコンピューター言語を使用して行われます。 自動化スクリプトを作成するために使用できる多くのツールがあります。 ツールに言及する前に、テストプロセスを自動化するために使用できるプロセスを特定しましょう-

• 自動化のためのソフトウェア内の領域の特定
• テスト自動化のための適切なツールの選択
• テストスクリプトの作成
• テストスーツの開発
• スクリプトの実行
• 結果レポートを作成する
• 潜在的なバグまたはパフォーマンスの問題を特定する

ソフトウェアテストツール

次のツールは、自動化テストに使用できます-

• HP Quick Test Professional
• セレン
• IBM Rational Functional Tester
• シルクテスト
• TestComplete
• どこでもテスト
• WinRunner
• ロードランナー
• Visual Studio Test Professional
• ワティル

ソフトウェアテスト-メソッド

ソフトウェアのテストに使用できるさまざまな方法があります。 この章では、使用可能な方法について簡単に説明します。

ブラックボックステスト

アプリケーションの内部動作に関する知識がなくてもテストする手法は、ブラックボックステストと呼ばれます。 テスターはシステムアーキテクチャを知らず、ソースコードにアクセスできません。 通常、ブラックボックステストの実行中、テスターは入力の処理方法や場所を知らずに入力を提供し、出力を調べることにより、システムのユーザーインターフェイスと対話します。

次の表に、ブラックボックステストの利点と欠点を示します。

Advantages	Disadvantages
Well suited and efficient for large code segments.	Limited coverage, since only a selected number of test scenarios is actually performed.
Code access is not required.	Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
Clearly separates user’s perspective from the developer’s perspective through visibly defined roles.	Blind coverage, since the tester cannot target specific code segments or errorprone areas.
Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language, or operating systems.	The test cases are difficult to design.

ホワイトボックステスト

ホワイトボックステストは、内部ロジックとコードの構造の詳細な調査です。 ホワイトボックステストは、*ガラステスト*または*オープンボックステスト*とも呼ばれます。 アプリケーションで*ホワイトボックス*テストを実行するには、テスターはコードの内部動作を知る必要があります。

テスターはソースコードの内部を見て、コードのどのユニット/チャンクが不適切に動作しているかを調べる必要があります。

次の表に、ホワイトボックステストの利点と欠点を示します。

Advantages	Disadvantages
As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.	Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased.
It helps in optimizing the code.	Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems, as many paths will go untested.
Extra lines of code can be removed which can bring in hidden defects.	It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and debugging tools.
Due to the tester’s knowledge about the code, maximum coverage is attained during test scenario writing.

グレーボックステスト

グレーボックステストは、アプリケーションの内部動作に関する知識が限られている状態でアプリケーションをテストする手法です。 ソフトウェアテストでは、フレーズを知っているほど、アプリケーションをテストする際の重みが大きくなります。

システムのドメインをマスターすることで、テスターは常に、ドメインの知識が限られている人よりも優位になります。 テスターがアプリケーションのユーザーインターフェイスのみをテストするブラックボックステストとは異なります。グレーボックステストでは、テスターは設計ドキュメントとデータベースにアクセスできます。 この知識があれば、テスターはより良いテストデータとテストシナリオを準備しながら、テスト計画を立てることができます。

Advantages	Disadvantages
Offers combined benefits of black-box and white-box testing wherever possible.	Since the access to source code is not available, the ability to go over the code and test coverage is limited.
Grey box testers don’t rely on the source code; instead they rely on interface definition and functional specifications.	The tests can be redundant if the software designer has already run a test case.
Based on the limited information available, a grey-box tester can design excellent test scenarios especially around communication protocols and data type handling.	Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested.
The test is done from the point of view of the user and not the designer.

試験方法の比較

次の表に、ブラックボックステスト、グレーボックステスト、ホワイトボックステストを区別するポイントを示します。

Black-Box Testing	Grey-Box Testing	White-Box Testing
The internal workings of an application need not be known.	The tester has limited knowledge of the internal workings of the application.	Tester has full knowledge of the internal workings of the application.
Also known as closed-box testing, data-driven testing, or functional testing.	Also known as translucent testing, as the tester has limited knowledge of the insides of the application.	Also known as clear-box testing, structural testing, or code-based testing.
Performed by end-users and also by testers and developers.	Performed by end-users and also by testers and developers.	Normally done by testers and developers.
Testing is based on external expectations - Internal behavior of the application is unknown.	Testing is done on the basis of high-level database diagrams and data flow diagrams.	Internal workings are fully known and the tester can design test data accordingly.
It is exhaustive and the least time-consuming.	Partly time-consuming and exhaustive.	The most exhaustive and time-consuming type of testing.
Not suited for algorithm testing.	Not suited for algorithm testing.	Suited for algorithm testing.
This can only be done by trial-and-error method.	Data domains and internal boundaries can be tested, if known.	Data domains and internal boundaries can be better tested.

ソフトウェアテスト-レベル

テストのプロセスにはさまざまなレベルがあります。 この章では、これらのレベルについて簡単に説明します。

テストのレベルには、ソフトウェアテストの実施中に使用できるさまざまな方法が含まれます。 ソフトウェアテストの主なレベルは次のとおりです-

• 機能テスト *機能しないテスト

機能テスト

これは、テストされるソフトウェアの仕様に基づいたブラックボックステストの一種です。 入力を提供することでアプリケーションをテストし、目的の機能に適合する必要がある結果を調べます。 ソフトウェアの機能テストは、完全な統合システムで実施され、指定された要件に対するシステムのコンプライアンスを評価します。

アプリケーションの機能をテストする際に関与する5つのステップがあります。

Steps	Description
I	The determination of the functionality that the intended application is meant to perform.
II	The creation of test data based on the specifications of the application.
III	The output based on the test data and the specifications of the application.
IV	The writing of test scenarios and the execution of test cases.
V	The comparison of actual and expected results based on the executed test cases.

効果的なテストの実践では、上記の手順がすべての組織のテストポリシーに適用されるため、ソフトウェアの品質に関しては組織が最も厳しい基準を維持することが保証されます。

単体テスト

このタイプのテストは、セットアップがテストケースを正式に実行するためにテストチームに引き渡される前に、開発者によって実行されます。 ユニットテストは、それぞれの開発者がソースコードの割り当てられた領域の個々のユニットで実行します。 開発者は、品質保証チームのテストデータとは異なるテストデータを使用します。

単体テストの目標は、プログラムの各部分を分離し、個々の部分が要件と機能に関して正しいことを示すことです。

単体テストの制限

テストでは、アプリケーションのすべてのバグをキャッチできません。 すべてのソフトウェアアプリケーションのすべての実行パスを評価することは不可能です。 単体テストの場合も同じです。

開発者がソースコードの検証に使用できるシナリオとテストデータの数には制限があります。 すべてのオプションを使い果たした後、ユニットテストを停止し、コードセグメントを他のユニットとマージする以外に選択肢はありません。

統合テスト

統合テストは、アプリケーションの結合部分が正しく機能するかどうかを判断するためのテストとして定義されます。 統合テストは、ボトムアップ統合テストとトップダウン統合テストの2つの方法で実行できます。

Sr.No.	Integration Testing Method
1	Bottom-up integration* このテストは、ユニットテストから始まり、モジュールまたはビルドと呼ばれるユニットの段階的により高度な組み合わせのテストが続きます。
2	Top-down integration このテストでは、最高レベルのモジュールが最初にテストされ、その後徐々に、下位レベルのモジュールがテストされます。

包括的なソフトウェア開発環境では、通常、ボトムアップテストが最初に行われ、続いてトップダウンテストが行​​われます。 プロセスは、できれば実際の状況を模倣するように設計されたシナリオで、完全なアプリケーションの複数のテストで終了します。

システムテスト

システムテストは、システム全体をテストします。 すべてのコンポーネントが統合されると、アプリケーション全体が厳密にテストされ、指定された品質基準を満たしていることが確認されます。 このタイプのテストは、専門のテストチームによって実行されます。

システムテストは次の理由で重要です-

• システムテストは、ソフトウェア開発ライフサイクルの最初のステップであり、アプリケーション全体がテストされます。
• アプリケーションは徹底的にテストされ、機能および技術仕様を満たしていることを確認します。
• アプリケーションは、アプリケーションがデプロイされる実稼働環境に非常に近い環境でテストされます。
• システムテストにより、ビジネス要件とアプリケーションアーキテクチャの両方をテスト、検証、および検証できます。

回帰試験

ソフトウェアアプリケーションに変更が加えられるたびに、アプリケーション内の他の領域がこの変更の影響を受ける可能性が非常に高くなります。 回帰テストを実行して、修正されたバグが別の機能やビジネスルール違反を引き起こしていないことを確認します。 回帰テストの目的は、バグ修正などの変更により、アプリケーションで別の障害が発見されないようにすることです。

次の理由により、回帰テストは重要です-

• 変更が加えられたアプリケーションをテストする必要がある場合、テストのギャップを最小限に抑えます。
• 新しい変更をテストして、変更がアプリケーションの他の領域に影響を与えなかったことを確認します。
• アプリケーションで回帰テストが実行されるときのリスクを軽減します。
• タイムラインを損なうことなくテスト範囲が拡大します。
• 製品の市場投入のスピードを上げます。

受け入れ試験

これはおそらく、アプリケーションが意図した仕様を満たし、クライアントの要件を満たしているかどうかを評価する品質保証チームによって実施されるため、最も重要なタイプのテストです。 QAチームには、アプリケーションのテストに使用される事前に作成された一連のシナリオとテストケースがあります。

アプリケーションについてより多くのアイデアが共有され、アプリケーションでより多くのテストを実行して、その精度とプロジェクトが開始された理由を評価できます。 受け入れテストは、単純なスペルミス、表面的なエラー、またはインターフェースのギャップを指摘するだけでなく、アプリケーションのシステムクラッシュや重大なエラーを引き起こすアプリケーションのバグを指摘することも目的としています。

アプリケーションで受け入れテストを実行することにより、テストチームは、運用環境でのアプリケーションの実行方法を削減します。 システムを受け入れるための法的および契約上の要件もあります。

アルファテスト

このテストはテストの第1段階であり、チーム（開発者およびQAチーム）の間で実行されます。 ユニットテスト、統合テスト、およびシステムテストを組み合わせた場合は、アルファテストと呼ばれます。 この段階では、次の側面がアプリケーションでテストされます-

• スペルミス
• 壊れたリンク
• 曇りの道順
• アプリケーションは、ロード時間と遅延の問題をテストするために、最も低い仕様のマシンでテストされます。

ベータテスト

このテストは、アルファテストが正常に実行された後に実行されます。 ベータテストでは、対象ユーザーのサンプルがアプリケーションをテストします。 ベータテストは、*プレリリーステスト*とも呼ばれます。 ソフトウェアのベータテストバージョンは、部分的にはプログラムに「現実の」テストを提供し、次のリリースのプレビューを提供するために、Web上の幅広い視聴者に理想的に配布されます。 このフェーズでは、聴衆は以下をテストします-

• ユーザーは、アプリケーションをインストールして実行し、フィードバックをプロジェクトチームに送信します。
• 誤植、混乱を招くアプリケーションフロー、さらにはクラッシュ。
• プロジェクトチームは、フィードバックを入手して、実際のユーザーにソフトウェアをリリースする前に問題を修正できます。
• 実際のユーザーの問題を解決する問題を修正すればするほど、アプリケーションの品質は向上します。
• 一般公開するときに高品質のアプリケーションを使用すると、顧客満足度が向上します。

非機能テスト

このセクションは、非機能属性からアプリケーションをテストすることに基づいています。 非機能テストでは、本来は機能しないがパフォーマンス、セキュリティ、ユーザーインターフェイスなどの重要な要件からソフトウェアをテストします。

重要で一般的に使用される非機能テストタイプのいくつかを以下で説明します。

性能試験

これは主に、ソフトウェアのバグを見つけるのではなく、ボトルネックやパフォーマンスの問題を識別するために使用されます。 ソフトウェアのパフォーマンスの低下に寄与するさまざまな原因があります-

• ネットワーク遅延
• クライアント側の処理
• データベーストランザクション処理
• サーバー間の負荷分散
• データレンダリング

パフォーマンステストは、次の側面の観点から重要かつ必須のテストタイプの一つとみなされます-

• 速度（つまり、 応答時間、データのレンダリングとアクセス）
• 容量
• 安定
• スケーラビリティ

パフォーマンステストは定性的または定量的であり、*負荷テスト*や*ストレステスト*などのさまざまなサブタイプに分けることができます。

負荷テスト

これは、ソフトウェアが大きな入力データにアクセスして操作するという点で最大負荷を適用することにより、ソフトウェアの動作をテストするプロセスです。 通常の負荷条件とピーク負荷条件の両方で実行できます。 このタイプのテストでは、ソフトウェアの最大容量とピーク時の動作を特定します。

ほとんどの場合、負荷テストは、Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio Load Testなどの自動化ツールを使用して実行されます。

仮想ユーザー（VUsers）は自動テストツールで定義され、ソフトウェアの負荷テストを検証するためにスクリプトが実行されます。 ユーザーの数は、要件に基づいて同時にまたは段階的に増減できます。

ストレステスト

ストレステストには、異常な状態でのソフトウェアの動作のテストが含まれます。 たとえば、一部のリソースを削除したり、実際の負荷制限を超えて負荷を適用したりすることが含まれます。

ストレステストの目的は、システムに負荷をかけ、ソフトウェアが使用するリソースを引き継いでブレークポイントを特定することにより、ソフトウェアをテストすることです。 このテストは、次のようなさまざまなシナリオをテストすることで実行できます-

• ネットワークポートのランダムなシャットダウンまたは再起動
• データベースをオンまたはオフにする
• CPU、メモリ、サーバーなどのリソースを消費するさまざまなプロセスを実行する

ユーザビリティテスト

ユーザビリティテストはブラックボックス技術であり、ユーザーの使用と操作を観察することにより、ソフトウェアのエラーや改善点を特定するために使用されます。

Nielsenによれば、使いやすさは5つの要素で定義できます。 使用効率、学習能力、記憶能力、エラー/安全性、満足度。 彼によると、製品の使いやすさは良好であり、システムが上記の要素を所有していれば使用可能です。

Nigel BevanとMacleodは、ユーザビリティはコンピューターシステムとの相互作用の結果として測定できる品質要件であると考えました。 適切なリソースを使用して目的の目標を効果的に達成できれば、この要件を満たし、エンドユーザーを満足させることができます。

2000年のMolichは、使いやすいシステムが次の5つの目標、つまり学習しやすく、覚えやすく、使いやすく、使いやすく、理解しやすいという5つの目標を達成する必要があると述べました。

ユーザビリティのさまざまな定義に加えて、ISO-9126、ISO-9241-11、ISO-13407、IEEE stdなどの属性およびサブ属性の形式でユーザビリティを定義する標準および品質モデルと方法がいくつかあります。 610.12など

UI対ユーザビリティテスト

UIテストには、ソフトウェアのグラフィカルユーザーインターフェイスのテストが含まれます。 UIテストにより、GUIが要件に従って機能し、色、配置、サイズ、およびその他のプロパティの観点でテストされることが保証されます。

一方、使いやすさのテストは、簡単に処理できる優れたユーザーフレンドリーなGUIを保証します。 UIテストは、ユーザビリティテストのサブパートと見なすことができます。

セキュリティテスト

セキュリティテストでは、セキュリティと脆弱性の観点から欠陥やギャップを特定するためにソフトウェアをテストします。 以下にリストされているのは、セキュリティテストで確認する必要がある主な側面です-

• 守秘義務
• 誠実さ
• 認証
• 可用性
• 承認
• 否認防止
• ソフトウェアは既知および未知の脆弱性に対して安全です
• ソフトウェアデータは安全です
• ソフトウェアはすべてのセキュリティ規制に従っています
• 入力チェックと検証
• SQL挿入攻撃
• 注入欠陥
• セッション管理の問題
• クロスサイトスクリプティング攻撃
• バッファオーバーフローの脆弱性
• ディレクトリトラバーサル攻撃

移植性テスト

移植性テストには、再利用性を確保し、他のソフトウェアからも移動できることを目的としたソフトウェアのテストが含まれます。 以下は、移植性テストに使用できる戦略です-

• インストールされたソフトウェアをあるコンピューターから別のコンピューターに転送する。
• さまざまなプラットフォームでソフトウェアを実行するための実行可能ファイル（.exe）の構築。

このテストタイプには、さまざまな環境での使用に関するソフトウェアの全体的なテストが含まれるため、移植性テストはシステムテストのサブパートの1つと見なすことができます。 移植性テストの主な焦点は、コンピューターハードウェア、オペレーティングシステム、およびブラウザーです。 移植性テストの前提条件の一部は次のとおりです-

• ソフトウェアは、移植性の要件を考慮して設計およびコーディングする必要があります。
• 関連するコンポーネントで単体テストが実行されました。
• 統合テストが実行されました。
• テスト環境が確立されました。

ソフトウェアテスト-ドキュメント

テストドキュメントには、ソフトウェアのテスト前またはテスト中に開発する必要があるアーティファクトのドキュメントが含まれます。

ソフトウェアテストのドキュメントは、必要なテスト作業、テスト範囲、要件の追跡/追跡などの見積もりに役立ちます。 このセクションでは、次のようなソフトウェアテストに関連する一般的に使用される文書化された成果物の一部について説明します-

• テスト計画
• テストシナリオ
• テストケース
• トレーサビリティマトリックス

テスト計画

テスト計画では、アプリケーションのテストに使用する戦略、使用するリソース、テストを実行するテスト環境、テストの制限、テストアクティビティのスケジュールの概要を説明します。 通常、品質保証チームリーダーがテスト計画の作成を担当します。

テスト計画には以下が含まれます-

• テスト計画ドキュメントの概要
• アプリケーションのテスト中の前提
• アプリケーションのテストに含まれるテストケースのリスト
• テストする機能のリスト
• ソフトウェアのテスト中にどのようなアプローチを使用するか
• テストする必要がある成果物のリスト
• アプリケーションのテストに割り当てられたリソース
• テストプロセス中に伴うリスク
• 達成すべきタスクとマイルストーンのスケジュール

テストシナリオ

これは、アプリケーションのどの領域がテストされるかを通知する1行のステートメントです。 テストシナリオを使用して、すべてのプロセスフローがエンドツーエンドでテストされるようにします。 アプリケーションの特定の領域には、アプリケーションの規模と複雑さに応じて、1つのテストシナリオから数百のシナリオまでを含めることができます。

「テストシナリオ」と「テストケース」という用語は同じ意味で使用されますが、テストシナリオには複数のステップがあり、テストケースには単一のステップがあります。 この観点から見ると、テストシナリオはテストケースですが、いくつかのテストケースと実行する必要があるシーケンスが含まれています。 これとは別に、各テストは前のテストの出力に依存しています。

テストシナリオ

テストケース

テストケースには、テストタスクの実行中に使用できる一連のステップ、条件、および入力が含まれます。 このアクティビティの主な目的は、ソフトウェアの機能やその他の面でソフトウェアが成功するか失敗するかを確認することです。 機能的、否定的、エラー、論理的テストケース、物理的テストケース、UIテストケースなど、多くのタイプのテストケースがあります。

さらに、テストケースは、ソフトウェアのテスト範囲を追跡するために作成されます。 一般に、テストケースの作成中に使用できる正式なテンプレートはありません。 ただし、次のコンポーネントは常に利用可能であり、すべてのテストケースに含まれています-

• テストケースID
• 製品モジュール
• 製品バージョン
• 改訂履歴
• 目的
• 仮定
• 前提条件
• ステップ
• 期待される結果
• 実際の結果
• 事後条件

多くのテストケースは、単一のテストシナリオから派生できます。 さらに、テストスイートと総称される単一のソフトウェアに対して複数のテストケースが記述される場合があります。

トレーサビリティマトリックス

トレーサビリティマトリックス（要件トレーサビリティマトリックス-RTMとも呼ばれる）は、ソフトウェア開発ライフサイクル中に要件をトレースするために使用されるテーブルです。 フォワードトレースに使用できます（つまり、 要件から設計またはコーディングまで）または逆方向（つまり、 コーディングから要件へ）。 RTMには多くのユーザー定義テンプレートがあります。

RTMドキュメントの各要件は、関連するテストケースにリンクされているため、前述の要件に従ってテストを実行できます。 さらに、バグIDも含まれ、関連する要件とテストケースにリンクされています。 このマトリックスの主な目標は次のとおりです-

• 上記の要件に従ってソフトウェアが開発されていることを確認してください。
• バグの根本原因を見つけるのに役立ちます。
• SDLCのさまざまなフェーズで開発されたドキュメントをトレースするのに役立ちます。

ソフトウェアテスト-推定手法

テストに必要な労力を見積もることは、SDLCの主要かつ重要なタスクの1つです。 正確な推定は、最大のカバレッジでソフトウェアをテストするのに役立ちます。 このセクションでは、テストに必要な労力を見積もるのに役立ついくつかの手法について説明します。

機能点分析

この方法は、次のカテゴリを持つソフトウェアの機能的なユーザー要件の分析に基づいています-

• アウトプット
• お問い合わせ
• 入力
• 内部ファイル
• 外部ファイル

テストポイント分析

この推定プロセスは、ブラックボックスまたは受け入れテストの機能点分析に使用されます。 この方法の主な要素は、サイズ、生産性、戦略、インターフェイス、複雑さ、および均一性です。

Mark-IIメソッド

これは、エンドユーザーの機能ビューに基づいて推定値を分析および測定するために使用される推定方法です。 Mark-IIメソッドの手順は次のとおりです-

• 視点を決める
• カウントの目的とタイプ
• カウントの境界を定義する
• 論理トランザクションを特定する
• データエンティティタイプの特定と分類
• 入力データ要素タイプをカウントする
• 機能サイズを数える

その他

次のような他の一般的な推定手法を使用できます-

• Delphiのテクニック
• 類推に基づく推定
• テストケース列挙ベースの推定
• タスク（アクティビティ）ベースの推定
• IFPUGメソッド