こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。
最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。
とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。
- 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？
- 本職のテスト（QA）エンジニアの方はどのようなツールやサービスを利用されて、テストケースを作成しているのだろう？
このような疑問を持っている方には、「ソフトウェアテスト技法ドリル 第2版 テスト設計の考え方と実際」があっていると思います。
著者の秋山様はJSTQBなどの委員などとしてもご活躍されており、ソフトウェアテストに関するシンポジウムなどでも非常にためになる情報発信をしてくださっています。
また、Noteでも非常に有用な記事を書いてくださっていて、これらを見るだけでも面白いです。
本書の概要
本書では「ドリル」と記載いただいているように、例題や演習問題を解きながらテスト技法や設計について学習することができます。
以下書籍の目次ですが、章ごとにどのような視点を持ちながら、技法を適用してテスト設計をしていくかということを学べます。
- 第１章 点に注意を向ける
- 第２章 線を意識する
- 第３章 面で逃がさない
- 第４章 立体で捉える
- 第５章 時間を網羅する
- 第６章 多次元の品質
なんかバグや設計の不備を捉える次元というか、視点が広がっていく感じがして面白いですよね？
実際に各章ではテスト技法や考え方が書いてあるのですが、単に問題文に書いてある仕様のとおりにツールを使うのではなく、「どんなふうにして整理しておかないとこういうところが抜けちゃうよ？」といったメッセージがあると感じています。
第１章 点に注意を向ける
ここでは「ピンポイントテスト」と呼ばれるような狙い撃ちをテストしていく観点などから説明してくださいます。
「怪しいところ」を導くために三色ボールペンで仕様書のようなドキュメントを整理・書き込みしていく手法とともに、使用に対して具体的なデータを割り当てて考えていくためのノウハウが記載されています。（与えられる入力Nに対して、じゃあどういう観点で実例を考えていくか）
バグ発生のメカニズムを想像、蓄積していくためのトレーニングについても述べられているなど、これ以降の章を読み進めるための土台だと感じています。
個人的に、実例マッピングという考えのように、曖昧な仕様や基準に対して「じゃあ5なら？」「-1は？」というように深掘りしていくことの重要性をあらためて感じました。
第２章 線を意識する
ここでは、テスト技法の入門書などでもよく出てくる同値分割法や境界値分析といった技法について例題を解きながら学べます。
例えば以下のようなコードを見た時に、「こういう分岐とかの境界周りでよくバグって起きるよね。だったら、そのあたりを狙ってテストしようね」というのが基本的な考え方だと思います。
// 10000000以下なのか、「より小さい」なのかの誤解もよくありそう
// 10000000が「おこだよ」の境界値
if ( salary <= 10000000 ) {
return "おこだよ"
}
// 10000001が「いいね！！」の境界値
return "いいね！！"
// その他、「salaryは正の整数？」とか「なぜこの数字なのか？設計の意図は？」という他の問題になりそうなところにも想像が働きそうその他にも「パスワードのバリデーション」といった文字列の際にも、境界値という考えが使えるなど非常に勉強になります。
なお、境界値分析や同値分割法の学習をされたい方には、以下の書籍に問題が充実しているためこちらもおすすめです。
第３章 面で逃がさない
個人的に最も面白い章で、テスト技法の名前を上げると以下のようなことを例題を通して学べました。
- ドメイン分析テスト
- クラシフィケーションツリー技法
- デシジョンテーブル
- 原因結果グラフ
- CFD法
このあたりまで来ると、複数の変数や入力により振る舞いや結果が変わる機能に対するテストという意識が高くなっているようです。
一見上の技法の名前だけ見ると「うっ」となるかもしれませんが、著者が都度「特に複数の変数が数式で結ばれているような場合に有効」といったアドバイスを添えてくださるので、どのような場面で技法を利用できるのかとてもわかりやすいです。（私のようなロジックを書く側の人間にもフレンドリーです）
第４章 立体で捉える
この章では、先にも紹介した「ソフトウェアテスト技法練習帳」にも登場する「組み合わせテスト」に該当する以下のような技法を学習できます。
- HAYST法
- ペアワイズ
3章で出てきたようなデシジョンテーブルのテストでは、以下のように条件に対して（基本としては）すべての組み合わせを列挙してテストケースを作成します。
しかし、これではパラメーターが増えるほどに指数関数的に結果が増えていくことになってしまいます。
競技プログラミングの世界においても、2**30 ともなれば数秒以内に終わらせることは難しい状況が多いため、極力計算量が爆発するようなアルゴリズムは避けて行く必要があります。
（ちなみに、2**60の計算量ともなると数十年単位での時間が必要になると書籍で読んだことがあります）
そこで、「少ないテストケース数としつつも、単パラメーターではなく複数のパラメーター組み合わせて効率よくテストする方法」を考えていく必要があるのですが、この章で出てくる技法が役に立ちます。
ペアワイズテストなどはAll-Pairs法とも呼ばれていると思いますが、GIHOZ等のサービスでも気軽に試すことができるので非常におすすめです。
第５章 時間を網羅する
ここでは、開発者おなじみの状態遷移図を活用したテスト技法について学べます。
- 状態遷移表
- Nスイッチカバレッジ
- 並列処理テスト
以下の資料を合わせて読むと、更に理解が深まると思います。
私は「待機中とか起動中とかの状態なら状態遷移テスト使えそうだけど、起動中（28度）、起動中(29度） とかいうふうにコロコロ内部の変数が変わるような場合はどうすればよいの？」などと考えていたのですが、本書籍と演習問題の解答例を見ることで、疑問に答えていただいたような気持ちになりました。
第６章 多次元の品質
最後の章では以下のようなテストに対する観点や考え方を解説してくれています。
- シナリオテスト
- 例外シナリオ
- 受け入れテスト
- 探索的テスト
「シナリオテスト」って雰囲気でやってませんか？私は「いいえ」とはいえません。
例えば、これまでの組み合わせテストでも見てきたようなことを浅いシナリオに落とし込んで、同じようなテストをしてしまっている時もありました。
本書では「抽象的でなく具体的に記述」というわかりやすい言葉をいただきつつ、非常に具体的な例を上げてくれるため、「シナリオテストってここまで掘り下げて良いのか。むしろ掘り下げるべきなのか」と背中を押していただきました。
まとめ
まさにテストのプロフェッショナルが、「どんな考えで」「どうやって」テストを考えるんだよ、ということを問題を解きながら教えてくれる書籍についてご紹介しました。
テストツールやAIによるテストなども今後どんどん進歩していくのではないかと思いますが、根本的な考え方を知っておかないとそれらが妥当なのかどうかも判断することができないと思います。
本書は特に「境界値分析」や「同値分割法」といった基本的な技法を知っている方には、それらを基本としつつも新しい観点を授けてくれるのではないかと思います。
ぜひ、もう少しソフトウェアテストの技法に Deep Dive したい方は、本書を読まれると良いと思います。
それでは、最後まで読んでいただきありがとうございました。
9
