まいどです。BiTT事業部のやなさんです。
突然ですが、皆さんは開発したWebサイト・Webサービスのテストに向けてどのような準備をしていますか？
案件受注の際、見積もり明細などを出すかと思いますが、金額調整する際にテスト工数って削られがちですよね。でも、いざ納品すると、「あれができてないやこれができてない。表示までに時間がかかるんですけど。」みたいなクライアントからのご指摘を受けた経験ってWebサイト・Webサービスに関わった方なら一度はあるはず。
正直、いろいろ言い訳したいときもありますが、そういったときに限って要件を満たしていない不具合が起きていたり、説明不足など、この業界が長くなってしまった私にとっては、涙ちょちょぎれる位どうしようもない状況を経験してきました（そのときはとてもとても辛かったです……w）。
そのような際に、「ちゃんとドキュメントを残してコンセンサスをとっていれば、切り分けて説明できたのにな」と反省するのですが、案件規模・期間によってどうしても作成できないことがよくあります。
今回はそのような辛い経験をする人が少なくなることを願い、私の経験から考える、「時間がなくてもしっかり定義しておいたほうが良い3つのドキュメント（「テスト計画書」「テストシナリオ」「テストケース」）」についてお話します。
では、さっそく。
ドキュメント1.テスト計画書
テスト計画書とは、
- テストの目的と方針
- テストの範囲や観点
- テスト手法
- スケジュール
- 成果物
- 合否判断の基準
- 注意事項・制限事項
などを明記したドキュメントとなります（本当はもっとありますが、書き出すと切りがないので割愛します）。
このドキュメントの目的は、システム全体で行うべきテストのなかから、要件・規模に応じて
- どのような観点で
- どの範囲を対象に
- どのようにテストを実施し
- 何を持って問題なしと判断するか
を定義するものとなります。
やみくもに気づいたものや指摘されたものをテストするのではなく、システム全体を鑑みて、「アプリケーションだけでなく、サーバー構成などを含むすべてのシステムがこういうものだから、我々としてはこういった目的でこの部分のテストを実施します。」という意味をもつドキュメントとなります。
このドキュメントを作ることで、テストすべき項目の中から、費用に合わせたテスト範囲を明確化し、ドキュメントとしてテスト範疇のコンセンサスを取ることが可能です。
また、テスト計画書を定義するからこそ、後ほど説明しますが、テストシナリオが決まったり、その中のテストケースとしてどういったテストをすべきかを明確にする大元のドキュメントになります。
ドキュメント2.テストシナリオ
テストシナリオとは言葉の通り、実際のユーザーの立場に立って、システムとしてどうなるべきかをシナリオベースで定義したものとなります。WordPressを例にあげると、記事を投稿するや、記事を予約投稿する、記事を削除する、メディアをアップロードする、などです。
ユースケーステストに少し似ているものですが、イメージとしてはシナリオをまとめたものとして位置付けられるものなので、ユースケースより少しブレイクダウンしたものとなります。
こちらを定義することで、ユーザーが利用するオペレーションに合わせたテストを実施でき、よりユーザーに近い観点でテストができます。そして、自身の理解度を測ることもできます。
システムにどういう機能が実装されているかが理解できていないと記載できず、「シナリオが網羅できない＝システムを完全に理解できていない」証拠です。
システムを完全に理解できていないままの状態で、後述するテストケースを作成しても、抜け漏れのあるテストを実施することになってしまい、不具合を見逃すことになってしまいます。
ドキュメント3.テストケース
テストケースとは確認項目になります。イメージとしてはテストシナリオに沿って実施していく中で確認する項目を定義したものです。
こちらも例を上げると、
- 検索フィールドを未入力のまま検索ボタンを押した場合、◯◯◯が表示されること
- 検索フィールドに□□を入力して検索ボタンを押した場合、△△が表示されること
などです。
テストケースをただただ羅列すると、何を想定して何のために確認しているかがわかりくい状態になることがありますが、テストシナリオに沿って確認ポイントを整理していくことで、網羅性と抜け漏れが少なくなり、品質アップにつながっていきます。
最後に
Webサイトだと、社内のナレッジを活かしてチェックリストなどを作成して、デザイン通りに作成されているか確認しますし、入力項目がある場合は仕様に応じてチェックリストを追加してテストをしているかと思います。
しかし、どんなにしっかりテストをしたと思ってもやっぱり抜け漏れが出ることはありますし、時と場合によっては「そこまで求めます？？」と心の中で思っちゃうことってありますよね？
「そこまで求めます？？」となってしまう多くの原因は、クライアントと我々で「テスト」というものに対して「対象範囲」に認識の齟齬が生まれていることだと思っております。
こういった認識の齟齬をなくすため、自分たちの考えるテストがどういうもので、どういったテストをするかをクライアントに対して、しっかり説明しておくことも受注する側として重要であり、それが会社にとってのトラブル回避に繋がっていきます。
今回記載した内容はテストという考え方のほんの一部であり、完璧なテストをこなそうとすると、開発の流れであるV字モデルや、システム規模や費用間に応じたテストボリュームの妥当性など、もっともっと理解しなければならないことがたくさんあります。
そのなかでまず、品質担保とテストの抜け漏れをなくすためには、必要最低限のドキュメントを作成していくことは必須です。そのドキュメントがクライアントを含む関わるメンバー全体でテストに対する共通認識を持たせることができ、さらにそれがエビデンスにもなります。ドキュメントを使い回せる形でナレッジとして蓄積させることも良さそうですね。
それでは、ほなまた。
やなさんでした。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
