『知識ゼロから学ぶソフトウェアテスト』読んだ

知識ゼロから学ぶソフトウェアテスト改訂版: アジャイル・クラウド時代のソフトウェアテスト

作者:高橋寿一
翔泳社

チームに一人目のQAエンジニアを迎え入れるにあたり、自分もQAを体系的にインプットせねばということで、読んでみた。

デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developersというスライドにあるソフトウェアテスト読書マップを参考にした。

「テストによって全てのバグを見つけることは不可能」、「リリース後に見つかるバグは、要求の時点で見つかるの100倍修正コストがかかる」など抽象レイヤーで意識すべきこと、なんとなく意味は分かってる「ホワイトボックステスト」「ブラックボックステスト」の詳細や、はじめてきく「探索的テスト」の有用性など具体についてもバランスよく理解できた。まさにタイトル通り知識ゼロから学ぶのに適した1冊だなという印象。

以下、メモ

ホワイトボックステスト

ホワイトボックステスト = プログラムの論理構造が正しいかを解析するテスト
ウォーターフォール時代は、「開発者はホワイトボックステストで網羅率を担保、終わったらテスト担当者がブラックボックステストでバグをみつける」だった
アジャイルではそういった分断がなく、今後はテスト担当者もホワイトボックスを理解し、てすとkとしての限界を把握し、短いイテレーションでのテスト戦略を開発者と一緒に考える作業が重要になってくる
ホワイトボックステストは論理構造の正しさの担保なので、仕様そのものが間違っていることから起こるバグは発見できない
- よって、ホワイトボックスだけでテストを終わらせることはできない
- ホワイトボックスとブラックボックスの優劣の優劣を比較することはほとんど意味がない
制御パステスト
1. ステートメントカバレッジ
2. ブランチカバレッジ
カバレッジ基準
- ざくり、80％を目指す
  - 80％以上は、網羅率を上げるコストが一気に大きくなる

ブラックボックステスト

プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せずに（見ずに）テストを行う手法
3つの手法
1. 境界値テスト
  1. 基本中の基本
2. ディシジョンテーブルテスト
3. 状態遷移テスト
どうやってやるか
- まず境界値テスト
- 複数フォームがあれば、ディシジョンテーブルテスト
- さらに、ダイアログ遷移があれば、状態遷移テスト

探索的テスト

上記「テストケースベース」のテストに加え、探索的テストを行うことでより多くのバグ発見につながる
テスト設計・実行を同時にやる
vs テストケースベーステスト
テストケースベースより多くのバグを発見できる
- テストケースから見つかるのは全体の3％以下
- → であれば、テストケースをいちいち事前に書くよりさっさとテストしながら考えて実行しちゃおうよ、という結論
テスト設計・ケース作成を早い段階でやりすぎると、序盤の作業が無駄になるリスクが大きい
テスト実行しながら、どこか他にバグが起こりやすい箇所を見つけて、弱い箇所を見つけたらそこを重点的にテストすることが大事
- テストケースベースだと、これがやりづらい
探索的テストもテストケースベーステストも、網羅率は同じ
- ほんとに？とは思う
さらに、テスト担当者に開発者がプログラム構造を説明すると、探索的テストの網羅率が跳ね上がる
- 探索的テスト＋スキルのあるテスト担当者の最強コンビでは、短時間で効果の高いテストが実施できる