そこで今回受入テストをやってみて勘所になりそうだと思ったこと・気づきを共有したいと思います。トピックとしては、「①受入テストって何？」「②受入テストの品質は受入テスト開始前に9割決まっている」「③受入テストのスケジューリングのコツ」「④受入テストで指摘が挙がった時の考え方」の4つです。
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
受入テストとは
受入テストの楽しさ
まずは、「受入テストとは」についてです。
皆さんは「受入テスト」に対してどんなイメージを持っていますか？私は受入テストを結構楽しいタスクだと思っています。
テストの中では単体テスト、結合テスト、総合テストと進んで最後の工程となるため、「品質担保の最後の砦」という責任の重いタスクである一方、V字モデルでは要件定義と対になるタスクでもあります。そのため要件定義フェーズでみんなでああでもない、こうでもないと議論しながら頭の中で描いたプロダクトが、目の前で動いていることの感動を味わえるフェーズでもあるわけです。アイディアが形になって動くのを見ると嬉しくなりますね。
受入テストには「狙い撃ちテスト」と「狙わないテスト」がある
実際に受入テストを初めて担当する人にとっては、「受入テストって言っても何をやるの？」とイメージがつかないかも知れません。一般的にも明確な種別が存在するわけではないと思うのですが、自分の中では大きく分けて「狙い撃ちテスト」と「狙わないテスト」の2種類があると思っています。
狙い撃ちテストは、その名の通り「○○したら●●になる」という明確な条件と結果があり、その通りになっているかを確認していくテストです。要件定義書と見比べて、要件通りになっているか確かめていくテストはこちらにあたります。また、ソフトウェアの機能は正常系の業務フローで使用されるものと、異常系の業務フローで使用されるものがあり、狙い撃ちテストはこの観点でさらに「正常系テスト」と「異常系テスト」の二つに分けられます。
狙い撃ちテストでは、この「正常系テスト」と「異常系テスト」のうちまずは「正常系テスト」からテストしていきます。正常系の業務フローで問題なく操作することが出来れば、8割の業務は回すことが出来ると考えられるからです。例えば、何らかの申請で差し戻しがなく承認されるパターンや、最もよくあるデータの組み合わせでのテストです。ここがOKであれば、まずは80点です。次に、「異常系テスト」をテストしていきます。例えば、何らかの申請で差し戻しがあるパターンや、ユーザが正しくない操作をした時のエラー処理などを確認するテストです。ここもOKであれば、狙い撃ちテストとしては合格です。
狙い撃ちテストが合格であれば、次に狙わないテストに進みます。狙わないテストは”何となく”いろいろと探索的に操作してみるテストで、特に追加開発の際に重要になるテストです。理由は、追加開発ではどこか一か所を変更したことで思いもよらないところに影響が出る・意図しない部分が変わってしまう、ということが起こりうるからです。（私は過去この事象に何度も苦しんだことがあります。。）こうした事象は「変えたところがきちんと変わっているか」という観点だけでテストしていると見逃してしまいます。「思いもよらないところに影響が出ていないか？」を確認するのは狙ってやることは難しく、むしろ”なんとなく”操作していると見つかるものです。このように、デグレチェックの観点から「狙わない」テストもやるようにしています。
結合テストと受入テストの違い
結合テストと受入テストとの違いについても少し触れておきたいと思います。追加開発のような比較的規模の小さい改修の場合、結合テストと受入テストは操作シナリオとしては被ることもあり、違いが曖昧になることもあります。しかし、たとえ結合テストと受入テストで同じような操作をしていても、それぞれのテストは観点が大きく異なります。結合テストはV字モデルで言うと概要設計(基本設計)と対になるタスクであるため、”概要設計通りに動くか？”ということを確認するテストです。一方、受入テストは要件定義と対になるタスクであるため、”これで業務上の要件を満たすことが出来るか？”ということを確認するテストです。ですから、受入テストは業務要求を深く理解していて、業務要件と照らし合わせて確認できる人が実施する必要があります。
受入テストの品質は、受入テスト開始前に9割決まっている
次に、「受入テストの品質は、受入テスト開始前に9割決まっている」ということについてお話ししたいと思います。
今上流フェーズをやっているという方は、「受入テストはまだまだ先」と思わずに是非読んでもらえたら嬉しいです。私は受入テストの品質を決めるものは、大きく「要件定義の質」と「業務パターンの理解」があると思っています。
要件定義の質
まず要件定義の質についてです。
受入テストは要件定義書の内容を照らし合わせて要件を満たすものになっているか確認するプロセスですので、「要件が受入テスト可能な状態で書かれているか」が重要なポイントになります。アジャイル開発の現場ではシステム要件を記述する文書（＝「要件定義書」にあたるもの）を「ユーザーストーリー」と呼ぶことがありますが、そこではよく書けているユーザーストーリーは以下の6つを満たしている(INVEST)と言われます。
- Independent（独立している）
- Nagotiable（交渉の余地がある）
- Valuable（価値がある）
- Estimatable（見積もれる）
- Small（小さい）
- Testable（テストできる）
６つの詳細な説明は割愛しますが、ここでも「Testable(テストできる)」ということが、いいユーザーストーリーの条件にあげられています。ですので要件を記述するときには、受入テストで使えるドキュメントになっているかという観点でもレビューしましょう。要件定義時点で、ある程度どんな受入テストをするかイメージできればOKです。最近個人的には要件定義書というよりも「受入テスト仕様書を作っている」という意識で臨む方がいいのではないか、という仮説を持っています。内容が大きく変わるわけではないのですが、要件定義書は「出来るようにしたいこと」をまとめたものですが、受入テスト仕様書は「○○が出来るようになったらこうしたことが実現される」というニュアンスが強くなりより明確に記述できるのではないかと思っています。
なお、INVESTについてさらに詳しく知りたい方は「アジャイルサムライ」という書籍で紹介されていますので是非読んでみてください。
業務パターン理解
次に業務パターンの理解です。本コラム冒頭で、狙い撃ちテストでは正常系のテストをした後に異常系のテストをします、とお話ししました。しかし、意外とやるのが難しいのが異常系のテストです。異常系のテストを行う際には異常系のデータパターンを用意する必要があり、そのためには四半期に1回や年に1回などの周期で行う低頻度の業務や、その業務に伴って発生するデータのパターンを知っている、または普段ユーザがどのようなミスオペレーションを起こしやすいか、といったことを知っている、といった知識が求められます。
こうした知識は受入テストが始まってから収集するのはなかなか難しいので、上流の段階からアンテナを張っておく必要があります。業務パターンの収集・蓄積は「これをやればOK」という特効薬がないプロセスですが、例えば業務ヒアリングの際にユーザに特殊な業務がないか確認する、普段ヘルプデスクなどでユーザのオペレーションに精通している人に見てもらう、ヒアリング情報だけに頼るのではなく実機を確認して特殊なデータパターンがないか見ておく、といった工夫が考えられると思います。先日お客様と共同で受入テストをした時にはお客さんがこの異常系のテストがとても上手で、やはり普段の業務を深く理解しておくことの重要性を改めて感じさせられました。
後編へ続く…
