テストで気をつけたいと思ったポイントをまとめてみました
まず、「テスト＝簡単」は大間違い！
「テスト＝簡単」
社会人になりたてホヤホヤの頃、私はなんとなくそう思っていました。
単純作業で頭使わなそうだし、なにより実装に比べたら技術的な知識がいらない＝簡単
ってイメージです。
しかし、それはナメた発想でした。
もちろん実装工程には実装工程の難しさがありますが、テスト工程にはテスト工程の難しさがあります。
2年目にチームでのテスト工程に携わらせて頂き、「テストは思ったよりも結構難しいな」「考えることが多いな」ということに初めて気づきました。
この記事では、私がテスト1工程で大切だなと思ったことを書いていきたいと思います。
前編：テスト項目書作成で気をつけたいこと
１、そのテストによって保証するドキュメントは何かを考えよう！
テスト項目書作成にあたり、項目起こしの元ネタとするドキュメントがあるはずです。
それがイコール試験の実施により保証されるドキュメントになります。
どのドキュメントを保証する試験なのかを意識し、
そのドキュメントの記載と試験項目を紐付ける必要があります。
もちろん、保証するドキュメントの記載以外にもテストすべきと考えられる項目があれば、
それも記載した方が良いでしょう。
ただし、軽微な改修であれば、上位ドキュメントは作られていないケースも多々あり。
２、「網羅性」を意識しよう！
上位ドキュメント（要件定義書、設計書）に規定されたものを
きちんと実現できていることを保証するために、
様々なパターンを、漏れがないように記載すべきです。
具体的には、以下の様にマトリックス図を作成するのが有力です。
| 端末A | 端末Ｂ | 端末Ｃ | |
|---|---|---|---|
| 有料サービス契約なし | パターン1 | パターン4 | パターン7 |
| 有料サービスを当月に解除済み | パターン2 | パターン5 | パターン8 |
| 有料サービスを解除した翌月 | パターン3 | パターン6 | パターン9 |
ただ単に箇条書きをするのでは網羅性が保証できません（カバレッジがとれない）。
また、「実施しない」項目があれば、なぜ未実施で良いのか、説明できる必要があります
（テストケース55でカバーできることになるから、等）。
３、大切なのは準正常系と異常系！
「ド正常」よりも「準正常系」と「異常系」を網羅できていることの方がよっぽど重要です！
正常系がNGなのにテストフェーズに入るプロジェクトがあるとしたら相当ヤバいです。
正常系はほぼ全てOKになって普通です。
それでも単体試験であれば正常系も結構重要ですが、
結合試験・総合試験でド正常でバグが見つかるのは本来おかしいです
（まあ実際にはあるのですが）。
「想定外」をキャッチすることがテストの役割です！
特にBtoCのサービス（世間一般に公開するサービス）の場合、
ユーザはどんな操作をしてくるかわかりません。
例えば、二重課金や通信エラー、あり得ないほど長文での登録など、
考えうるだけの「想定外」をテストで拾っておく必要があります。
４、試験手順を具体的に書こう！
例えば、
試験手順：「DBを確認する」
では、仕様をよく知らない人が読んだとき、「？」になります。
どのテーブルのどのカラムがどの値になっていればよいか、まで書かなければ意味がありません。
レビューに出しても多分NG食らいます。
項目書作成者と実施者が同じとは限らないので、
仕様設計をよく知らない人が見ても差し支えない記述を心がけましょう。
仮に項目書作成者と実施者が同じだとしても、
その後、その項目書を参考にして新たな項目書が作成される可能性もあります。
情報は正確・具体的に書いておくことで、長い目で見れば結果として無駄工数を削減することができるのです。一時の手間を惜しみ、雑に書いてしまうと損をします。
５、文言を統一化しよう！
試験項目書に限ったことではなく、ドキュメント管理全般にあてはまることではありますが、
同じ事柄を指すのであれば、表現はひとつに統一すべきです。
同じものを指す表現が複数あるのは好ましくありません。
当たり前のようでいて、実際には書き方がバラバラで混乱の元になることがどのプロジェクトでも少なからず見受けられます。
また、書き方にしても、厳しい顧客だと、読点の付け方にも指摘が飛んでくるので注意。
６、フィルタは必ず付けよう！
テスト項目書は、Excelで作成されることが非常に多いです。
項目ごとにフィルタをつけるのは当たり前。
試験実施の進捗や残件をわかるようにしておくことで作業効率が上がります。
７、分量が多い場合は、内容面の記載と体裁面の記載を分けて書くのが有力
特にテストケースが多い場合、
試験手順や結果確認方法（期待値）といった内容面を記載するだけで、かなりの時間がかかります。
それと同時進行で体裁面の記載を進めると、どちらも中途半端になってしまいがちだと思います。
まずは内容面の記載を一通り終え、次に一気に体裁を整えていく方が効率的だと思います。
８、レビューしてもらうときは、作成方法を説明しよう！
時間に余裕のあるレビュアーは稀です。
テスト項目書の細かい項目を一から十まで説明していたらキリがありませんし、全て確認してもらうのは普通は望めません（たまに鬼の様に細かくチェックして鬼の様に指摘をしてくる方もいますが）。
かといって、「レビューお願いしまっす！」だけで丸投げするのでは、
レビュアーは何を判断すれば良いのかわかりません。。。
「ドキュメント〇〇を元にして、こんな考え方でこんな構成にしました！」
という感じでレビュアーに説明すると良いでしょう。
参考：テスト項目書の記載項目として考えられるもの
エンハンス開発の場合、既に類似システムのテスト仕様書が作成されているはずですが、
自分でゼロからつくる＆テストケースが多いとなると、どう書けば良いか、悩むと思います。
参考としてこんな項目が考えられるのでは、というものを書いてみました。
| 試験項目例 | |
|---|---|
| 試験項目番号 | 一意になるように振っていく |
| 大項目 | 例えば、機能の確認なのか、画面表示/遷移の確認なのか、といった、最も大きな分類を書く |
| 中項目 | 大項目の次に大きな分類を書く |
| 小項目 | 細かい分類を書く。例えば画面名や、機能名 |
| 試験条件 | 例えば、有料会員なのか無料会員なのか、といった、試験手順を行うにあたっての前提を書く |
| 試験端末 | 色々な機種が対象である場合は、どの機種なのかを書く |
| 試験手順 | 試験を実施するにあたっての操作手順を書く。特に重要 |
| 試験結果確認方法 | 画面に表示される値やデータベースのテーブルの期待値を書く。特に重要 |
| 試験実施予定日 | |
| 試験実施日 | |
| 試験実施者 | |
| 試験結果 | 試験を行った結果、期待値であればOK、そうでなければNGを入れる |
| 試験実施環境のバージョン | ブラウザのバージョン情報や、端末のビルド番号を書く |
| 修正後の実施結果 | |
| 修正結果確認日 | |
| 修正結果確認者 | |
| 問題管理番号 | バグが見つかった場合は、修正用のチケットが切られることが多いはず。そのチケット番号を書いて紐づけしておく |
| 備考 | 何か気になることがあったら書く用。 |
| 対応する上位ドキュメントの項目番号 | 保証対象となる要件定義書や設計書の項目番号との紐づけ用 |
後編：テスト実施で気をつけたいこと
１、目的を忘れない！
バグが全く見つからない試験はありえません。
テストの目的、それは、「品質を保証すること」です。
もう一度書きます。
「品質を保証すること」です。
特に進捗が悪い場合、進捗定例で苦い顔をしないために
「とにかく実施項目数を稼ぐためにやる」
という心理になりがちですが、理想としては、バグをしっかり拾う意識を持ちたいですね。
意外な挙動を発見すれば、「○○さんが見つけてくれました！」と感謝されるはずです。
２、テスターは段取りが大事！
テスト環境の構築はなかなか難しいです。
テストデータをリーダーや実装者に準備してもらったり、テスター用のアカウントを発行してもらう必要があります。わりと時間がかかります。しかもたちが悪いことに、テスト準備は後回しにされる傾向が強いです。
また、貧しいプロジェクトだと端末やSIMカードの取り合いになったりします。
「何時から何時まではAさん使用、その後は私が使用させてください」
みたいな段取りも必要になってくることがあります。
自分だけですべて用意できる、は普通あり得ません。
段取りをしていないと、何もテストケースを消化できずに数時間過ごすことになる、ということも起き得ます。
また、テスト実施を複数人で行う場合、誰がどの項目を担当するのかを決めておかないと無駄工数が増えます。試験実施予定者列をつくって、割り振っておくと良いでしょう。
３、テスターは連絡速度が大事！！
テスター自身がバグ修正をするケースもありますが、そうでない場合、実装者（コーダー）への連絡は早いほど良いです。
質問や相談を躊躇するとあっという間に進捗が鈍化し、進捗定例で苦い顔をする羽目になります。
これは実装工程等でも同じですが、テスターでは特に顕著なのではと思っています。
テスターには、一人でじっくり問題に向き合う、ということは殆ど求められません。
どちらかというとスピード勝負ですので、フットワーク軽く動きましょう。
４、進捗が悪い時の対応①
自責で進まないのか、他責で進まないのか、切り分ける必要があると思います。
バグ指摘をしたけど、実装者がいつまでたっても対応してくれない、などはテスターの自責ではありません。
他責事由については、リーダの方などに早めに相談しましょう。
５、進捗が悪い時の対応②
バグが起きていたり、なんらかの事由でブロックされているときは、
現状で進められる項目と進められない項目とに整理分類するのが良いと思います。
特に試験項目数が多い場合は必ず行った方が良いと思います。
そうしないと、どの項目を実施するかで目移りしてしまい、結果としてロスタイムが増えることになりますし、虫食い実施になって、収拾がつきにくくなります。
６、ハイフンを書こう
記載する必要がない欄は、ハイフンを書きましょう。
これから記載する必要があるのか、何も記載するのか、明確にさせるため、記載必要のないセルはハイフンを記入しましょう。テストケースが多いと、その内わけがわからなくなります。
７、状況把握のためにExcel関数で集計しよう
試験はテストケースの実施数というわかりやすい指標があるため、進捗率が数値化しやすい工程です。関数で数がわかるようにしておくと、問題が起きてもその後の対応スケジュールが立てやすいです。
８、Excelの共有モードを活用しよう
テストが複数人で同時進行するものであり、
かつテスト項目書がファイルサーバに置いてあるならば、
同時編集できるExcelのファイル共有モードは大きな味方となります。
もちろん競合しないよう、認識合わせは必要にはなります。
最後に
テスターに「技術力」はさほど求められません。
プロジェクトによっては、テスターはソースコードもデータベースも見られないということもあります。
テスターは、軽いフットワークと段取り力が一番求められる要素だと私は思っています。
私は両方ともに力不足で苦戦してしまったので、
一年前の自分に言い聞かせるつもりでこの記事を書いてみました。
-
テストと試験は同義として書いています。 ↩