開発の基本概念

テスト（ソフトウェアテスト）てすと

ソフトウェアテストバグ品質保証ユニットテストテスト駆動開発デバッグ

テストについて教えて

簡単に言うとこんな感じ！

ソフトウェアテストは、作ったシステムが「ちゃんと動くか確認する作業」だよ！新車を出荷前に試乗チェックするのと同じで、バグ（不具合）を見つけて直してから世に出すんだ。テストが甘いと、リリース後にトラブルが起きて大慌て…なんてことになるから、開発の命綱ってこと！

ソフトウェアテストとは、開発したシステムやプログラムが仕様どおりに正しく動作するかどうかを確認する工程のことです。単純に「動くかどうか」を確認するだけでなく、「想定外の操作をしたときに壊れないか」「性能は十分か」「セキュリティ上の穴がないか」なども検証します。

テストは開発プロセスの中で非常に重要な位置を占めており、リリース前に問題を発見・修正するコストは、リリース後に対応するコストの数十倍も安いと言われています。つまり、テストに投資することは、後々の損失を防ぐための保険と考えることができます。

発注者やビジネス側の立場から見ると、「テスト計画書」「テスト仕様書」「バグ管理票」といった成果物が適切に用意されているかを確認することが、システムの品質を守るうえで非常に重要なチェックポイントになります。

ソフトウェアテストには、目的や対象範囲によって複数の種類があります。一般的にはテストピラミッドという考え方で整理されます。

テストの種類	別名・説明	主な実施者	タイミング
単体テスト（ユニットテスト）	関数・クラス単位の動作確認	開発者	コーディング中〜後
結合テスト（統合テスト）	複数のモジュールを組み合わせて確認	開発者・QA	単体テスト完了後
システムテスト	システム全体が仕様を満たすか確認	QAチーム	結合テスト完了後
受け入れテスト（UAT）	発注者・ユーザーが実際に使って確認	発注者・ユーザー	リリース直前

また、何を確認するかという観点では以下のように分類されます。

        ／＼
       ／E2E＼       ← 少ない（時間・コストがかかる）
      ／──────＼
     ／  統合   ＼
    ／────────────＼
   ／  単体（ユニット）＼  ← 多い（速くて安い）
  ／──────────────────＼

「下に行くほど数が多く・速く・安い」が鉄則。単体テストをたくさん書いて、上に行くほど数を絞るのがコスパの良い設計です。

用語	意味
バグ（Bug）	プログラムの不具合・誤り
デバッグ	バグを見つけて修正する作業
テストケース	「この操作をしたらこうなるはず」という1つの確認シナリオ
テスト仕様書	テストケースをまとめたドキュメント
カバレッジ	コードのうちどれだけテストされたかの割合
リグレッション	修正によって別の箇所が壊れること（退行バグ）

1940年代後半 — コンピューター黎明期にグレース・ホッパーが実際の「バグ（虫）」をコンピュータの中に発見したエピソードが有名。ここからデバッグという言葉が広まった
1950〜60年代 — ソフトウェアが大規模化するにつれ、テストの重要性が認識され始める
1979年 — グレンフォード・マイヤーズが『ソフトウェアのテスト技法（The Art of Software Testing）』を出版。テストを体系化した先駆け的な書籍
1990年代 — オブジェクト指向の普及とともに、ユニットテストの概念が整備される
1999年 — ケント・ベックがテスト駆動開発（TDD）を提唱。「テストを先に書いてからコードを書く」という革新的な手法が広まる
2000年代〜 — JUnit（Java）、RSpec（Ruby）などのテストフレームワークが普及。自動テストが標準的な開発プロセスに
2010年代〜 — CI/CD（継続的インテグレーション/デリバリー）の普及により、コードをプッシュするたびに自動でテストが走る仕組みが当たり前になる

主要なテスト関連の手法・プロセスを整理します。

以下は、ウォーターフォール型開発とアジャイル型開発でテストがどの位置づけになるかを示した図です。

ウォーターフォール型では「実装が全部終わってからテスト」となりがちで、後半に問題が集中するリスクがあります。一方アジャイル型では、短いサイクルの中にテストを組み込み、問題を早期に発見・修正できます。