はじめに
前回の記事を読まれた皆さんは，「発注者ビューガイドライン」（画面編）をダウンロードされましたか？ 今回の記事は画面編が手元に置いてあることを前提にして進めますので，まだの方は，すぐにでもダウンロードしてください。
ダウンロードされた方はお読みになりましたか？ PDFのページ数にして291ページ（表紙含む）のドキュメントです。PCで300ページ近くある文書を読むのは大変ですし，かと言って印刷するのも大変です。結局面倒になって読まなかったかもしれません。
その気持ち，よくわかります。そこで，本記事ではテストエンジニアが知っていても良いと思われるコツをいくつかピックアップして紹介します。馴染みのあるコツがいくつかあれば，いつか膨大なドキュメントも制覇できるでしょう。
本記事の構成
「発注者ビューガイドライン」（画面編）は，大きく「表現編」と「レビュー編」に分けることができます。「表現編」はさらに6つの成果物に分かれています。そこで，本記事もガイドラインの構成に沿って，テストエンジニアが知っておいても良いコツを取り上げていきたいと思います。
説明はコツごとに「ガイドラインの引用」→「テストエンジニアが知っておくべきポイント」という構成にしています。
画面一覧
画面一覧の書き方のコツとして6つのポイントを挙げています。その中から2つ紹介します。
画面の全体像を知ろう
FD1001
システム全体で必要とする画面の全体図が作成されている。
システム全体としての画面の抜けや漏れや重複を確認でき，作業の優先度も確認できる。
システムの全体像に関する合意を得やすくする。
（ガイドライン第1部-14 から引用）
図1 画面の全体図の例（ガイドライン第1部-14より）
画面のテストを始める前に画面構成，つまり全体像を押さえましょう。画面一覧表ではなく，画面構成図のような全体図で理解します。もし，全体が俯瞰できるドキュメントが無ければ，テスト工程の最初の方で作ります。たとえ自分の担当している部分が一部であったとしても，全体像を知るように努力します
自分の担当している箇所が全体のどこに位置しているのかを知ることにより，テストの意味が明確になります。
画面の分類を知ろう
FD1002
画面一覧に記述する分類には，あらかじめ定義された分類を使用する。
また，未定義の分類については，新たな分類として定義した上で使用することにより，未定義の分類の使用による混乱を避けることができる。
（ガイドライン第1部-15 より引用）
図2 画面の分類の例（ガイドライン第1部-15より）
画面一覧に分類が書かれていなければ，テストケースを書き始める前に画面の分類を行います。同じ分類に属する画面は，テストケースの構成が似てきます。最初から画面を分類し，画面分類毎にテストケースのテンプレートを作成しておけば，テストケースの質が向上します。
画面遷移
わかりにくい画面遷移は書き直す
FD2003
画面遷移の遷移矢線が錯綜していると，処理の流れが煩雑になり，ユーザを混乱させる。
FD2004
画面遷移が上から下，左から右に遷移するように配置する。
（ガイドライン第1部-44より引用）
図3 画面遷移図の良い例，悪い例（ガイドライン第1部-44より）
画面遷移のテストを設計する際，そのもとになるべき画面遷移図が良くない書き方になっていた場合，画面遷移図から正しい情報を読み取れず，間違えたテストケースを書く可能性があります。テストケースを書く人とテストを実施する人が異なっている場合，余計な手間がかかってしまいます。
「ぱっと」見てわかりにくい画面遷移図を開発チームから手渡されたら，書き直してもらうか，テストチームの方で書き直してしまいます。書き直す手間を惜しんでも，後で手戻りが発生してしまうことがあります。手戻りが予想されるぐらいなら，さっさと書き直してしまった方が楽です。
