はじめに
前回に引き続き、発注者ビューガイドラインに書かれている「コツ」の中で、テストエンジニアにとって参考になりそうなところを絞って解説していきます。今回はシステム振舞い編とデータモデル編を取り上げます。
本記事の構成
システム振舞い編は、「表現」「記述確認」「レビュー」に分かれています。本記事では「表現」から3つのコツを取り上げます。
データモデル編は、「表現」「記述確認」「レビュー」「レビュー時の確認」に分かれています。本記事では、「表現」から3つのコツを取り上げます。
コツの説明はコツごとに、「ガイドラインの引用」→「テストエンジニアが知っておくべきポイント」という構成にしています。
システム振舞い編
システム化業務一覧
システム化業務一覧の書き方のコツとして7つのポイントが挙げられています。その中から2つのコツを紹介します。
機能は階層で捉えよう
図1 機能階層表の例（ガイドライン第1部-14より）
図2 機能階層図の例（ガイドライン第1部-73より）
機能に関するテストは、テストエンジニアにとって一番馴染みのあるテストでしょう。テストエンジニアは、仕様書や設計書に書かれてある機能名称をもとにして、テスト仕様書を記述していきます。参考にしている仕様書に機能階層が書かれていれば、そのまま使用することができます。しかし、画面仕様書に機能が書かれているような場合、テスト仕様書を図3のように書いてしまうことがあります。
図3 テスト仕様書の例（ガイドライン第1部-14を参考に作成）
確かにこの仕様書でもテストはできます。しかし、テスト項目の漏れ、つまり機能の漏れを確認するのはかなり困難な作業になります。
画面仕様書のあちらこちらに機能が書かれている場合、漏らしてしまうことが多くなります。とくに「備考欄」に機能が書かれている場合、見落としてしまいがちです。漏れてしまうのを避けるためにも、機能は階層構造で捉えるようにします。
機能の条件を押さえよう
図4 事前条件・事後条件を記述した例（ガイドライン第1部-20より）
すべてのケースに当てはまるわけではありませんが、機能テストのテスト仕様書を記述する前に、それぞれの機能に対して事前条件、事後条件、例外処理などを整理しておくと、テストケースが書きやすくなります。事前条件を満たす場合と満たさない場合、例外処理を行うデータの組み合わせなどを考えて、テストケースを作っていきます。
万一、事後条件がわからないのであれば、テストケースを書き始めてはいけません。すぐ調べましょう。事後条件、つまり、確認項目がわからなければ、テストを実施しても何が正しいのかわからないのですから。
システム化業務フロー
システム化業務フローの書き方のコツとして6つ挙げていますが、コツではなくコラムを紹介します。
エンタープライズ系システムでも状態の遷移を知ろう
図5 状態遷移図の例（ガイドライン第1部-50より）
エンタープライズ系システムにおけるテストの場合、あまり状態遷移図を基にしてテストケースを書く機会は少ないかもしれません。多くの場合、業務フローに基づくテストを実施していれば、業務の状態（業務ステータス）を意識しなくてもよいからです。
しかし、お客様の業種／業態によっては、顧客の状態の変化によってシステムの振舞いを変えなくてはいけないことがあります。このようなケースのとき、本来ならば仕様書に状態遷移と処理動作の関連が書かれていなければいけないのですが、書かれていないことがあります。
そのような場面に立ち会ったら、状態遷移図を書いてシステムの振舞いと対応づけしたドキュメントをさっさと作り、お客様に確認していただきます。テストケースを書く基になるドキュメントが無いと嘆くぐらいなら、書いてしまった方がましです。
システム化業務説明書
システム化業務説明書の書き方のコツとして5つ挙げています。その中から1つ紹介します。
シナリオを考えよう
図6 シナリオの例（ガイドライン第1部-60より）
システムの利用者がシステムをどのように使い、その使い方に対してシステムがどのような反応をするかをシナリオ形式で表現します。ガイドラインでは、要求を導き出す分析シナリオとして説明していますが、本記事では検証用シナリオとして利用します。このシナリオはテストケースの基になります。
シナリオには、基本／代替／例外の3つのタイプがあります。基本シナリオとは、正常に終わる代表的なパターンのことです。代替シナリオは正常に終わるのですが、基本シナリオとは異なったシナリオを表現したものです。基本シナリオの異なったバリエーションと考えてもよいでしょう。例外シナリオは、シナリオが正常に終わらなかった場合です。基本シナリオは代表的なものを取り上げるために通常1つですが、代替と例外のシナリオは複数存在することもあります。
シナリオをテストで用いる場合には、基本／代替／例外という大きな分類をしてから、システムの振舞いに関するテストを考えていきます。シナリオに書かれている入力項目や「～情報」に着目し、その中からシナリオに影響を与える項目を抽出します。後は、いつも使っているテスト技法を用いて、テストケースを書いていきます。
シナリオをいちいち考えなくても同様のテストケースを書けますが、シナリオを用いた方が「なぜそのテストケースを書いたのか」がわかりやすいというメリットがあります。
データモデル編
エンティティ一覧
データモデル編は工程成果物ごとに分かれていません。しかし、本記事では工程成果物ごとに分類して説明します。
データを管理する主管部署を明確にしよう
図7
エンティティ一覧の例（担当部署あり：ガイドライン第1部-17より）
エンタープライズ系システムの場合、誰でもデータを扱えるわけではありません。社員に関するデータは人事部が責任を持ちますし、受注に関しては販売部が責任を持ちます。販売部に所属している人が勝手に社員データを増やすことはできませんし、受注取り消しを人事部の人が操作できるようになっていてはいけません。
このようにシステムの機能をテストするだけではなく、「誰が」使えるのかという視点でのテストも重要になります。このテストを実施するためには、主管部署・担当部署を知る必要があります。さらに、このエンティティ一覧には書いてありませんが、どんな役割の人が操作できるのか（担当者・役職者など）まで押さえておくとテストケースを書きやすくなります。
データ件数や保存期間を押さえよう
図8 エンティティ一覧の例（保存期間あり：ガイドライン第1部-18より）
データの件数や保存期間も確認し、それに応じたテストを実施しなければなりません。機能テストではなく非機能のテスト、つまり、性能テスト（ボリュームテスト）を行います。性能テスト（ボリュームテスト）のテストケースを作成するためのインプットとして、この情報は必要です。
また、データ件数や保存期間を開発工程の最初の方で重要視しなかったために、性能がでないシステムになってしまったという事例はたくさんあります。テストで確認しなくてはいけないのですが、テスト実施よりも前の段階からデータ量を考慮した設計やプログラミングを行わなくてはいけません。
CRUD図
CRUDを知らなければ、このガイドラインで覚えよう
図9 CRUD図の例（ガイドライン第1部-23より）
CRUD図は、エンタープライズ系のテストエンジニアにとって必ず覚えなければいけない図表です。もし知らなければ、このガイドラインに書かれているMD3001～MD3004、つまりCRUD図に関して書かれているコツをすべて読んでください（「データモデルなんて関係ない」と思っている人でもこのコツだけは読むこと）。
そして、読むだけではなく、実際の業務で書いてみてください。書いてみるとCRUD図の威力がわかります。
CRUD図というのは、いくつかのバリエーションがあります。図9に書かれているビジネスプロセスや画面ではなく、プログラム名称だったり関数名称だったりすることもあります。しかし、テストエンジニアにとって必要なのは、どのビジネスプロセスでどのエンティティと関連があるのか、どの画面とどのエンティティが関連するのかを知ることです。この情報を得ることにより、テストのシナリオを作成しやすくなるからです。
さて、ガイドラインについてまだまだ書き足りないところがたくさんありますが、約束の字数に達してしまいました。後は、ガイドラインをダウンロードして読んでみてください。難しいところは後回しにしてもよいので、全体をとおして読みます。そして、テストに使えそうな知識を自分のノートに書き写していきます。このような努力を積み重ねることにより、一段上のテストエンジニアになれると思います。
参考文献：発注者ビューガイドライン （システム振舞い編）ver.1.0
発注者ビューガイドライン（データモデル編）ver.1.0
