インターン生が『知識ゼロから学ぶソフトウェアテスト』を読んで学んだこと
この記事は Money Forward Kansai Advent Calendar 2025 7日目の記事です
はじめに
インターンとして初めて開発現場に入ると、避けて通れないのが「テスト」です。
自分がインターンに参加した今年6月、研修課題で初めてテストコードを書いたときは、正直未知の領域という感覚でした。
とりあえず真似して書いてみるものの、
- どこまでテストすればいいのか
- どういう観点でケースを設計すべきなのか
- コードのどこにバグが潜みやすいのか
といった基準が分かっておらず、ずっと手探りの状態でした。
研修が終わって本番開発に携わるようになると、書いたばかりのコードで想定していないところでバグが見つかるなど、テストの重要性を身をもって痛感しました。
そんなタイミングで読んだのが『知識ゼロから学ぶソフトウェアテスト』です。
「単体テスト」「結合テスト」「E2E」などの単語だけ知っていた状況から、テストとはそもそもプロジェクトの中でどのような役割を担っているか、といったところからテストについて体系立てて理解できた一冊でした。
ここでは、自分が特に重要だと感じたポイントをまとめていきます。
テストとは「戦略」である
本書で最初に強調されていたのは、テストですべてのバグを検出することは不可能という事実です。
とはいえ、どんな領域にバグが入り込みやすいのか、どのテスト手法がどんな品質保証に向いているのかを理解することで、限られた時間でも高い効果を得られます。
つまり、テストは完璧を目指すのではなく、限られたリソースで最大の品質を確保するための戦略的活動であるということです。
ホワイトボックステストで学んだこと
ホワイトボックステストは、コード内部の論理構造を確認する強力なテスト手法です。
ただし本書では、ホワイトボックスでは仕様の誤りを検出できないという重要な弱点も指摘されています。
特に印象に残ったのが カバレッジ の扱い方でした。
- ブランチカバレッジは最低限見るべき指標
- しかし 100% を無理に目指す必要はない。80%が妥当な指標である。
- カバレッジテストで全てのバグを見つけることはできない。
など、現実的なテスト設計の考え方が分かりやすく説明されています。
ブラックボックステストの基礎と使い分け
ブラックボックステストでは、ソースコードを見ることなく、プログラムの振る舞いを
- 入力
- 計算
- データ保存
- 出力
という 4 つの観点で検証します。
本書で紹介されていた代表的な技法は以下の通りです。
- ** ディシジョンテーブル **
複雑な条件分岐を整理し、必要なパターンを漏れなく洗い出す。 - ** 境界値分析 **
バグが潜みやすい境界部分に注目して効率よくテストする。 - ** 状態遷移テスト **
UI やマルチステートな機能に適した手法。
章末には、レビュー・テスト種類ごとのバグ検出率がまとめられており、
「テスト手法を組み合わせる意味」
が数値で理解できる内容でした。
探索的テストの重要性
仕様が曖昧だったり、頻繁に変わるような環境では、事前にテストケースを完璧に整えるのは現実的ではありません。
そこで有効なのが 探索的テスト です。
- 理解
- 設計
- 実行
を短いループで繰り返しながら、気づいたポイントをその場で広げていくテスト手法で、アジャイル開発と相性が良いと感じました。
特に興味深かったのは、「スキルのある担当者による探索的テストは非常に強力」と明記されていた点です。ただ自由に触るのではなく、深い理解と経験があるからこそ効果が出る手法だということが分かりました。
非機能要求テスト（パフォーマンス・セキュリティ・信頼性）
非機能要求テストについて、パフォーマンステスト・セキュリティテスト・信頼性に対するテストの3つの視点から難しさと重要性が整理されていました。
これらの非機能要件のテストが複雑になるのは以下の理由です。
- 機能要求と違って、アーキテクチャ設計をしてそれをソースコードに落とし込むという流れがないので、バグが見つかってもアーキテクチャの問題なのか、もしくは非機能要求の仕様定義の問題なのかなど、どのレイヤーによるバグなのかがわからない。
それによって非機能要求テストはそれぞれの非機能要求に対してアプローチが異なります。
- パフォーマンステストは後ろ倒しにすると対処コストが跳ね上がる
- セキュリティテストには万能な手法が存在しない
- 信頼性は定量指標（MTBF・信頼度成長曲線）で評価する必要がある
さらに複雑な非機能品質のトレードオフが存在するのも非機能要件テストの特徴です。
機能要件を担当することが多い自分にとって、品質を保証するために非機能要件に対して多様なテスト手法が存在するという点は新しい視点で、興味深く感じました。
テスト自動化のリアルについて
自動テストは華やかで便利なイメージがありますが、本書では“目的はあくまでコスト削減”であり、自動化に向くテストに対してメンテナンスコストを考慮しながら慎重に自動化設計戦略を立てなければいけないと強調されていました。
たとえば、
- 出番の少ない機能を自動化するのは逆効果
- 安定・反復可能な領域こそ自動化が効く
- 頻繁に変わる UI の自動化はコストに見合わない
といった判断軸が示されています。
テスト運用について
テストには費用がかかります。一方で不具合の回収にはもっと大きなコストがかかります。
このコストと品質のバランスをどう取るかがテスト運用の本質だと説明されていました。
また、テストプランの作成方法については IEEE829 で示されているテストプランテンプレートをベースに、実務で意識すべきポイントが丁寧に書かれています。
品質管理にはメトリックスを使用しよう
テストは成果が目に見えにくく、感覚だけで判断すると「十分できているのか」「改善が必要なのか」が分かりづらい領域です。
そのため、本書では メトリクス（定量指標）を使って品質を可視化する重要性について最初に触れられていました。
紹介されていたメトリクスは幅広く、実際の開発でも意識できるものでした。
- バグメトリクス（バグ件数と修正時間について など）
- コードメトリクス（コード行数と複雑度 など）
- アジャイルメトリクス（特に実践的に使える指標が多い）
- 顧客満足度
- MTTR
- Four Key Metrics（デプロイ頻度、変更リードタイム、MTTR、変更失敗率）
おわりに（感想）
読み終えて最も強く感じたのは、テストは単なるチェック作業ではないということです。
- 20% のモジュールが 80% のバグを生む
- すべてをテストするのは不可能
- 効果的な設計とレビューが品質の鍵
こうした知見は、単に「テストコードを書く力」だけではなく、開発全体を俯瞰して考える視点を与えてくれました。
本書ではあまり触れられなかったトピックとして、個人的には AI 時代のテスト戦略 が今後どう変わるのかにも興味があります。
AI が単体テスト生成やコードチェックを担うようになり、テスト運用や戦略のあり方そのものが変化していくはずです。
また、本記事で紹介したポイントは本書のごく一部です。
自分のような開発プロジェクトに入って日の浅いエンジニアがテストの全体像を短期間で掴むのに非常に良く、日々触れているような純粋なテスト手法について学べるのはもちろん、ソフトウェア開発という活動自体を多様な視点から見たい方にとっても、きっと得るものが多いと思います。
Discussion