3. 試験する切り口を洗い出す
観点と目的を混在しがちですが、違う言葉を使うと「切り口」のようなものです。
例えば・・・
- 表示されている内容が正しいかどうか
- 画面の遷移が正しいかどうか
- 入力項目された文字のチェックが正しいかどうか
などなど、試験の切り口となる項目を洗い出します。
機能を洗い出すことと同様に、切り口の洗い出しも足りなければ、試験ができなくなってしまい、品質も下がる可能性が高くなってしまいます。
4. 試験仕様書を書く
この工程が一番大事です。
上記3つの工程を踏まずに試験仕様書からいきなり書くと抜け漏れが連発しますが、ある程度機能や切り口が出ていれば、それに沿って書いていくだけです。
上述したサンプルと合わせて、書いてみます。
- 試験目的：機能試験
- 試験観点：表示内容の確認
- 試験項目1：下記に列挙
- ヘッダーに表示されている文言が正しいかどうか
- h1タグに埋め込まれている文言が正しいかどうか
- 表示されているデザインが正しいかどうか
- 表示されているフォントサイズが正しいかどうか
- 表示されているフォントの種類が正しいかどうか
- ボタンにオンマウスすると、プルダウンメニューが◯個表示されること
などなど・・・・。
サイトの構成要素（デザインや文章やボタンなど）を上から順に、機能と切り口に沿ってできる限り書き出しましょう。
数は多くなりますが、その分試験をするということなので、品質がグッと上がるはずです。
5. 試験を実施する
さあここまで準備ができたら、いよいよ試験の実施です。
試験の実施は制作担当者・試験設計者・試験実施者の3人に分けるのが理想的です。
というのも、作り手はロジックやデザインが頭の中に入ってしまっているので、先入観が生まれて注意力が低下してしまいがちです。
いくら素晴らしい試験仕様書を作ったとしても、実施の段階で見落としてしまっては意味がないですからね。
とはいえ、リソース的な都合もあると思います。
試験設計者が試験を実施する場合は、先入観や理想論は全て捨ててフラットな頭で望みましょう。項目が多くなりがちなので、先が見えない大変な作業になりますが、疑いの目を持って望むことが大切です。
さて実施後にも重要なポイントがあります。
もし試験を全て終えて、バグが1件も出なかったとしたら。
- 「よっしゃ。さすが◯◯さん（プログラマー）。バグが一個も出ないぜ」
とはならず、試験の手法や工程そのものを疑いましょう。
初回の試験でバグが1件も出ないなんて、そんなうまい話は世の中ありません。
バグを出せない、見つけられないのは試験設計者が恥ずかしいと思うべきポイントなので、こんな結果になってしまったら、疑い続けましょう。
いろんな人に試験仕様書をレビューしてもらい、それでもバグが出なかったら、作った人を褒め称えましょうw
さいごに
さてさて、いかがでしたでしょうか。
今回はおざなりになりがちな試験について、書いてみました。
試験が好きな人は多くないですが、品質が上がることでデメリットなんてひとつもありません。
試験が好きなエンジニアの方には、優秀な人がたくさんいらっしゃいます。
新人ディレクターといえど、品質の高いサイト制作を目指して、がんばりましょうー！
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
