【読書記録まとめ】ソフトウェアテストの教科書

以下の内容は、【この1冊でよくわかる】ソフトウェアテストの教科書を読んだ際の学びや気づきをまとめたものです。

目次

本書の概要
書籍紹介
Part1. ソフトウェアテストの基本
Part2. さまざまなテスト技法
Part3. テストドキュメントとモニタリング
まとめ

本書の概要

本書は、ソフトウェアテストの基本的な考え方から、テストのさまざまな技法、そしてテストドキュメントやモニタリング方法まで幅広く解説しています。チャプターごとの学びを記録していましたが、一冊を通じて自分が何を学んだのかを明確にしたいため、本記事で総括します。

書籍紹介

Part1. ソフトウェアテストの基本

Chap01. ソフトウェアテストとは？

学び

ソフトウェアテストの目的
- 単にバグを防止するだけでなく、ユーザの要求を実現するためにもテストは必要。
- 誤動作を防ぎつつ、ユーザが満足する機能を実装できているかを確認することが重要。
ソフトウェア品質（ISO/IEC 25010）
1. 機能適合性: ユーザが必要とする機能を満たしているか
2. 性能効率性: 限られたリソースでも高パフォーマンスを維持できるか
3. 互換性: 他のシステムやプラットフォームとの連携がスムーズか
4. 使用性: ユーザが直感的に使いやすいか
5. 信頼性: 安定して動作し、障害やエラーを最小限に抑えられるか
6. セキュリティ: 不正アクセスやデータ漏洩からユーザを守れるか
7. 保守性: 変更や修正が容易か
8. 移植性: 異なるプラットフォームや環境でも動作するか
狩野モデル
ユーザ満足と品質の関係を3つの品質要素で示すモデル。

品質要素充足した場合不充足だった場合

当たり前品質当たり前不満

一元的品質満足不満

魅力的品質満足仕方がない

テストにおいては、当たり前品質をしっかり担保することが重要。
Never, Must, Want
- Never: 絶対に起きてはいけない不具合。
- Must: 必ず実装すべき・確認すべき要件。
- Want: あれば嬉しいものの、優先度は下がる要件。

Chap01 感想

品質に対する解像度が上がり、日々の業務でも意識しやすいポイントが明確になった。

Chap02. ソフトウェア開発の流れとテスト工程

学び

テスト工程
1. 単体テスト: モジュール（最小単位）ごとの動作確認。
2. 統合テスト: モジュール同士の連携確認。
3. 機能テスト: 組み合わさったモジュールをひとつの機能としてテスト。
4. システムテスト: 要求定義どおりにシステム全体が動作するかを確認。
統合テストと機能テストの違い
- 統合テストはモジュール間の連携に焦点を当て、
- 機能テストはユーザ視点でひとつの機能が正常に動くかを検証する。

Chap02 感想

普段の業務で既に行っている工程ではあるが、定義を理解することでテスト漏れのリスクを減らせると再認識。

Chap03. ホワイトボックステストとブラックボックステスト

学び

制御フローテスト
- 単体テストを作成する際に役立つホワイトボックステスト手法。
- カバレッジレベル（文カバレッジ、デシジョンカバレッジ、複合条件カバレッジなど）を意識することで、テストの網羅度を高める。

Chap03 感想

テストケースを作るときはカバレッジを意識し、どこまで網羅するかを明確にすると効率が上がる。

Part2. さまざまなテスト技法

Chap04. 同値分割テスト・境界値テスト

同値分割テスト

値を有効値と無効値にグループ化し、それぞれの代表値をピックアップしてテスト。
連続的な値になるとは限らないので、境界値テストとは別に考える。

Chap04 感想

ホワイトボックステストの中でも重要な考え方。
生成AIを活用すれば、網羅的にテストケースを生成しやすくなるかもと感じた。

Chap05. デシジョンテーブルテスト

デシジョンテーブルテスト

複数条件の組み合わせによる動作を表にして、漏れを防ぐためのテスト手法。
条件が多いシステムだと意外に便利。

Chap05 感想

複雑なロジックに対応する際は有力な手段。
実務で見かける機会は少ないが、必要になったら読み返したい内容。

Chap06. 状態遷移テスト

学び

状態遷移図を作成して、どんな状態からどの状態へ移るのかを可視化する。
ハードウェア開発で馴染み深いが、複雑な業務フローを扱うソフトウェアでも有用。

Chap06 感想

ソフトウェア開発であまり用いられるイメージではなく、ザッと流し読みした。
必要性を感じ次第、また見返す。

Chap07. 組合せテスト技法

学び

組合せテスト: 複数の因子（機能や設定項目）を組み合わせてテスト。
2因子間網羅: 「大抵のバグは2つの要因の組み合わせで検出できる」という考え方。
All-Pairs法: 2因子間を効率的に網羅するためのテスト設計手法。ツール利用も可能。

Chap07 感想

効率を重視する現場ではAll-Pairs法が現実的。
大規模な組合せテストが必要になったときには思い出したい。

Chap08. テスト技法適用チャート

学び

本書では、悩みに応じてどのテスト技法を選べば良いかをチャート化している。
「テストが多すぎる → 組合せテスト技法の適用を検討」という流れで考えられる。
コードリーディングが大変なら状態遷移図やシーケンス図などの補助も有効。

Chap08 感想

現場の課題に合わせて柔軟にテスト技法を活用できるよう、本書を辞書的に参照すると良さそう

Part3. テストドキュメントとモニタリング

Chap09. テストドキュメントの作成

学び

なぜテストドキュメントを作るのか？
- チームでテストを進める場合、担当者が変わってもテストの目的や方法を共有する必要があるから。
- ドキュメントがないと、同じようなテストを繰り返したり、抜け漏れが発生しがち。

Chap09 感想

現場ではスプレッドシート管理が主流で、目的・手順が曖昧になりやすい。
本書の具体例は、チーム拡大時に役立ちそう。

Chap10. テストドキュメントの正しい書き方

Chap10 感想

大きな組織や長期開発になればなるほど、テストドキュメントの整備が必要。
今は少人数で管理できるが、将来的な拡大を視野に入れると、学んだ内容を押さえておきたい。

Chap11. テスト実施のモニタリング

学び

テスト実施の進捗や状況を把握するための手法。
重大なバグが出ていないか、期限内に終わるかなど、プロジェクト管理上のリスクを抑える。

今の現場

スプレッドシートで管理しているため、すぐに進捗を把握できている。
大規模化したらモニタリングのフローを検討したい。

Chap11 感想

小規模・短期プロジェクトの場合はそこまで必要性を感じないが、規模が大きくなるほど重要になるポイント。

まとめ

本書を通して、ソフトウェアテストの目的や品質観点の整理から、効率的なテスト技法、そしてチームでのテストドキュメント管理・モニタリングと、幅広く学べました。とくに「狩野モデル」「Never, Must, Want」の視点は業務でもすぐに活かしやすく、当たり前品質の視点は忘れないようにしたい。

品質は細かく分けると、たくさんの分類ができる。
全てを覚えることは大変だと感じ、まずは「不具合を減らすこと（Verification）」と「ユーザ要求を満たすこと（Validation）」の視点を持ち、日々テストを考えていきたい。