ソフトウェアテストの簡単なガイド-標準とプロセス

「無実でテストされるまで、すべてのコードは有罪です」–未知の技術オタク。

厳密なテストを行わずに優れたソフトウェアを入手することはできません。 この記事では、より良い結果を出すために従うべきソフトウェアテストの標準とプロセスについて詳しく学びます。

ソフトウェアテストとは何ですか？

簡単に言えば、ソフトウェアテストはソフトウェアをより良くします。 これは、開発されたソフトウェアの正確性、完全性、および品質を識別するプロセスです。 テストは、クライアントに配信する前に欠陥/バグを発見し、ソフトウェアの品質を保証するため、重要です。 これにより、ソフトウェアの使用の信頼性が高まります。

ソフトウェアテスト段階

上記のソフトウェアテストの段階を見ていきましょう。

要件分析：

要件分析は、構築/変更されるソフトウェアアプリケーションに対するエンドユーザーの期待を定義します。 したがって、要件分析とは、ソフトウェアまたはシステムの要件を分析、報告、文書化、検証、および管理することを意味します。

テストエンジニアは、要件分析を完了するために次のタスクを実行する必要があります

• 各要件を読んで、完全性、明確性、あいまいさがある場合はそれを確認します。
• 要件分析フェーズで考えられるすべてのシナリオが検討されていることを確認し、カバーされていないすべてのケースまたはギャップを特定してみてください。
• チームが同じページにいることを毎日求めている要件分析から生じる質問や疑問についての議論。
• テスト対象のソフトウェアの完全な要件カバレッジを保証するには、要件トレーサビリティマトリックスを使用する必要があります。

以下は、RTM（要件トレーサビリティマトリックス）のサンプルテンプレートです。

クレジット：Opencodez

テスト計画：

テスト計画は、ソフトウェアアプリケーションでソフトウェアテストを実行するために必要なテストの目的、スケジュール、見積もり、成果物、およびリソースを説明するドキュメントです。 テスト計画は、テスト対象のアプリケーションの品質を検証するために必要な作業を理解および決定するのに役立ちます。 以下は、アジャイルテスト計画の例です。

クレジット：zenq

テスト設計：

テスト設計は、テストに必要なユースケースを設計するフェーズです。 テスト設計は、テスト計画に基づいて実行されます。 設計されたテストケースは、ソフトウェアアプリケーションのすべての要件をカバーするように作られています。 すべての要件のギャップをカバーするために、トレーサビリティマトリックスを使用したテストケースのマッピングも必要であると考えられます。

以下のテスト設計手法に基づいて設計されたテストシナリオ/テストケースは、ハッピーパスおよびネガティブシナリオテストの完全なテストカバレッジを保証します。

• 境界値分析（BVA）
• 等価分割（EP）
• ユースケーステスト
• 影響ベースのテスト

以下は、サンプルのテストデザインテンプレートです。

クレジット：https：//www.softwaretestingclass.com/

テスト環境のセットアップ：

テスト環境は、ソフトウェアアプリケーションでテストケースを実装および実行するために構築されたプラットフォームです。 テスト用の環境は、必要なネットワーク構成と必要な設定に加えて、必要なハードウェアとソフトウェアを統合することによって作成されます。 テストを開始する前に、テスト環境の実現可能性を確認するために、テスト環境でスモークテストを実行することが常に重要です。

テストの実行：

テストの実行は、設計されたテストケースを実行し、期待される結果と実際の結果を文書化して比較するプロセスです。 リスクを考慮したテスト実行では、以下の要素が考慮されます。 このサイクルで実行するテストスイートのサブセットを選択し、それぞれのテスター/品質アナリストに割り当てます。

• テストの実行は、テスト計画に従って設計されたテストケース/テストシナリオに基づいて実行されます
• 所見-テスト実行中に遭遇したそれぞれのJIRAチケットに文書化されています
• それぞれのJIRAチケットのテスト証明ドキュメントは次のもので構成されています

◦テストステータス： PASS / FAIL -JIRAチケットのテストステータスを示します

◦テストURL：特定の要件のテストに使用されるテストデータで構成されます

◦テストシナリオとそのスクリーンショット

• 正気度と回帰-正気度と回帰テストは、UAT前のテスト手段の一部として、すべてのスプリント終了時に定期的に高等環境（STG）で実行されます。

テストクロージャ：

スプリントテストの終了チェックリストでは、複数のスプリント間のスムーズな移行のために、すべてのスプリントの最後に次のアクティビティが実行されていることを確認します。

• 完全なカバレッジでタイムラインに従って完了した機能テスト
• チームによってログに記録され、対処されたすべての観察結果
• 欠陥として記録され、それぞれのチケット所有者に割り当てられた有効な観察結果
• チケットごとに更新されたテストプルーフドキュメントと、それぞれの手動テストおよびデバイステストの結果
• コードが上位の環境にマージされる前に、テスト環境で実行される回帰テスト。 この場合、DevからSTGへ

デバイステスト/クロスブラウザテスト：

デバイス/クロスブラウザテストは、デバイス/ブラウザの品質をテストして、開発された要件をどの程度満たしているかを確認するプロセスです。 デバイス/クロスブラウザのテストは、お客様が確認した以下のデバイス/ブラウザのリストでカバーされています。 デバイステストのプラットフォームとして使用されるブラウザスタック。

さまざまな種類のソフトウェアテスト

ユニットテスト：

単体テストでは、コードの小さな単位をチェックして情報を早期に配信し、テスト戦略をスピードアップし、不要なテストサイクルを削減します。 単体テストは通常​​、コードがソフトウェアテストチームに渡される前に開発者によって実行されます。

スモークテスト：

スモークテストは、展開されたソフトウェアが安定しているかどうかを判断するソフトウェアテスト手順です。 スモークテストは、テストチームがさらにソフトウェアテストを進めるための確認です。 これは、ソフトウェアの機能をテストするために各ビルドで実行する最小限のテストセットで構成されています。

統合テスト：

統合テストは、システムの動作をチェックするために、統合されたハードウェアおよびソフトウェア環境で実行されるテストの一種として定義されます。 ソフトウェア/ハードウェアコンポーネントは統合され、完成したシステムがテストされるまで段階的にテストされます。

システムテスト：

完全に統合されたソフトウェア製品のシステムテスト。 納品された製品が要件文書に記載されている要件仕様を満たしていることを確認するための最終テストです。 機能要件と非機能要件の両方を範囲内で検討する必要があります。

回帰試験：

リグレッションは、最近のコード変更が既存の機能を変更または破壊しないことを確認します。 回帰テストには、サブセット/完全回帰の両方が含まれ、両方とも手動または自動のテストシナリオでカバーできます。

ユーザー受け入れテスト（UAT）：

ユーザー受け入れテストは、ソフトウェアテストのライフサイクルの最終段階の1つであり、ソフトウェアが徹底的にテストされた後にクライアントによって実行されます。 UATは、製品のエンドユーザーが製品リリースの承認と展開のために実施します。