Webアプリケーションのテスト仕様書はどのように作成したらいいのかわかりません。
勤めている会社で、バックエンドにPHPを利用しているWebアプリケーションを開発しています。
最近、PHP7からPHP8にバージョンアップして、ソースコードを修正しました。
ここで、テスト仕様書を作成して、動作確認テストを行っていこうと思っているのですが、
そのテスト仕様書をどのように作成していけばいいのかわかりません。
テスト仕様書を作成するコツを教えていただきたいです。
どういう案件なのか分からないですが
例えばお客さんにテスト設計や実施結果を提出する必要があるなら
過去のファイルを参考にしてください。
そうでなくて、今回初めてちゃんと仕様書を用意するようなレベル感であれば
何かソフトウェアテストの書籍を探すのがよろしいかと思います。
Webアプリの画面操作に関するテスト・稼働中の修正結果確認・仕様書自体は初回作成ということであれば
非機能要件はいったん置いといて、機能要件についてとりあえず2種類のテストをお勧めします。
①単機能ブラックボックステスト
②シナリオ的ホワイトボックステスト
①は画面中の細かい部品をリストアップして、
単純な操作手順・それに対して期待する結果の形でテストケースを作成します。
部品ごとの操作可能・イベント発生箇所を画面表示側・ソースコード側の双方からできるだけ漏らさずリストアップします。（クリックだけでなく、マウスホバーや画面サイズ変更etc）
入力操作がある所は、入力値の取りうる範囲から境界値・分類ごとの代表値・異常値を意識したケース作成が必要となります。
ブラックボックステストとして、分岐処理やループ条件も加味し入力値の範囲を検討しましょう。
バリデーションがあるならバリデーションの種類ごとに全てのメッセージが表示されることの確認なんかも合った方がよいです。
画面遷移であれば、遷移元・遷移先ごとに遷移できること・ブラウザバックもできるならそれも確認、など
とにかく挙げればいくらでもテストケースは増殖します。
重複したテストができるだけ増えないように考慮し計画しましょう。
②は、ユースケースごとの一連の操作のテストです。
ソースコード内のことは忘れ、ユーザ目線で実際によくやるシナリオを考えます。
できるだけ画面をまたいだ連続した操作で、1シナリオが長すぎずなおかつテストケース全体として画面がもれないように計画しましょう。
ただし、こちらもその気になれば無限にケースを増やせるので、重複が出ないように気を付けましょう。
よさげなurlをピックアップしました。
紙面の制約から書ききれないので、四方山話を!
次のどれと、あなたの求めているテストと類似してますか?
答えはテストの目的によって、異なります。
前者は品質評価
後者は不安解消のための不良品の是正
ｐ.s. 運動会の予行演習のステークスホルダーは学校の先生であり、不安を抱いている本人です。
私は体外的にはシステムテストはステークスホルダーの不安解消のために、安心させるテスト仕様書、テスト計画書、テストケース実施書を提出するセレモニーと考えています。これは正直、企業ブランドと成果物のデザインセンスが成功を左右します。
一方、開発側としては運用後、深夜障害対処に駆り出されることなく、枕を高くして眠るために、徹底して不具合を蹴落とします。これは、技術的に裏付けされたテスト体制、環境、方法論、教育制度が成功を左右します。
両者は目的としては不良品の是正ですが、成果物が品質評価のアピールと未提出のバーンダウンチャート(バグ収束図)にわかれるのが不思議です。
この矛盾する課題を如何にコスパ良く、プロジェクトを導くかが、プロジェクトマネージャーの力量であり、企業のテスト文化でしょう。
