1.テスト項目書を書くときは用語集を作ること
用語集を作れば
- 表記ブレを防げる
- 重複を減らせる
毎回説明を記述する必要がなくなるので全体はコンパクトになる。
テスト実施者に重複した内容を何回も読ませる奴はDRY原則をわかってない、自殺すべき。
2.ユースケースシナリオと単体テストの項目が合ってないのはどっちかがおかしい
ユースケースシナリオと単体テスト項目の内容がずれていたら「正しい仕様」を確認する。
ログインに失敗したときのメッセージが
- ユースケースシナリオでは「パスワードを確認してください。」
- 単体体テスト項目では「IDとパスワードのいずれかが間違っています。」
と書いてあったら？メッセージが出ているのだからテストに合格したと判断するのはダメ。
仕様もテスト項目も確認しないでリリース直前に「これおかしくないですか？」とかドヤ顔言うやつは、自殺すべき。
3.ユースケースは能動態で試験項目は受動態で書くこと
ユースケースシナリオは主語をユーザやシステムにし能動態（○○する）で書くこと。
「誰」の動作か明確になる。ユースケースシナリオのうちどの部分が、テスト項目に書く「操作」と「確認項目」になるのかが明確になる。
- ユーザはIDとパスワードを入力し、ログインボタンを押下する。
- システムはIDとパスワードの対応を確認し合っていればメニュー画面を表示する。
試験項目の確認事項は受動態（○○になっていること）で書くこと。
- 操作：ログイン画面を表示し、IDにTEST_USER、パスワードにpassword1を入力しログインボタンを押下する。
- 確認項目：メニュー画面が表示されること。
ユースケースを受動態で書くやつは仕様を他人事として考えている、自殺すべき。
おまけ。文トリガーの単体試験項目には複数行更新、PK更新のテストケースを入れること。
トリガーでバグ出して本番運用に支障をきたすやつは、自殺すべき。
あ・・・、俺だ。
参考図書
