こんにちは。QAグループの松谷(まつや)です。
みなさんはテスト計画を行なっていますか？
テスト計画では、「どのテストレベル」で「どの対象」に対して「どのようなテスト」をしていくかという、テストのアプローチを定めることが大切です。
このテストのアプローチの有無によって、プロダクト全体としてMECEで効率的なテストになるのか、抜け漏れが多い残念なテストになってしまうかが決まってきます。
今回は、プロジェクトチームと共にテスト計画を作成する「テスト計画コンシェルジュ」をご紹介します。
テスト計画コンシェルジュとは
テスト計画コンシェルジュは、横断組織であるQAグループによるテスト計画作成代行サービスです。
プロジェクトチームからテスト計画コンシェルジュの依頼を受け、テスト計画ミーティングを行います。
そのミーティングでプロジェクトチームと一緒にテスト計画を考えます。
このときスケジューリングなどを含めた全ての計画を行うわけではありません。
我々とプロジェクトチームが話し合って、テストスコープを明確にし、互いに腹落ちするテストのアプローチを定義します。
テスト計画コンシェルジュの流れ
テスト計画コンシェルジュは、プロジェクトチームから依頼があったときに実施します。
依頼はチケットで管理されています。その際の入力項目は以下です。
- 施策概要
- 規模（人数と全体工数）
- 開発拠点
- 開発期間
- 既存リスク
このチケットで概要や規模感を把握し、テスト計画コンシェルジュのミーティングをセットアップします。
1:施策の概要を聞く
ミーティングが始まりましたら、最初にテスト計画の対象となる施策の概要を聞きます。
施策の全体像を聞き、どういったことを実現したいのか把握します。
依頼チケットでもおおよその概要は把握してから臨んでいますが、認識のすり合わせを行なっていきます。
2:テストアイテム、テストスコープを明確にする
概要を聞きつつになりますが、徐々に話を掘り下げ、その施策のテストアイテムを洗い出していきます。
概要からわかるテストアイテムもあれば、
「○○は関わってこないのですか？」
「あ、そうですね。影響があるかと思います」
と、問答することで新しく浮かび上がってくるテストアイテムもあります。
他施策やシステムとの関わりなどは、横断組織である我々だからこそ気づく場合もあります。
さらにテストアイテムについて質問を交えながら話を掘り下げ、テストスコープを把握していきます。
「不安だからとりあえず全体的に」といった話も出ます。
ですが、テストする機能は何で、テストしない機能は何かをはっきりさせないと、テスト工数が膨れ上がってしまいます。
3:どのテストレベルでテストすればよいか考える
テストする機能を細かく分けていくと、テストする粒度が見えてきます。
例えば以下のような粒度です。
- ロジックがメインで計算結果を確認したほうがよい機能
- CRUDのような処理や、インターフェイス部分を確認したほうがよい機能
- 他機能やシステムとの連携が多く、それらを通してテストしたほうがよい機能
これらが見えてくると、どのテストレベルでそれらのテストを行うかが見えてきます。
見えてきましたら、テストする機能をどのテストレベルで行うか当てはめていきます。
- ユニットテスト
- 統合テスト
- システムテスト
- （受け入れテスト）
テストレベルを考慮しない場合、ほとんどのテストがシステムテストに偏っていくので注意が必要です。
4:テストのアプローチを組み立てる
ここまでで、どの機能を、どのテストレベルでテストするかが見えてきました。
次は、それらについてどのようにテストをするか、テストのアプローチを組み立てていきます。
テスト計画の段階ですので、プロダクトに対しての全体的なテストの枠を組み立てるイメージです。
詳細なテストの組み立てはテスト設計段階で行うことになります。
ここでは行うべきテストタイプや、探索的テストといったテスト方法を挙げて組み立てることが多いです。
（私はついついテスト設計段階のことまでしてしまうこともあります…）
各機能のことだけではなく「システムテストに入ったらまずは大きなバグを見つける目的での探索的テストをしましょう」といった作戦も伝え、テストの流れも組み立てることもあります。
この「どのようにテストをしていけばいいか」というアプローチが見えることにより、プロジェクトチームはテスト工程が見え、やるべきことがわかり、安心します。
5:プロダクトリスクを挙げ、そのリスクが考えたアプローチでケアされているか確認する
最後にプロダクトリスクを聞いていきます。
プロダクトリスクはそのまま聞いても意見が出ないことがあるので、以下のようなことを聞きます。
- 不安なこと
- 起きて欲しくないこと
この際、プロジェクトリスクとプロダクトリスクの双方の意見が出てきます。
ここではプロダクトリスクにフォーカスします。
プロダクトリスクはテストによってケアできるためです。
このとき挙がったプロダクトリスクが、先に組み立てたアプローチでケアされているか確認します。
この活動が、アプローチの抜け漏れチェックとして働いています。
例えば
「実際の業務フローでちゃんと動くのか不安」
といったリスクが上がったら
「業務フローを使ったシナリオテストを追加しましょう」
と漏れていたアプローチに気づき対応することができます。
まとめ
QAグループが行なっているテスト計画コンシェルジュの紹介でした。
テスト計画は、時間がかかりそう、という理由で敬遠されがちです。
ですが、何も計画も立てずにテストに臨んだ場合は、非効率なテストになったり、抜け漏れが発生する可能性が非常に高いです。
恐らく最後にはテスト計画にかける労力以上に膨大な労力が費やされてしまうでしょう。
今回紹介したテスト計画コンシェルジュでは、機能をいくつか追加といった規模の施策の場合、60分のテスト計画ミーティング内で行われます。
この時間でしたら敬遠するほどの長時間でもないですし、アジャイル開発にも組み込みやすいのではないでしょうか。
最後に2011年の"Ten Minute Test Plan"を紹介して終わりたいと思います。
