この記事はNishi Grover Gargによるゲスト投稿です。

探索はテストに欠かせません。アプリケーションを探索するのは、アプリケーションの動作について学び、新たな情報やフローを発見するための戦略として非常に優れており、さらには見つけにくいバグが見つかることもあります。 

多くのテスターは当然のように探索テストを実施し、アジャイルチームでは探索テストをタスクの一部にしている場合もあります。しかし、もっと効果的に探索テストを行えるようになるにはどうしたらよいでしょうか？漫然とアプリケーションを実行し、あちこち見て回ったりクリックしたりするだけでは、創造的な探索とはとても言えません。

探索テストを体系化し、最大限に有用な情報を得るには何をすればよいのでしょうか。

この記事では、テスト戦略を強化し、探索テストのスキルを上げる方法を説明します。

探索の時間を確保する

私たちテスターは、アジャイルのフローと動きの速いスプリントに入ると、各ユーザーストーリーのテスト作業に集中し、次に終わらせるべきことは何かを常に考えます。しかし、最小限のドキュメントしかなく、テスト設計の時間も限られていることから、文書化された、あるいはスクリプト化されたテストを実行するだけでは、機能の品質、正確さ、健全性を保証するには不十分だという理解が不可欠です。

探索テストは独立したタスクとみなされる必要があります。ユーザーストーリーに探索テストを追加することで、探索テストに使われた時間を明らかにし、作業を認識できるようにすることもできます。

テスターは探索テストのための時間を使って担当の機能に集中し、機能がどのように動作するか、他の機能との連携、スクリプトテスト設計時に考慮されていたり、いなかったりする通常外のシナリオでの動作を試すことができます。探索テストをタスクとして行うと、あらゆる機能に対して探索テストが義務付けられ、テスターには探索のために既定の時間が与えられることになります。 

私が実際にテストしていたときは、探索がスプリントで一番クリエイティブで楽しく、大きな発見や疑問、洞察、そして欠陥の検出につながりました。

体系に従う

広大なアプリケーションの中で迷子にならないよう、また本来の目標を見失わないよう、探索時には体系が必要です。探索する特定の領域または機能を念頭に置く必要があります。たいていの場合は担当しているユーザーストーリーになるでしょう。

また、私は事前に機能をスクリプトテストでテストし、明らかなバグ（もしあれば）を見つけておくようにしました。そうすると、テスト対象の機能についてあらかじめある程度理解できます。探索を行うときには、さらに知識を拡げ、機能についてより多くを知ることができます。

時間の制限も必要です。探索セッションは1時間から2時間の時間枠が必要だと言われています。私は1時間で試してみて、担当しているどんな機能でもひととおり実行するのに十分だと判断しましたが、担当機能のドメインや複雑さに応じて2時間まで試してみてもよいでしょう。

あらかじめ設定した時間枠を取り、ミーティングや休憩、息抜きなどの中断が入らないようにスケジュールしましょう。私は探索中に思考の流れに何も邪魔が入らないよう、オンライン上のステータスを「応答不可」にすることもありました。

所見のメモを取る

探索の時間内にその場で直接欠陥を登録するのはお勧めできません。ただし、気付いたことをメモに残しておくのは重要です。システムをセットアップし、メモを取る準備をしておきましょう。

使い慣れたメモ帳とペンでも、まっさらのドキュメントを開いて準備しておくのでも構いませんし、TestRailを使って探索セッションをセットアップし、考察を記録することもできます。何を選んだ場合でも、探索セッション中に行ったことはすべてメモしておく必要があります。

たとえば、機能をテストする新たな方法を発見したとします――これは後でテストに追加する必要があるでしょう。あるいは、期待される動作がよくわからないアクションを見つけたとします――後でプロダクトオーナーや開発者に確認する必要があるでしょう。あるいは、アプリケーションのパフォーマンスが問題になりそうな個所を見つけたとします――チームに知らせて、次のスプリントでパフォーマンステストのモニタリングを開始する必要があるでしょう。あるいは、システムに登録する必要がある欠陥を見つけたとします――後で忘れてしまわないよう、シナリオの詳細を記録しなければならないでしょう。

後でチームメンバーと再検討できるよう、考察をすべて書き留めておきます。メモは探索セッションで何を行ったかを示す良い方法にもなり、あなたが行っているすばらしい仕事を可視化するのに役立ちます。

適切な期待値を設定する 

その定義から言って、探索テストはテストというより学習であるため、探索テストに期待するものもそれに沿っていなければなりません。探索セッションの結果として欠陥が見つかることもあれば見つからないこともあるが、探索テストは機能の動作について確実に意識と知識を高め、適切な疑問を発するのに役立つということをチームに対して明確にする必要があります。 

過去の、あるいは現在進行中の探索セッションで得られた所見を知らせ、考察やメモを共有することで、探索テストというアクティビティが、欠陥を発見するという以外にさまざまな方法で役に立っているということをチームに意識させます。そうすると、探索テストの多様な利点が理解されるほか、あなたがシステムを探索するときにさまざまな方面に意識がいくようになります。

ここで挙げたヒントがより多くの探索テストを計画に含め、あなたの探索テストのスキルを上げて努力を最大限に活かす助けになることを願っています。

Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で11年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップを主催したり、多数のテストイベントやカンファレンスで講演を行っています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Raise Your Exploratory Testing Game」2020年6月18日の翻訳記事です。）