今回このブログを書かせていただきます、 ヒューマンクレストの高橋です。
私の担当する回ではテストに関するTipsをいろいろ書いていきます。
前回は 第一回目として、テスト設計の「テスト要求仕様」作成のフェーズにスコープを充てて書いてみました。
今回はその続編として、「テストケース仕様」にスコープを充てて書いていきます。
前回のテスト要求仕様書で定義したテストケースを具現化していくことにより、テストを効率的に実施し、バグを検出する事を助けることが、テストケース仕様書の目的になります。
私が考えるテストケース仕様書の記載必要内容は、以下の内容を想定しています。
（なお、テスト結果も同時に記入を行える「テスト結果一覧」も兼ねています。）
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
①テスト実行環境の明確化
テスト実行時の環境を明確にします。
テスト実行時の環境にテスト実施目的により差異がある場合は、どの環境を使用するかというのを テストケースごとに明確にしておく必要が有ります。
②テスト実行時の前提条件（Input）の明確化
テストケースにおいてテスト実施の前提条件となるInputのパラメータを指定します。 ここはなるべく、曖昧な言葉だけの表現はさけて、具体的なパラメータを指定する表現にします。
ex.「パラメータ●●に▲▲を指定する（他のパラメータはデフォルト値を指定）」
③テスト実行時の期待結果（Output）の明確化
テストケースにおいてテスト実行した際の期待結果（期待値、Output）を明確に記載します。
ここは、やや抽象的な表現に陥ること(ex1)が多いのですが、期待する結果を詳細に記載すること(ex2)が望ましいです。
ex1.「●●バッチが正常動作する事」
→正常動作の動作内容が不明であるため、正常動作の動作内容を具体的に示す必要が有ります。
ex2.「以下の通り、▲▲バッチ実行時、以下の動作を行う事
1.●●バッチ実行時、エラーが発生せず、実行結果に正常終了（resultコード：OK）となること
2.●●バッチ実行時、▲▲ファイルが出力されること
3.▲▲ファイルに入力したパラメータ「xx」が出力されること」
④テスト実行時の手順の明確化
テスト実行時の手順を明確に記載します。 手順についても曖昧な表現は裂け、具体的な記述を行う必要が有ります。
なるべく、日本語だけの記載ですと副詞での表現は曖昧な記載になってしまうので、実行頻度などの記載は 数字で表現した方が良いです。
テスト実行者により、感覚が異なり、結果に差がでる可能性が生じる為です。
あくまで、テストケース作成者がテスト実行をするという目線でなく、誰が実行しても同じ結果を得る事が できるということを目的に記載を行う必要が有ります。（テスト要求仕様書も然りです。）
ex.「ほどよいスピードで●●を１分間実行する」(×)
→「1秒間に6回の頻度で●●を1分間実行する」（●）
また、テスト手順については、手順の数が多いと、テストケースの数が多くなると、仕様変更等で 実行手順が変更されたときに、一つ一つのケースに対して手順の手直しが必要になってきて、 修正の工数が多くなってしまう可能性があります。
そういった事を避ける為にも、別に「テスト実行手順書」を作っておいて、テスト実行時の手順を その手順書で定義しておくといった方法を採ると楽です。
手順書のみを直す事で対応でき、テストケースと手順書間でリンクをとっておけば、 テストケースごとに手順を直す必要は無く、修正に要する工数はさほど、かからないと思います。
⑤テスト要求仕様書、機能仕様書との紐付け
テストケースごとにこのケースはテスト要求仕様書で記載しているどのテスト観点とリンクしているのかという事を 明示しておくと、テスト要求仕様書に記載されているカバレッジを満たしているかを容易に確認できます。 併せて、テスト要求仕様書、テストケース仕様書のInputとなる開発側で定義している機能仕様書についても 紐付けを行うと、機能仕様書に対してのカバレッジを満たしているかの確認が容易に行えると思います。
以下の内容はテスト実行結果を記載するテスト結果一覧の内容になります。
⑥テスト実行日時とテスト実行担当者
テスト実行日時及び、テスト実行担当者を記載する欄はテスト実行時のトレーサビリティを確保する為にも 必要な情報です。
⑦テスト結果記入欄
テスト結果「OK」もしくは「NG」を記載する欄を設けます。 個々の欄に結果についてテスト結果内容が正しいのか判断ができず、問い合わせを行っていたりする項目に着いては 「QA確認中」などのステータスも用意しても良いと思います。現状が読み取れるステータスを用意してやることが 必要です。
⑧不具合報告とのリンク
不具合が発生しているテストケースについては、起票したBug管理システムの不具合報告書のIDを紐づける欄を設けて、 そのIDを記載しておきます。なお、現象の概要まで把握したい場合は起票した不具合報告書のタイトルを記入する欄を設けても良いでしょう。
⑨メモ・備考記入欄
メモや備考を記入する欄を設けます。ただし、備考が多くなると、わけが分からなくなり管理しにくくなるので、あまり情報量が多くならないほうがいいと思います。
⑩テストサマリー
テスト結果を一目で確認できる、サマリーを用意してテストの実施状況を把握できる様にします。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
大きな項目では上記の10点になるでしょうか。
前述の通りですが、テストケース仕様書にて心がけなくてはいけないことは、「自分でテストを実施するという視点ではなく、 自分以外の他のメンバーが実施する」ということを意識する必要が有ります。
「誰が行っても、同じ結果がでる。」を念頭において 極力、曖昧な表現は避け、誰にでも理解し易いテストケース仕様を心がけましょう。
次回は、レビュー時のTipsについて書いていきます。テスト実行時のTipsにいこうかと 思ったのですが、其の前に重要なタスクを忘れていましたので。
最後までご覧頂き、ありがとうございました。
Tweet