この記事はPeter G Walenによるゲスト投稿です。
これは、ソフトウェアテストに携わる誰もがいつかは経験することです。仕事が山のようにあり、大量のシナリオやテストを片づけなければならないが、たとえ自分やチーム全員が1日24時間働いたとしても、すべてをテストするのはとうてい不可能。私が関わるほぼすべての組織やチームでこういった問題を目にします。完了しなければならないことが山のようにあり、顧客に約束したデリバリー期日に間に合うようすべてのテストを終わらせるのは不可能です。さまざまな「アジャイル」環境で働く人たちもよく似た、あるいはまったく同じ課題に直面します。それは、つまりは「何もかもテストしろ」という要求です。
ただし、現実においては、何もかもテストするのは単純に不可能です。
どう対処すればよいでしょうか？できるかぎりよい仕事をし、チームの期待に応えながら、ベストを尽くして顧客を満足させるにはどうしたらよいのでしょうか？
計画と検討
テスト作業がテストで利用できる時間を超過しそうだと感じたら、私はまず基礎的な計画から始めます。以下の点に注意します。
- 何をテストできるか？
- どうやってテストできるか？
- それぞれどれくらいの量の作業が必要か？
- 一緒に、あるいは並行してテストできるような類似した機能はないか？
- どの機能が最もエラーに対して脆弱か？
- どの機能が最も重要か？
最初のいくつかの項目の検討はテスターまたはテストチームで完結し、有効な計画を作成できます。このときのゴールは、可能な作業オプションを残らず検討し、各機能に使える時間を最大化する方法を判断することです。すると、実施を計画するアイテムのリストと、依存関係や各機能を統合したときの動作の概要がわかります。結果として、テスト対象となる一連の機能を記載したスケジュール、それらのテストに必要な時間のおおよそを把握できます。
最後の項目は多くの人にとってなかなか難しいものです。顧客や顧客の代弁者と話し合う必要があります。スクラム環境ならプロダクトオーナーかもしれません。その他の環境ではプロダクトマネージャーかもしれません。顧客にとって最も重要なアイテムを特定したら、テストスケジュールの原案に戻ります。情報をもとに、顧客にとっての最重要である機能をテストの最上位に持ってきます。開発チームと話し合うことで、最も脆弱でエラーが発生しやすいと彼らが考えている領域を特定できます。これを顧客にとって重要な機能と組み合わせることで、出発点となる優先順位付きのリストが手に入ります。
まず最優先のタスクを完了させ、優先度の低いタスクを最後にします。単純なことではありませんか？
そうかもしれません。しかし、たちまち非常にややこしくなることもよくあります。
最初の難題 – 顧客の優先順位
複数の顧客のニーズが衝突する場合、話し合いがややこしくなるのは確実です。多くの組織では、作業が始まる前に優先順位に関する話し合いが行われます。これは、少なくとも何を最初にテストするべきかに関する話し合いの開始点にはなります。すべてのニーズや期待が他の顧客にとっても同程度に重要とは限りません。複数の顧客がいる場合、特にそれが特定の機能拡張のためにお金を出している顧客なら、競合する優先項目をテストチームが比較検討するには、組織のリーダー層からの支援とガイドを必要とします。成熟した組織のリーダー層なら、介入して複数のニーズを優先順位付きのリストのようなものに何とかまとめあげるでしょう。そうでなければ、事態は混乱するでしょう。それぞれの最優先アイテムをテストせよという要求とともに、何もかもテストせよという要求が大きくなります。
もちろん、何もかもをいっぺんにテストすることはできません。「最優先」アイテムは1つしか存在できません。自由にやらせてもらえるなら、多くのテスト組織は妥当かつ理に適った作業によって何が最も重要か、またそれらをテストするのに何が必要かを判断するでしょう。
単純な真実は、テストチームが孤立して判断することはないということです。リーダー的な立場にある誰かがいて、優先順位を指示することで、開発作業とテスト作業の両方を支援する必要があります。リーダー層がこれを怠るなら、チームが失敗するよう仕向けたのと同然です。内部的な顧客や組織内部の優先順位であれば、より簡単に舵取りできるでしょう。要求が組織内のあちこちから寄せられる場合でも、全体的なビジネスバリューおよび要求を実現するための労力と照らし合わせて重みを付けることができます。この場合、テストチームおよび開発チームはより大きな役割を果たせるかもしれませんが、決定は組織のリーダー層が行うべきです。
優先順位が決定されたら、事態は容易になります。そうですよね？
2つ目の難題 – テストの労力と時間
テストに関しては、多くの組織でまず尋ねられるのは、「いつテストが終わるのか」という質問でしょう。識者なら、永久に終わらないというようなことを言うかもしれません。計画されたソフトウェアテストが完了しても、顧客は単にソフトウェアを使うことによってテストを行います。他の人は「状況による」と答えるかもしれません。どちらも役には立ちません。
テストにかかる時間と、テストにどれくらいの作業が必要かを割り出すという課題は、無数の論文、トーク、書籍、ブログ記事のテーマになっています。この終わりのないサイクルは、ソフトウェアテストはソフトウェア開発とは別だという証拠として取り上げられることも多くあります。
私たちにとっては、問題は「このリリースでデリバリーが期待されているテストすべきものを何もかもテストできるか」となります。
答えは通常「ノー」です。この点をもう少し明確にしておきましょう。
特定の機能をテストするのにどれくらい時間がかかるか？テストチームは以前にも該当機能をテストしたことがあるか？テストチームは機能がどう動作するべきかよく知っているか？テストチームは機能に関する議論に参加し積極的な役割を果たしていたか？これらすべてが「テストにどれくらいかかるか？」に影響します。
私がよく使うアプローチは、各成果物を個別に検討する方法です。きわめて順調にいった場合、機能を検証し、その後、開発チームやプロダクトオーナー、マネージャーと結果を確認するのにどれくらいの時間がかかると思うか？それからもう一度同じ質問を、ただし今度は何か問題が見つかったとして繰り返します―機能を検証し、見つかった問題を修正するのにどれくらいの時間がかかると予想するか？これには開発チームの関与が必要です。
もちろん、典型的な答えは「まったく予想がつかないね、どんな問題が見つかったかによるよ」でしょう。これは無理のない答えであり、率直に言って、誠実でもあります。開発者たちはできるだけ問題がゼロに近い製品をデリバリーしようと最善を尽くしています。
科学的な見積を出しているのだと証明するために、もっともらしい方程式をひねり出すこともできます。しかし私の経験では、そういったものは実際には役に立ちません。代わりに、私は以前のリリースでバグを修正するのにどれくらい時間がかかったか等を見ることにしています。チームが完了させた似たような規模のプロジェクトがあれば、バグ修正をコーディングし、戻し、修正できたことをテストするのに必要だった時間はどれほどでしょうか？すべてにかかった時間の平均を求めると、たいていのプロジェクトに対して妥当な見積になります。
この値によって、各機能に問題がなかった場合とあった場合のテストにかかる時間の範囲を見積もることができます。次の考慮すべき点に移りましょう。
何をテストするか
時間とリソースがじゅうぶんにあるなら、何もかもをテストできます。ただし、何もかもをテストするのに必要な時間があることは、皆無とは言わないにしても稀です。通常はすでにあるだけの時間にかぎられています。では、どうすればいいのでしょうか？
- これまでの過程で、テストすべき機能の優先順位付きリストを定義しました。最も重要な機能と最もリスクの高い機能を特定し、それらの機能と前提となる機能をテスト対象リストの先頭に置くことができます。
- 各機能のテストにどれくらいかかるか妥当な見積を作成しました。何か変化があれば、多少はずれが発生するかもしれません。しかし、作業の開始点となる見積はあります。
- 優先順位付きリストと見積から、何をテストできるか、おおよそいつテストできるか、各コンポーネントのテストにどれくらいの時間がかかると考えられるか、何もかもテストするのに全体でどれくらいの時間が必要かに関する計画を策定できます。
ここからが難しいところです。開発の完了からテストが終了しなければならない時まで、どれくらいの時間があるでしょうか？作成したタイムラインは時間内に収まるでしょうか？ごくたまには収まることもあります。ときどきは非常に近いところで収まるでしょう。
たいていは、使える時間を大幅にとまではいかなくとも超過するでしょう。そこでまたプロジェクトチームやプロダクトオーナー、あるいはマネージャーとの話し合いが必要になります。
私が参加した話し合いは、おおむね次のように進みます。私はテストの見積を決めるのに使ったプロセスを説明します。優先順位とリスクに関する議論には彼らも参加していたことを指摘します。何が最も重要で何がそれほど重要でなかったかを思い出させます。
それから皆にカットオフラインの位置を見せます。その線より上にあるものは、高い確率でテストできます。線より下にあるものはまったくテストされないかもしれません。
ここでこの議論の要となります。プロジェクトおよび顧客にとってこれがどんな意味を持つか？テストされないものがあってもかまわないか？一部の機能のテストを浅くして他の機能のための時間を作るのはどうか？
アイテムのリストを見せたとき、「期日を3週間遅らせたら、あとどれくらいテストできるか？何もかもテストするには、あとどれくらいの時間が必要か？」というように言われることはごくごく稀です。
その後は、他の人たちがテストの利益とリスクを比較検討しているあいだ、情報提供の専門家という役割に転じます。この時点で、あなたは可能な限りよい仕事をやり遂げたのです。専門知識に基づいて、プロのアドバイスを提供しました。必要な情報について事前に相談しました。
今度は彼らがどうするべきか決断します。
時には、テストの見積時間について蒸し返されます。これはよくあることです。例として出せる以前のプロジェクトがあれば、それも皆がよく知っているプロジェクトであればなお好都合ですが、テスト時間の元々の見積もりと実際にかかった時間について思い出させることができるでしょう。
結局、私たちテスターの仕事は情報を提供することです。情報に基づいて行動する必要があるのは他の人たちです。プロジェクトの制約の中で「何もかもテストする」ことはできない理由について、すでに情報を示しました。今度は彼らが情報に基づいて行動し、決定を下す番です。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「What to Test When You Can’t Test Everything」2020年8月10日の翻訳記事です。）
