##試験仕様書
完全なウォーターフォールでない場合、だいたい
「要件と設計」を同時にやって
「製造と試験仕様書」を同時にやって
って感じなんじゃないでしょうか。
って状態を前提として
試験仕様書を書く際、注意しておきたいところをまとめてみました。
品質にダイレクトで関わりそうな部分なので注意深く作りたいですね。。
##試験観点をつくる観点
どんな観点があればいいのか、いまとなっては先人たちがとてもきれいにまとめてくれているので
まずは以下を参考にしてほしい
参考：テスト仕様書
観点としてだいたいこう。
・入力値のパターン全部網羅
バリデーションが値範囲なら、境界値highと境界値low、正常代表値、異常代表値、とかを確認。
バリデーションが文字数なら、...など。
・件数の上限について確認する場合
100件が上限ならその前後とかも確認。
・性能的に
商用にて1000件とかで運用されるなら、2000件はどうなのか、とか。
・タイムアウト系
API中に他のAPIとかやる場合、内側でタイムアウトしても外側が包括しているか、など。
・期待値について
かならず明確に。
期待値が違う場合は、いくら似てても別ケースとして試験を作ったほうが良い。
似てるからいいやで試験不足してバグになったらえらいことに
##ではテンプレートは
まず試験仕様書の作成と、試験仕様書のレビューがある。
次に、試験実施して試験仕様書に結果を報告、次に試験結果レビュー。
なので、試験仕様書レビュー欄と、試験結果レビュー欄、が欲しいところだが
試験仕様書レビュー欄はさすがにいらない。間違ってた時点でなおせ。
加えて、追加改修/新規改修にかかわらず、「前回の試験仕様書に新観点を追加」し
カラム「試験実施対象かどうか」を用いることで
いつも同じ観点、粒度を保つことができる。
また、
画面の下のほうに新しい項目追加したので試験観点追加
とした場合
画面の上のほうがバグってないか確認をするときに
いままでの分の「試験実施対象」を「〇」にするだけで済む
必要カラムをまとめると
・項番
・試験区分
・機能区分1
・機能区分2(適宜変えよう)
・試験手順
・期待値や確認手順
・実施対象かどうか
・必要な証跡の種類
・確認結果
・確認者名
・確認日時
・バグチケット記載欄
・証跡レビュー結果
・証跡レビュワー名
・証跡レビュー日時
・備考欄
とかになるのかと思う。