初めまして。QAエンジニアのまちこです。今はお客様先に常駐してWebシステムのUATを担当しています。テスト分析・設計、テスト実施を行う毎日です。
QAの仕事に携わって２ｘ年、今では当たり前のようにテスト分析・設計、テスト実施を行っていますが、まだテスト初心者で初めてテスト設計して作成したテスト仕様書は、ただテストベースのドキュメントに記載してあることだけをコピーしたようなものでした。テストケースの内容も記載方法も全く不足していて、今の私なら恐ろしいほどのダメだしをしているはずです。
「テスト担当者は、期待結果を識別する際、画面上の出力だけでなく、データおよび環境的な事後条件も考慮する。テストベースが明確に定義されていると、理論的には、正しい結果を容易に識別できる。ただし、テストベースのドキュメントは、曖昧で矛盾を含み重要な領域をカバーしていないか、もしくはまったく存在しないことがある。」
ISTQB® テスト技術者資格制度 Advanced Level シラバス日本語版
テストアナリスト Version 3.1.1.J03 1.4.2 テストケースの設計
上記のようにJSTQBシラバスにも記載がありますが、テストベースのドキュメントは曖昧だったり、矛盾を含むことがあります。時には記載内容が不足していることもあります。その中で試行錯誤し「今では当たり前」といえるようになったテスト分析・設計、テスト実施の私なりのコツ（心がけていること）をご紹介します。
記載内容から想像・想定を膨らます
私が仕様理解をする際に心がけていることなのですが、想像・想定を膨らませながらテストベースのドキュメントを読み進めてテストベースの「抜け漏れ」を防ぐことです。
例えば・・・
テストベースにユーザー登録の手順について、以下の記載があったとします。
■ユーザー登録は次の手順とする Step1 個人情報入力 Step2 勤務先情報入力 Step3 その他情報入力 Step4 [登録]ボタン クリック 登録完了
このような場合に
- 記載通りの手順でのユーザー登録の検証
- 各Stepでの入力値の検証が必要
- Stepはスキップが可能なのだろうか？→スキップできるか否かの検証も必要
- 前のStepに戻ることは可能なのだろうか？→前のStepに戻る検証も必要
- 前のStepに戻れたとして、入力内容は保持されているだろうか？
等・・・
このような想像は、今まで行ってきたテスト分析・テスト設計・テスト実施の経験が発想の元になっていると思います。また、他の方が作成したテスト仕様書のレビューからも気づきを得てきました。
他にも自分が普段使っているWEBサービスやアプリケーションを利用していて感じたことも発想の元になっています。例で挙げた「前のStepに戻れたとして、入力内容は保持されているだろうか？」という観点も、アンケートの入力中に前のページに戻った際に入力した値がクリアされていて使いづらさを感じた経験から想像に至っています。想像を膨らませて思いつけることは個人差がありますが、まずは記載内容だけを鵜呑みにするのではなく、意識的に「何か他に必要な検証はないか？」と想像することを心がけています。
必要な検証内容を想定したり、他にどんな検証が必要かを想像しながらテストベースを読み進め、想定した検証内容や不明点などを書き留めておくようにします。
テストベースを読み進めて疑問に思っていたことが記載されていて疑問が解消できれば、それをテストケースの期待値として検証内容を想定できます。最後まで残った疑問は開発者へ質問します。
開発者に質問した結果、回答がただの記載漏れであれば、対象のテストベースに記載してもらえば記載漏れを防ぐことができたことになります。
回答が記載漏れではなく仕様の検討がなされていなかったために記載していなかった、といった仕様の検討漏れだった場合、質問したことで開発者に仕様検討漏れに気づいてもらうことができますので、仕様の検討漏れを防ぐことができたことになります。
テストベースの記載内容が充実すれば、テスト分析・テスト設計もやりやすくなります。なので、仕様理解を進める際に記載内容を鵜呑みにするのではなく、1つの記載から想像を膨らませて検証内容を想定していくのが1つ目のコツです。
曖昧をそのままにせずに明確にする
繰り返しになりますが、テストベースのドキュメントは曖昧なことがあります。記載が曖昧だとテストケースの期待値の記載もそのまま曖昧となります。
例えば・・・
テストベースのドキュメントの記載に「不正な場合にエラーメッセージを表示する」とあったとします。それをそのままテストケースの期待値に採用したらどうなるのでしょうか？自分がテスト実施する際にテストケースの期待値として「エラーメッセージを表示する」とだけあったら、正しく判断できるでしょうか？
- メッセージの文言は何？
- メッセージの表示形式はどんな？インラインで表示？メッセージダイアログを表示？
とテスト実施時に不明点が出てしまいます。
実際に私が参画していたプロジェクトで、テスト実施のヘルプに入った別チームのテスト仕様書の期待値が「エラーメッセージを表示する。」となっていたことがありました。表示されたメッセージが正しいものであるのか判断することができずに、テスト仕様書の作成者に確認を取ったり、参照したテストベースのドキュメントを探したり、ドキュメントから該当のメッセージを探し出すといった余計な時間がかかってしまいました。
余計な時間がかかるだけではなく、実施者によっては表示されたメッセージの内容まで確認せずにメッセージが表示されていたのでOKとしてしまうかもしれません。
テスト仕様書の記載は、初めて実施する人でも分かるように確認手順や検証結果の期待値は明確に記載されていることが理想です。ですが限られた時間のなかで作成することもあり、テスト仕様書を詳細に作り込むことができないこともあります。
そんな時でも可能な限り、
- テストベースの記載内容が曖昧な場合にはテスト設計時までに開発者に質問して記載内容を明確にすること
- テスト仕様書の確認手順や検証結果の期待値は曖昧にせずに明確に記載すること
を心がけています。
テスト実施者が効率よく、迷うことのない優しいテスト仕様書を作成できるように、テストベースの記載内容の曖昧さやテスト仕様書の記載を明確にすることが2つ目のコツです。
ユーザーがやるかもしれないと想像してやってみる
ユーザーがやるかもしれないと想像する・・・というとユースケースを想定してテストシナリオを考える。と思われるかもしれませんが、ちょっと違ってテスト実施時にテストケースにはないけどちょっと気になったことを「ユーザーがやるかもしれない」と思ってやってみるということなんです。
例えば・・・
[登録]ボタンをクリックしてから処理が完了するまでの処理中に、画面に変化がなく[登録]ボタンがクリックできる状態になっていたら
- ユーザーに処理が開始されたのか分からないじゃん！
- ユーザーはもう一回ボタンをクリックするかも、いや連打しちゃうかも
みたいに思ったりしませんか？そんな風に思ったらテストケースには記載はないけどやってみるんです。
実際にテスト実施中に、ボタンクリック後の処理中にボタンがクリックできる状態だったことがあったのでボタンを連打してみたんです。そしたらアプリケーションが固まってしまった！ということがありました。
テストケースには「処理中にボタンをクリックする」とはなくても、”もしかしたらユーザーがクリックしちゃうかもしれないので、クリックしてみよう。”とユーザーがやっちゃうかもしれないと想像してやってみることで潜んでいたバグを見つけることができました。
また画面に変化がなく処理が開始されたのが分からないので「処理中なら処理中と分かる画面表示にした方がユーザーには分かりやすいのでは？」といった、ユーザーにとって分かりずらい画面表示になってしまっていたといった気づきを得て問題点を開発者に提示し、改善に繋げられたこともありました。
このようにテスト実施中にちょっと気になったことをそのままにせず、ユーザーのことを想像してやってみることが3つ目のコツです。
まとめ
今回紹介した３つのコツは、誰もが無意識で実践しているような当たり前のことかもしれません。テスト分析・設計、テスト実施がちょっと難しくて苦手と思っている方でも、これらのコツを意識することで効果はあると思います。私が今日に至るまでテスト分析・設計、テスト実施時に心がけ、実践して効果がありましたので！！！
そして、皆さんも日々試行錯誤しながら自分なりのコツを掴んでより良いテスト分析・設計、テスト実施ができればと思います。
最後まで読んでいただき、ありがとうございました。
