ソフトウェアテスト関連書籍を読んで Part1
記事を書くきっかけ
家にソフトウェアテストの書籍がかなり積読されており、このままでは買った意味がないと思い、書籍を読んでいく中での気づきを発信していこうと思い始めました。
今回のテーマ
高橋 寿一 著
『知識ゼロから学ぶソフトウェアテスト 改訂版 アジャイル・クラウド時代のソフトウェアテスト』
どんな本か
ソフトウェアテストがどのような役割を果たし、具体的にどのような方法が存在するのかわかりやすく解説した本である。
本のタイトル通り、ソフトウェアテストの入門書としての立ち位置であり、所々で先人たちの言葉や著者の経験談を交えて、ソフトウェアテストにどう向き合っていくかの指針を示す本であった。
想定する読者と難易度
ソフトウェアテストに携わる人全てに向けた本である。
ソフトウェアテストの種類やテストドキュメントの話など、実務にも活かせそうな考えが広く浅く書かれており、所々でソフトウェアテストの専門用語は登場するが、意味を調べても出てこない難解なワードはほぼないので、詰まることはないだろう。
ただ、プログラムを書いたことがない人にとって、ピンとこない話も出てくる。
ホワイトボックステストの話やテスト自動化の内容に触れてもピンとこないだろうし、私も言葉の意味は理解しているが、実務で触れていない領域もあり、存在だけ認知しているレベルである。
人によって未知の部分がそれなりにあるかもしれないが、この本で基本的なワードを覚えてしまえば、より専門的な書籍を読む際のハードルも多少は下がるので、ソフトウェアテストを一から学びたい人にとって一読する価値はある。
裏を返せば、ソフトウェアテストを深堀りした話はそこまで展開されないため、そこは予め頭に入れておいた上で読んでほしい。
気になった箇所
P10
ソフトウェアテストで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト技法をてきようすれば十分な品質を得られるかを知ることである
闇雲に数だけこなすテストをしても、ソフトウェアの品質を担保できるわけではない。
ソフトウェアテストの仕事をやり始めた時、「テストケースをたくさん作って実行すれば、不具合もたくさん出て、結果的に品質の高いソフトウェアになるのでは？」と思っていた。
しかし、それはあくまでソフトウェアテストに十分な予算と時間を目一杯投下できればの話で、実情は限られた予算と時間の中で、効率よく不具合を検出しないといけないと後々気付かされた。
「とりあえず数多くのテストケース作ったので、後は不具合出てください！！お願いします！！」というやり方では、仮にテストを行ったとしても数をこなしただけで、ユーザーが望むプロダクトになったかは判断できない。
テストはあくまで品質を保証する手段の1つで、テストだけ頑張れば万事良しではありません。
テストを行うことと同じくらい重要なのは、どんなテストを行うかを道筋を立てて考えることだと分かりました。
テストを行う前の段階で、ユーザーが期待するプロダクトはどんなものかを想像し、プロダクトにどんなリスクがあるとユーザーは不満を抱き、その不満を抱かせないためにどんなテストをすれば効率よくかつ重大な不具合が出せるのかを考えることが重要だと至りました。
テストケースの数で品質を担保すればいいじゃんという考えから、限られた資源の中で質の高いテストをどう実現していくか道筋を立て、検証してみることが良質なテストの第一歩と考えています。
P16
ソフトウェアテストという作業はプログラミングに負けず劣らず困難であり、かつ創造的な仕事です。よく「テストなぞ新人にやらせておけ」とか「プログラムができない人のやる仕事だ」などと耳にしますがとんでもありません。
ソフトウェアテストのような困難な仕事を、スキルの低い人に不完全な形で実施させ、それを製品として出荷するということは、その商品を使う顧客に大変な迷惑がかかります。
この引用の数ページ前にマイヤーズの三角形という有名なソフトウェアテストの演習問題があり、演習問題から導出したテストケースをプログラムで書いたものを見て、テストケースを作るのはプログラムを実装することと別の難しさがあると実感しました。
私も以前はテストは「プログラムが書けない人が行う開発工程の下流作業」という意識で仕事をしていました。
ただ、この本を読んだことでソフトウェアテストは専門的な知見がないと、品質の低いプロダクトが出来上がり、それを使ったユーザーの時間やお金が無駄になり、結果としてプロダクトを提供した会社の信頼が損なわれるリスクが生まれるということを学びました。
ソフトウェアテストは、ユーザーからの信頼を得るために必要なプロセスであり、専門的な知見や創造性が要求される仕事であると実感できました。
おまけ
ChatGPT 5 Thinkingにマイヤーズの三角形を解かせてみました。
回答をそのまま載せてみます。
マイヤーズの三角形の設問は以下の通りです。
最小セット（まずはこれで十分性を確保）
| ID | 入力 (a,b,c) | 期待結果 | 狙い |
|---|---|---|---|
| 1 | 5,5,5 | 正三角形 | 正三角形の基本 |
| 2 | 5,5,3 | 二等辺三角形 | 二等辺（同辺が先頭） |
| 3 | 5,3,5 | 二等辺三角形 | 二等辺（同辺が末尾）→順序不変性 |
| 4 | 4,5,6 | 不等辺三角形 | 代表的な不等辺 |
| 5 | 3,4,5 | 不等辺三角形 | 有名な直角三角形だが分類は“不等辺” |
| 6 | 1,2,3 | 三角形ではない | 退化（a+b= c）を弾く |
| 7 | 2,3,10 | 三角形ではない | 三角不等式違反（a+b < c） |
| 8 | 0,5,5 | 三角形ではない | 0を含む無効入力 |
拡張セット（堅牢性・境界・順序不変性の強化）
| ID | 入力 (a,b,c) | 期待結果 | 狙い |
|---|---|---|---|
| 9 | -1,2,3 | 三角形ではない | 負数の弾き |
| 10 | 0,0,0 | 三角形ではない | 全ゼロ |
| 11 | 1,1,2 | 三角形ではない | 退化（二等辺っぽく見えるが不成立） |
| 12 | 2,2,3 | 二等辺三角形 | 二等辺の最小級例 |
| 13 | 2,3,4 | 不等辺三角形 | 不等辺の最小級例 |
| 14 | 6,6,11 | 二等辺三角形 | “ほぼ退化”だが成立（しきい値確認） |
| 15 | 6,11,6 | 二等辺三角形 | 入力順を変えても同判定 |
| 16 | 7,8,9 | 不等辺三角形 | 一般例（順序未ソート想定） |
| 17 | 1_000_000_000,1_000_000_000,1_000_000_000 | 正三角形 | 大きい値（桁伸長の確認） |
| 18 | 1_000_000_000,1_000_000_000,1 | 二等辺三角形 | 大小差が極端でも成立 |
| 19 | 2_000_000_000,2_000_000_000,1 | 二等辺三角形 | 32bit境界を意識（加算安全性） |
| 20 | 2_147_483_647,2,2_147_483_646 | 不等辺三角形 | 最大級値での比較・ソート確認 |
こうしてみてみると、自分が考えたテストケースと生成AIが出力したテストケースを比較し、双方に足りない要素がないかチェックするのも、テストケースを作る際に活用できそうな気がします。
Discussion