7. FV表のV
アドカレ7日目は「FV表のV」。
VはVerificationのV。
「目的機能」のテストなのだから妥当性確認（Validation）のVでは？というエキスパートがいるかもしれない。
FV表のVはあくまでもFの欄に明記したものを確認するのであるから「検証」である。
逆に言えば、暗黙の要件はHAYST法では取り扱わない。（より正確に書くと、暗黙の要件は取り扱うが、明文化する方法で取り扱うので結果としてテスト設計以降では、暗黙の要件は考えない）
顧客の「要求」、「ニーズ」、「問題」、「課題」をテスト対象が解決できているかどうかが気になる場合は、それらについて6W2Hのどこかにあるはずなので、暗黙の要件を想像して目的機能に直してFの項に明記する。
これは、開発やテストの責任を明確にするうえで非常に大切なことである。
さて、具体的にVに何を書くかだ。
スクラムでユーザーストーリーをバックログ管理しているケースなら、そもそもFV表は不要で、バックログにアクセプタンスクライテリア（AC：Acceptance Criteria）を書いておけばよい。
バックログがユーザーストーリーで表現している場合は、ACには「ユーザーストーリーの受け入れ基準」を書く。
FV用のVもACと全く同じで構わない。さらに言えは、書いたものは「ハイレベルテストケース」となる。
ただし、「ユーザーストーリーの受け入れ基準：AC」も「ハイレベルテストケース」も“ふわふわしたもの”になりがちだ。
そこで、Vには【因子】を列挙すると良い。
結果に影響を与えるものを要因と呼ぶが、要因のなかで、特にテストに取り上げる要因のことを因子と呼ぶ。
FV表のFには「機能の目的」もしくは「ユーザーが達成したいゴール」が機能とともに書かれている。テストをしたいのは「さまざまな条件下で目的やゴールを達成すること」だ。この「さまざまな条件」と「因子」は同じものだ。
ただし、ラルフチャートを作成するときにもう一度因子について洗い出しをするので、FV表をつくるときには眉間にシワを寄せてウンウン唸るほど頑張らなくてよい。