はじめに
以下の記事はこの本の要約です。もっと詳しく知りたい方は以下の本の購入をお勧めします。この記事がQittaのガイドラインに違反するようだったら削除しますのでコメントで教えてください。
1章テストのプロセス
テスト is 何
「テストとは、テストされるソフトウェアの品質を測定して改善するためにテストウェアをエンジニアリングし、利用し、保守しながら同時並行的に進めるライフサイクルプロセスである」( GraigとJaskielの著書より)
ソフトウェア: Webアプリ、ゲーム、ロボット制御、データ解析、スマホアプリ
テストウェア: テストを支援するためのツールやアプリケーション全般のこと。例:) autify rspec cypress jest vitest capybara
pytest.....など (python javascript ruby以外ほぼやったことないのでごめんなさい。。)
ライフサイクル： ある製品やシステムが開発され、運用され、最終的に廃棄されるなどの一連の作業のこと。
「テストとは、テストされるWebアプリなどの品質を測定して、改善するためにCypressなどをツールを用いて、設計、保守しながら進める開発、運用されるもののことである。」
テスト設計の基本
「他の工業製品でも同じだが、ソフトウェアのテスト設計は製品そのものの初期設計と同じくらい困難な課題になる、ところが、ソフトウェア技術者はしばしばテストを付け足し扱いし、”安心”するためにテストケースを作成する。
しかし、それではソフトウェアの安全さについて僅かな保証しか得られない。テストの目的を改めて思い出すなら最小の時間と労直でほとんどのエラーを検出する可能性が最も高くなるように設計しなければならない」(Pressmanの著書より）
テストにつきまとう課題
- 適切にテストを行う時間が足りない
- テストする入力の組み合わせが多すぎる
- うまくテストする時間が足りない
- 各テストでの期待結果を決めるのが難しい
- 要件が存在しない、またはどんどん変化する
- 徹底的にテストをするには時間が足りない
- テストプロセスについてのトレーニングがない
- ツールの支援がない
- 上層部がテストについての理解がない、品質に対しての理解がない
このようなテストに対する課題があるから、たとえテストを書いていたとしても（テストを書くだけましかもしれないが）、テストは安心するためのテストケースを作成しているに過ぎない。正常系のテストを書くのだけではなく異常系のテストをしっかりと書き、エラーを検出するのを網羅した形にしなくてはいけないということ
ブラックボックステストとホワイトボックステスト
ブラックボックステストとは、要件や仕様に基づいて、テストを実施する戦略を指す。
一方で、ホワイトボックステストとは、テスト対象ソフトウェアの内部パス、構造、実態に基づいてテストする戦略を指す。
ブラックボックステストは入力と出力のみ、複数の関数やmethod,Class,コンポーネントを介していたとしてもその内部の処理は気にせず、期待する結果が得られるかどうかをテストする。
ホワイトボックステストは、ソフトウェアの最小単位である、関数やコンポーネント, method, classをテストすることを目的とします
テストにおける4つのレベルわけ
- 単体テスト
- 統合テスト
- システムテスト
- 受け入れテスト(UAT)
chatGptに聞いてみた
単体テスト
単体テストとは、ソフトウェアの最小単位であるユニット（関数やメソッドなど）をテストすることを目的としたテストのことです。単体テストでは、テスト対象のユニットを隔離して、そのユニットの動作が正しいかどうかを検証します。これにより、ユニット単位での動作が確認されるため、ユニット単位での品質を担保することができます。また、単体テストでは、開発者が自分の書いたコードをテストするための手がかりとなり、開発効率の向上につながるという利点があります。
統合テスト
統合テストとは、複数のモジュールやコンポーネントを組み合わせてシステム全体の機能をテストすることを目的としたテストのことです。統合テストでは、個々のモジュールが単体テストで正しく動作していることが前提となっています。統合テストは、モジュールの結合時に生じる問題や、システム全体の動作に関する問題を検出することができます。また、統合テストでは、システムの外部とのインタフェースや、複数のシステム間での相互運用性に関する問題も検出することができます。統合テストは、システムテストの前段階として行われることが多く、システムテストの前提条件となります
システムテスト
システムテストとは、システム全体の機能や性能をテストすることを目的としたテストのことです。システムテストでは、統合テストで発見された問題を含め、システム全体における問題やバグを検出することが目的となります。また、システムテストでは、ユーザーの視点からシステムの品質を確認することができます。例えば、ユーザビリティやセキュリティ、信頼性、パフォーマンス、耐久性などがテストの対象となります。システムテストは、通常、テスト環境において行われ、ユーザーが実際に使用する環境に近い状態でテストが行われます。テストケースやテストシナリオを用いて、システム全体の機能や性能が仕様通りに動作するかどうかを確認します。また、システムテストでは、非機能要件に関するテストも行われます。
単体 < 統合 < システム
受け入れテスト
受け入れテストとは、開発されたシステムが、ユーザーや顧客が求める要件や仕様を満たしているかどうかを検証するためのテストのことです。受け入れテストは、システムの開発が完了し、リリース前の最終段階で行われます。受け入れテストでは、通常、ユーザーや顧客が実際に使用する環境でテストが実施されます。
受け入れテストは、システムの品質を評価するために、機能要件や非機能要件などの観点から行われます。例えば、システムが要求された機能を満たしているかどうか、ユーザビリティが高いかどうか、セキュリティが確保されているかどうか、性能が要求されたレベルに達しているかどうかなどがテストの対象となります。また、受け入れテストでは、通常、テストケースやテストシナリオを用いて、実際のユーザーの操作やシステムの応答を再現することで、システムの検証が行われます。受け入れテストは、システムの品質を確認するだけでなく、ユーザーとのコミュニケーションの機会となり、システムの改善や要件の変更などについてのフィードバックを得ることができます。