WEBアプリの試験項目を作ること意識した方がいいと思うこと

最近社内で自分以外のメンバーが試験項目の作成をすることが増えてきています。
この機会に自分の中にあるノウハウの明文化をかねてブログの記事にしようと思います。
対象はWEBアプリになります。

1.試験の手順と結果の書き方について

試験項目では試験手順と確認項目が大事です。原則的に試験項目はそのWEBアプリのことを知らない人を前提に操作を書いていく必要があると思います。
（とはいえPC操作の完全な初心者ではなく、マウスやキーボードの操作能力などはある前提ではあります）
例えば会員登録についての試験手順を記載する場合、そのWEBアプリをある程度わかっている事を前提としてはいけません。

会員登録の試験をさせたいのなら、以下のような画面操作を試験項目として記載する必要があります。

画面操作の目的が会員登録だとわからなくても、手順に従って行えば会員登録ができるということが理想です。（あくまで試験項目の手順としては、わからなくても登録できるのが理想ですが、自分がやっている試験項目が会員登録だとわからない方が良いというわけでもないです。）
また、確認する結果についても登録が成功した、エラーになったとするのではなく、
具体的に画面ベースで何が起こるのか書く必要があります。

あくまでも、客観的にわかる事象ベースに手順と結果を書いていくことで、だれがやっても同じ手順、同じ事象（結果）を確認できるように表記をしていく必要があると思います。

2.表記ゆれしない

次に大切なことは、手順や結果を書く際に、同じ行為を別の表現で書かないようにすることです。
別の表現で書いてしまうと、今までとは別の方法（手法）や結果と勘違いされる可能性があるからです。

3.ユーザーが実施できる導線をしっかり意識する

会員登録の正常系の導線が、入力画面→確認画面→完了画面とした場合、この遷移での試験はもちろん作成されると思いますが、
大事なのは、確認画面から入力画面に戻ることも可能な作りになっている場合は、入力画面→確認画面→入力画面→確認画面→完了画面のような経路での試験もやるようにした方がいいです。
確認画面からもどった場合に実は大切な情報が消えるといった事故などを防げるようになるはずです。

4.境界を意識する

10文字しか入力できない項目があった場合、10文字ピッタリ、9文字だけ、11文字などその境界値付近の試験をすることが大事です。

5.組み合わせを意識する

試験項目ではその組み合わせが大事なこともあります。

任意項目についても試験のたびに入力だけして未入力の試験をしないと、実は任意項目も入力必須になっていたという不具合を見逃してしまいます。

いくつものパターンを網羅できるよう試験の組み合わせを考える必要があります。

まとめ

試験項目を作成するのは大変手間がかかる行為です。
ただし上記のようなレベルで作成していれば、エンジニア以外でも試験が実施でき、エンジニア以外が試験を実施することで、見落としがちな問題点も発見しやすくなります。試験の中でエンジニア以外の視点からの発見によりアプリとしての使いやすさが上がると思います。
そのためにもPJでは試験項目を作成する時間、試験を実施する時間をしっかり確保した上での開発が大事だと思います。