29号：テストは状況次第

≣概要

FLシラバスの「テストの7原則」の6つ目です。前回の原則5は、「殺虫剤のパラドックスにご用心」でした。テストデータやテストそのものをどんどん新しいものに更新していくこと、また、そうしてもすり抜けてしまったバグを分析してテストに反映しようということと私は理解しています。

さて、今回の原則6の「テストは状況次第」ですが、この原則は、原則名である「テストは状況次第」という文だけでは、真意がなかなか伝わらないかもしれません。「『状況』ってなに？」と思うでしょうし、「状況」の意味が分かったとしても、「状況」の分析をしっかり実施してからテストを行っている現場は少ないからです。
多くの組織では、「テストは開発全体の20%くらいの期間でいいよね？　前回もそれで何とかなったし。」というような「政治的な力関係」で外堀が埋められ、気が付いたらテスト終了日や予算が決まっていて、そこから逆算してどんなテスト（内容）をするのがベストなのかを考えているようです。そういった仕事の進め方をしている人ほど、この原則を噛みしめてほしいです。
結論は、「テストのアウトプットに求められているものを知り、それをもとにテストしましょう」ということです。

≣ シラバスの記載

『ISTQBテスト技術者資格制度　Foundation Level シラバス 日本語版 Version 2018.J02』の該当部分を引用します。

6.テストは状況次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1節を参照）。

≣ 解説（全体）

何を作るのか（またその背景となる「どのような要求を満足させるのか」、「どのような問題を解決したいのか」）によってテストの内容を変える必要があります。

例えば、画期的なアイデアを思いついたとします。それが、本当に世の中に受け入れられるかどうかをお試しで無料で使ってもらおうとしているとします。その無料ソフトのテストするなら、異常系のテストは最少限にして、その画期的なアイデアが使用者に伝わるかどうかをテストすることでしょう。もしも、自社の保守エンジニアが故障解析のために使用するツールのテストであればGUIではなく、CUIの方が使用性（ユーザビリティ）が高いかもしれません。状況が異なれば、テストの方法もそれに合ったものに変える必要があります。

また、アジャイルプロジェクト（イテレーティブ開発モデルとインクリメンタル開発モデル）とシーケンシャルライフサイクルプロジェクト（シーケンシャル開発モデル）のように、「ソフトウェア開発ライフサイクルモデル」が異なれば、テストに対するアプローチやテストの実行方法は異なります。例えば、イテレーティブ開発モデルでは、開発全体を通してテストレベルの重複や繰り返しが発生することが多いものです。

≣ 解説（詳細）

ここからは、FLシラバスの解説をもう少し分解して細かく読み解いていきたいと思います。
まずは、FLシラバスの解説を再掲します。

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1節を参照）。

■　状況が異なれば、テストの方法も変わる

この原則のポイントは「状況」です。2011年版のFLシラバスでは「条件」と訳されていて、もっとわかりにくいものでした。ISTQBの原文は、“Testing is context dependent”ですから「状況」は“context”を訳したものと分かります。
“context”は、日本語に訳しにくい単語です。WISDOMという辞書によると、

1. （事件・情報などの）背景、状況、環境2. （文・発話の）前後関係、コンテクスト、文脈、脈絡

「コンテクスト」と翻訳を諦めたカタカナ表記があることから、ぴったり対応する概念を持つ日本語の単語がないことが分かります。

ただ、ここまでの「状況」は、「使用状況」のことを述べているように思います。

■　アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる

後半のこちらは、「開発プロセスが違うと、テストの実行方法は変わる」ということです。「実行方法」であることに注意しましょう。つまり、同じ価値を提供しようというソフトウェアに対して作成するテストケースは同じでも、作成したテストケースを誰が、どのタイミングで、どういう方法で行うべきかは変わるということです。

また、こちらの「状況」は「プロジェクトが採用している『ソフトウェア開発ライフサイクルモデル』の状況」のことですね。

≣ ソフトウェアの作り方は状況か否か？

ここでは、私が気になっていることを書きます。それは、見出しの通り、「ソフトウェアの作り方は状況か否か？」についてです。

Kent Beckの『テスト駆動開発』という書籍の269ページに、マイヤーズの三角形問題に対して、

私は6つのテストを書いた（まるでクイズ番組だ：「私なら4つのテストでできるね」「じゃあやってみてください」）。Bob binderは、（……略……）65個のテストを書いた。

とあります。そして、次のページにKent Beckが書いたSmalltalkのプログラムが載っていて、「確かにこのアルゴリズム（入力した3辺の値のユニークな数を求めるロジック）なら6個のテストでバグが無いことの確信を得られる」と私も思いました。

この話、すなわち、「ソフトウェアの作り方によってテストの数が変わる」ことを本原則の延長線上で語る人がいるのだけれど、私はそれには反対です。

このエピソードは「開発者によるユニットテスト（という開発手法）」と「第三者によるテスト」との違いによって理解すべきだと思っています。これについては、話がそれるのでこのくらいにして、そのうち「ユニットテストとは何か」というnoteを書きたいと思っています。

なお、「三角形問題で必要なテストケース数」について興味を持たれた方は辰巳さんのブログが詳しくて面白いので、ぜひお読みください。

≣ まとめ

「テストは状況次第」という原則は「言われてみたら当たり前の原則」なのですが、実践するにはハードルが高い原則です。
というのは、この原則に則った活動はテストプロセスの初期を中心に最後まで関係しますので、テストリーダーやテストマネージャーの強い意志と関与が欠かせないからです。
「それは理想と、わかっちゃいるけど」とならないようにあの手・この手を使ってこの原則に則ったテストになるようにしたいものです。