基本的にテストを行う際には、テスト仕様書に沿って正確にテストを実行することが基本とされています。しかし、仕様書に書かれている内容だけでは一部見落としが発生する事があるのも事実です。今回はテスト仕様書にない事をあえて試すことの重要性について考えてみたいと思います。
なぜ仕様書にないことを試すのか
テスト仕様書は基本的には完璧ではありません。仕様書を作成する時点では想定していなかったユーザーの操作パターン、予期しない環境条件、あるいは他機能との意図しない相互作用など、実際の動作環境では様々な状況が発生します。仕様書通りのテストだけでは、こうした「想定外」の問題を発見することができません。
また、ユーザーは必ずしもマニュアル通りにソフトウェアを使うわけではありません。誤操作、連続クリック、ブラウザの戻るボタンの多用など、設計者やシステム作成者が「そんな使い方はしないだろう」と思うような操作こそが、重大な不具合を引き起こすことがあります。
探索的テストの価値
仕様書にない事を試す代表例が探索的テストです。これは、過去のテスト実施経験や知識、そして勘を活かして、システムを探索しながら同時にテストを実行する手法です。テスト仕様書に記載されている内容から読み取った、テスターの直感や好奇心が重要な役割を果たします。
探索的テストでは、「画面読込の切れ目にボタンを押す」、「処理動作中に画面を戻す」「意図的にエラー動作を放り込む」といった疑問及び興味を持ち、実際に試してみる事が重要です。この動作の結果で、テスト仕様書の内容だけでは見つけられなかった問題が発見される事があります。
具体的な実践方法
最近ではテスト仕様書の基本内容に含まれる事が多いですが、予想外の入力値を試す事はよくあるパターンです。数値入力欄に文字を入力する、テキストエリアに特殊文字、極端に長い文字列を入力するなど、「通常はやらないだろう」という操作を意図的に行います。場合によっては入力制限の漏れや文字数チェックの制限が機能していないと言った問題を発見出来ます。
他には操作手順の変更や日付で言えば過去や未来の値を設定したりして、実際にどの様な結果が返ってくるかを確認する事もあります。例えば、予約システムでは遥か未来の日付を設定出来るようにすると、入力ミスによっては10年先になったりする事もあり、注意書きやエラーが表示されない場合はそのまま予約してしまう事もあり得ます。こういった場合では限界値の設定等が必要になって来るかもしれないと新たに相談する必要があります。
また複数のユーザーでの同時操作も重要です。テスト環境としては一つのユーザーを使って、動作確認を行いますが、もしも同様の権限を持つ複数のユーザーが、同じデータを同時に編集した際にどちらが優先されるのか。あるいはエラーを表示して両方の編集結果を弾くのか等の制御機能の確認を行う事で、思わぬ不具合が見つかるかもしれません。
思い付きは意外と大事
テスト仕様書にない事を試す際に最も重要なのは、「こんなことをしたらどうなるのか」という思い付きです。「もし複数のボタンを短時間の内に素早く操作したら？」「権限のないユーザーが直接URLを入力してアクセスしたら？」など、疑問に思ったことは積極的に試してみる事が大切です。
手順記録は必須
仕様書にない事を試して問題を発見した場合、その再現手順をメモしておく事が重要です。自分が一度やった時は不具合が発生したのに、他の人がやると再現しないと言った事も十分にあり得る為、何をどのような順序で行ったのかをしっかりと記録しておく必要があります。
一度だけ再現した後にその現象が起きなくなった時でも、何かの拍子で似た様な事が発生した場合にメモがあると役立つ場面は数多く存在しています。
まとめ
テスト仕様書は重要な指標ですが、それが全てではありません。テスト実施者の好奇心と思いつきが、本当にテスト仕様書の隙間を埋めるテストを生み出します。仕様書にない事をあえて試すことで、本番前に重大な問題を発見し、より使いやすい物を提供できるようになります。勿論前提として、テスト仕様書に書かれている事をやらずに実施する事はNGです。まずはテスト仕様書をこなし、その後で思いついた事をやっていく事が重要です。
テスト実施者はある意味では一番最初のユーザーでもありますので、テスト実施時に「何となくユーザーがやりそうな事」を意識してみる事はとても大事な事と言う話でした。
