はじめに
前回に引き続き，発注者ビューガイドラインに書かれている「コツ」の中で，テストエンジニアにとって参考になりそうなところを絞って解説していきます。今回はシステム振舞い編とデータモデル編を取り上げます。
本記事の構成
システム振舞い編は，「表現」「記述確認」「レビュー」に分かれています。本記事では「表現」から3つのコツを取り上げます。
データモデル編は，「表現」「記述確認」「レビュー」「レビュー時の確認」に分かれています。本記事では，「表現」から3つのコツを取り上げます。
コツの説明はコツごとに，「ガイドラインの引用」→「テストエンジニアが知っておくべきポイント」という構成にしています。
システム振舞い編
システム化業務一覧
システム化業務一覧の書き方のコツとして7つのポイントが挙げられています。その中から2つのコツを紹介します。
機能は階層で捉えよう
SD1001
システム化業務一覧の中のシステム化業務を，階層構造に分けて記述する。
（ガイドライン第1部-14から引用）
図1 機能階層表の例（ガイドライン第1部-14より）
図2 機能階層図の例（ガイドライン第1部-73より）
機能に関するテストは，テストエンジニアにとって一番馴染みのあるテストでしょう。テストエンジニアは，仕様書や設計書に書かれてある機能名称をもとにして，テスト仕様書を記述していきます。参考にしている仕様書に機能階層が書かれていれば，そのまま使用することができます。しかし，画面仕様書に機能が書かれているような場合，テスト仕様書を図3のように書いてしまうことがあります。
図3 テスト仕様書の例（ガイドライン第1部-14を参考に作成）
確かにこの仕様書でもテストはできます。しかし，テスト項目の漏れ，つまり機能の漏れを確認するのはかなり困難な作業になります。
画面仕様書のあちらこちらに機能が書かれている場合，漏らしてしまうことが多くなります。とくに「備考欄」に機能が書かれている場合，見落としてしまいがちです。漏れてしまうのを避けるためにも，機能は階層構造で捉えるようにします。
機能の条件を押さえよう
SD1007
システム化業務一覧に事前条件や事後条件などの情報を備考欄等を使い，記述する。
（ガイドライン第1部-20から引用）
図4 事前条件・事後条件を記述した例（ガイドライン第1部-20より）
すべてのケースに当てはまるわけではありませんが，機能テストのテスト仕様書を記述する前に，それぞれの機能に対して事前条件，事後条件，例外処理などを整理しておくと，テストケースが書きやすくなります。事前条件を満たす場合と満たさない場合，例外処理を行うデータの組み合わせなどを考えて，テストケースを作っていきます。
万一，事後条件がわからないのであれば，テストケースを書き始めてはいけません。すぐ調べましょう。事後条件，つまり，確認項目がわからなければ，テストを実施しても何が正しいのかわからないのですから。
