この記事はJustin Rohrmanによるゲスト投稿です。
私が関わったソフトウェアプロジェクトの大半には、仕様書か受け入れ条件がありました。プロダクトオーナーから見ると、これは構築すべきもののリストです。私から見ると、テストのアイデアのリストにもなります。
テスターは仕様書の各ポイント、あるいはユーザーストーリーの各行をテストとして実行し、完了できます。このようにテストを見ると、技術者以外の人たちに説明しやすく、一定の期間内に終わらせるのも容易ですっきりします。
戦略としては良い出発点であるかもしれませんが、水深が2インチしかないプールのようでもあります。浅すぎるのです。
テスト作業が仕様書に始まり仕様書に終わるという考え方を捨てるのは進歩ですが、また別の問題も出てきます。基準のリストがなければ、どうしてテストが終わったとわかるのでしょうか―あるいはどうやってテストを終わらせるのでしょうか？
完璧なテストは不可能
送料がいくらになるかを計算するごく単純なWebページを想像してください。この単一ページのアプリケーションには以下のコントロールがあります。
- 10マイル未満用と10マイル超用の2つのラジオボタン
- 配達人が階段を登る必要があることを示すチェックボックス
- 週末配達用のチェックボックス
- 計算を実行するサブミットボタン
- 計算された料金を表示するラベル
このページを完全にテストするのに必要なテストはいくつでしょうか？1？100？1000？真理値表を作ると、ラジオボタンおよびチェックボックスの可能な組み合わせが8つか9つあることがわかるでしょう（選択なしも含む）。でも、それで本当にテストは完璧でしょうか？
すでに答えは「ノー」だと予測していらっしゃるでしょう。では、他の重要かもしれないテストアイデアについて考えてみましょう。
設計から、いくつか尋ねてみたいことがあります。配達距離がちょうど10マイルだった場合はどうなるでしょうか？また、ここでマイルは適切な単位でしょうか？階段としてカウントされるものは何でしょうか？週末の配達には追加料金が加算されるのはわかりますが、祭日や夜間、急ぎの配送はどうでしょうか？
これらは設計上の質問であり、多くは製品が開発プロセス内のどの段階にあるか、製品を使うユーザー、ユーザーの期待などをよく知ることで回答できます。次に、製品とのやりとりを含む問題に対応します。
これは大きな課題です。どのプラットフォームがサポートされるのでしょうか。プラットフォームが1つなら簡単ですが、最近では、1つということはめったにありません。デスクトップでは Windowsがあり、macOSがあり、ひょっとするといくつかのLinuxがあり、おそらくは各OSにつきいくつかのバージョンがあります。モバイルデバイスではAndroid、iOS、その他マイナーなものがいくつもあります。一般的に、AppleのiOSでは特定の時期に使われている主なバージョンは1つですが、GoogleのAndroidではリソースが開発者コミュニティで利用できるため、100あるいは1000ものバージョンがあるかもしれません。製品は環境ごとに少しずつ動作が異なります。
しかしこれも氷山の一角です。データストレージについてはどうでしょうか？見積りのEmail送信については？ユーザーが続けてサブミットボタンを押した場合はどうなるでしょうか―誤った複数のオーダーが作成されるでしょうか、それともページがクラッシュするでしょうか？この記事はテストのアイデアを扱うものではありませんが、5個や10個は考え付きますし、これでも表面をなぞっただけです。
ページ全体はもちろん、フィールド1つに対しても無限のテストがありえると理解すれば、いつテストをやめるかの決断が必要になります。
テストをやめるための経験則
私が新しいコードの変更をテストするときは必ず、いつテストをやめて次のタスクに行くべきかも判断します。通常、この判断は以下のような経験則あるいは実践的法則に従って行われます。
時間がなくなった
ソフトウェア開発は常に時間の制約の中で行われます。アイデアから運用に至るには、数時間から数週間かかります。おそらく、2週間のスプリントの中で開発するのが主流の方法でしょう。2週目の金曜日までの時点で、完了したとチームで合意がなされた機能のセットがあり、おそらくはまだ着手していない機能があり、まだ作業中の機能があるでしょう。その時点で、作業中のタスクを新しいブランチに移動し、後でリリースするか、問題があるかもしれないことを承知の上でリリースするかを判断するでしょう。ところで、さしあたりこれらの変更に対するテストは終わっています。
スプリントというコンテキストでは、「時間がなくなった」という言葉の意味はあいまいになります。テストに時間がかかりすぎてボトルネックになっている場合、時間がなくなったと言えるでしょう。1つのストーリーのテストに時間がかかりすぎてスプリント全体が遅れるような場合、時間がなくなったと言えるでしょう。私がスプリントの最初のストーリーをテストしているのであれば、与えられた時間に収まりそうにないかどうか判断するために、残りのテストがどれくらいかかるか見積もる必要があるでしょう。ストーリーに時間がかかりすぎているかを測るのにストップウォッチを使うことはめったにありません。多くはスタンダップミーティング時に会話の中で決定されます。
もうバグが見つからない
テストというのは、水に浸した布を絞るようなものです。何回かたたんでひねると、たくさんの水が絞り出されます。もう1回たたんでひねると、先ほどよりは少ない水が絞り出されます。最後にもう1回たたんでひねると、運が良ければ1滴くらい水が出てくるかもしれません。
通常、バグはテストセッション開始当初には容易に見つかり、後になるほど見つけるのが難しくなり、最後にはあらゆる努力をしても製品のテスト対象部分について新しい情報や重要な情報は得られなくなります。
これが次に移るべき時を意味している場合もあります。ただし、慎重にするべきです。アプローチが労力に見合わないものであり、単に新しいアプローチを採用すべき時であることを意味している場合もあります。
マネージャーにやめるよう言われた
コードの作成と同様に、テストも中断や割り込みをいかに管理するかが重要です。私が新しいコードの変更をテストしている最中に、マネージャーはサポートが支援を必要としているというメッセージを受け取るかもしれません。重要な顧客からサポートにデータの永続性の問題について問い合わせが入っています。私の新しいタスクは、その顧客のデータベースをエクスポートし、顧客が利用しているバージョンの製品で環境を構築し、できるだけ正確に問題を再現できるよう設定することです。
マネージャーの要請による中断は恒久的なものかもしれません。つまり、誰かが私の元のタスクを引継ぎ、私はサポートの問題に対処するかもしれません。あるいは、中断は一時的なもので、私はサポートの問題での役割が終われば、テスト作業に戻るかもしれません。
次に何をすればよいかわからない
コードの変更を受け取り、可能なことをすべてやり、それから目的を考え始めることがあります。テキストフィールドをテストし、予期しないデータを入力したとき何が起こるかを理解しました。日付フィールドは特定の日付範囲を1種類のフォーマットでだけ受け入れることがわかりました。次は何をするべきでしょうか？
次に何をするべきかわからないというのは、一時的に中断するべきだと判断するよい理由です。中断によって時間の余裕ができ、開発者と話をして開発者の懸念をもっとよく理解したり、製品マネージャーと話して顧客像や顧客が求めるものについてのイメージを明確にしたり、他のテスターと話してより実りのあるテストアイデアを生み出すことができます。それでも何も出てこない場合、次のタスクに移るべき時なのかもしれません。
ソフトウェアの用意ができていない
ときどき、渡された製品が動作していなかったり、問題がありすぎたりして、テストするのが砂利だらけの浜をサンダルでつまずきながら歩くようなものである場合があります。そのようなケースでは、一時的にテストを中断し、開発者に機能を戻して修正してもらうこともあります。
フォームをサブミットできないだとか、ディスカウント値に小数点値を入れるとJavaScriptエラーがスローされるといった簡単に見つかるバグがあるような状況では、これは純粋に効率の問題です。バグが発見されるごとに時間が消費されます。バグを調査し、コードを変更して修正し、新しいビルドにマージし、再びテストする必要があります。ここで私がテストの中断を決定するのは、開発者のほうがこれらのバグをすばやく簡単に見つけて修正できるからです。
判断する
先ほど、実践的法則とは経験則であるとしましたが、これは常にあてはめられるルールではないということも意味します。ここで挙げたルールのどれか1つ(あるいは複数)でもテストをやめることがありますが、問題を切り抜けて先に進むケースもあります。
たとえば、通常のスケジュールでは時間がなくなったが、まだ重要な問題が見つかっている場合、マネージャーはもう少し時間を与えることに同意するかもしれません。あてはまる理由が多くなるほど―時間がなくなった、もうバグが見つからない、マネージャーにやめるよう言われた―おそらくテストをやめるべき時であることがはっきりします。
テストアプローチを構築する
可能なテストは無限にあり、もうすぐテストを終わらせなければならないだろうとわかっているのですから、慎重にテスト技法やアプローチを選ぶ必要があります。どこからアプローチすべきかについて具体的なアイデアを挙げるのは困難ですが、多くの人がつまずきやすい領域を2つ挙げることができます。
1.テスト以外のことに注意を取られすぎている テスターの役割には、新しいソフトウェアを操作することとは関わりのないことが多く含まれています。たとえば各種のミーティング、電子メール、ドキュメント、次のビルドやコードの作成を待機することなどです。不注意なチームでは、いつの間にかテストよりもテストでないことにかける時間が多くなりすぎていることに気付く場合もあります。テスト以外のアクティビティも役に立ち、ソフトウェアについて新しい情報をもたらすこともあるかもしれませんが、「ずっとそうしてきたから」というだけでやっている場合もあるかもしれません。プロセスのうち、テスト対象のソフトウェアを知る役に立たない側面を排除することは、よい実習になります。
2.ほぼ1つの技法だけに依存している おそらく、ドメインテストは最も一般的なテスト手法でしょう。私たちはこの戦略によって変数―Webページのテキストなど―を解析し、テストする必要がある値と、意味のある情報をもたらさない値を判断します。フィールドに何らかの値を入力し、何が起きるかを観察し、テストは終わったと宣言するという惰性に陥るのは容易です。他にもさまざまなテスト技法があり、どれもソフトウェアについて固有の情報を教えてくれます。いろいろなテスト技法に慣れ、どのように利用するか、特定の時点でどのように役に立つかを学びましょう。そうすると、通常よりも短期間にもっと有能なテスターになるのに役立ちます。
いつでも実施すべきテストは多くあり、すべてを実施する時間はありません。テスト技法の目的について概要を知っておくことは役に立ちます。この知識を活用して、与えられた時間内でテストをより強力にすることで、テストの効果を最大化できます。
2005年以来、Justinはさまざまな立場でプロフェッショナルなソフトウェアテスターでありつづけています。現在は、Excelon Developmentでコンサルティングソフトウェアテスターおよびライターを務めています。業務以外では、 Association For Software Testing Board of Directorsの総裁として、さまざまなプロジェクトの円滑化と発展を支援しています。
（この記事は、開発元Gurock社の Blog 「When Do I Stop Testing?」2021年2月26日の翻訳記事です。）
