筆者のモットーは、楽（たの）しく楽（らく）してテストを行うことです。それでは、皆さんと“⁠楽々（たの)（らく）⁠”テストの進め方を考えてみたいと思います。

「週末はハイキングに行こう！」予定をたてて目的地へGO。さて、ハイキングの目的は何でしょう？ 景勝地の探索、はたまたウォーキングで体力増強とか、いやいや「目的なんてないよ」という声もありますね。

ハイキングに目的を設定したら、ハイキングは目的を達成させるための手段になります。合理主義で考えて、目的を達成させるために最適な手段を選べば良とすると、「⁠ハイキングをすること」も選択肢の1つにしかなりません。これでは、「⁠目的の為には手段は選ばず」なんてことになり本末転倒です。このように考えると、ハイキングはあまり楽しいと思えなくなりますね。

少し屁理屈になりますが、“⁠楽しくやれる⁠”ことは“⁠楽に感じる⁠”⁠、また“⁠楽に感じる⁠”ことは“⁠楽しくやれる⁠”とします。ハイキングの目的が苦しい体力増強だとしても、ハイキングが楽しければ、少しは救われるかと筆者なりに考えます。

テストの最終目的は終了基準のクリア。そのために……

テストにおいてはどうでしょう。まずは、楽（らく）をすることから考えます。

さて、皆さんはテストの目的をどのように設定されていますか。「⁠用意した全てのテストを実施した⁠」⁠、「⁠予定数の不具合を検出した⁠」⁠、なかには「納期になったから⁠」⁠、「⁠予算を使い切ったから」などでテストを終わらせたなんてこともあるかもしれません。

筆者が考える代表的なテストの終了基準は、

• 予定したカバレッジ基準をクリアした
• 残存不具合の数／重要度の基準をクリアした
• 与えられた要件（性能や信頼性などの非機能な要素）をクリアした

などをベースにさまざまな要件を複合的に取り入れて終了判定を行っています。これらは、テスト工程以降に想定されるリスク項目を残さないように行なっています。そして終了基準に達するために実施するテストといっても、その道筋（工程）はさまざまです。最短ルートもあれば、容易を求めるルートもあります。しかし、目的を見失って“⁠彷徨う⁠”状態になると、モチベーションが下がってしまいます。

終了基準を考えないで、延々と同じテストを繰り返しているプロジェクトは、徐々にモチベーションが下がり、生産効率が悪くなり、楽しくなくなる悪循環に陥ります。クリアすべき残存不具合数や残存するテストの要件の数を管理して、適切なテストをすることで、無駄な作業を減らすようにマネジメントを行います。

「無駄なテストをしない」って、簡単に書きましたが本当はものすごく難しいことで、実際のプロジェクトで「無駄である／無駄ではない」の区別をしてテストを実施することは少ないと想像します。少しでも楽（らく）をするには、これらの見極めが大切です。

一般的にテストの実施は、テスト終了基準をクリアするための活動です（中には、品質を診断するために、局面的に行う場合もあります⁠）⁠。そして、テストの終了基準を設けることは、目的を見失って⁠”迷子⁠”にならないようにするために重要なこととなります。

テストとは、ミステリRPGなり

次に、楽（たの）しくテストをすること考えます。

「テストを楽（たの）しくできる人は、本当は意地悪な性格なんじゃない。」と言っているあなた、それは誤解です。開発に比べてテストは、成果物は曖昧で達成感が少ないと思われているんじゃないかと考えています。「⁠達成感が少ない分、開発者を苛めている」なんてことはありません。

楽しくテストができる人は、開発者と違う達成感を持っています。「⁠好きだから、多少の苦労も苦労と感じない」というのは極端ですが、筆者はテストならでは楽しみを持っています。テストを担当するときに目標を決めているのですが、その一つを紹介します。

テストの行為とミステリRPGはよく似ていると思っています。ゲームに隠された謎（不具合）を想定し、探し出し、発見したときに達成感があります。そのためには、エラー推測を行なったり、環境や条件の組み合わせで矛盾している箇所を探索したり、そして開発者に開発の背景などをヒアリングすることもします。これらのヒント（情報）を使って、謎（不具合）にたどり着いたときに達成感を得ています。少ない手順でクリアすることは、無駄なテストを減らすことにも貢献します。

やっぱり、テストも仕事も“⁠楽々（たの)（らく）⁠”が基本ですね。

テストTips集を集めましょ

しかし、テストは地道な努力も必要です。毎日々々、同じテストの繰り返しではつまらないから変化を持たせたり、ちょっとしたTipsを集めるのも良いでしょう。失敗から学ぶことも重要です。まさに「人間力」が試されます。

経験からのTipsです。テストの準備は、テストの前日までに機材を揃え、環境を整えます。すべての環境を準備してテスト本番を迎えたのに、肝心なテスト対象に電源が入りません。慌ててもテストは進まず、1日が無駄になった経験があります。テストの準備段階で、テスト対象に“⁠火入れ⁠”しなかったので、適切に対応するタイミングを逸してしまいました。それ以降、入手したテスト対象は必ず“⁠火入れ⁠”の儀式を行うようになりました。

ほんの“⁠些細な⁠”経験を活かすことが、テストの効率化に貢献します。

第6回（最終回）「あっ、しまった。」と思う前に！

不具合の混入の原因は、ちょっとしたミスがほとんどです。現在のテストは、不具合の流出を防ぐための「歯止め」です。これからのテストでは、「⁠あっ、しまった。」を事前に察知して「予防（抑止⁠）⁠」することが求められてきます。次回は、筆者が考える不具合の「予防（抑止⁠）⁠」について解説します。