仕様書のレビュー

仕様書のレビューを行い、仕様策定段階で仕様の検討漏れを指摘することで、
後工程の実装やテストの段階で発見した際に比べ、修正コストを格段に抑えることができます。
つまり、仕様書のレビューは"コスパ"が良い活動なのです。

▼観点リスト

そもそもなぜこれを実装するのか？
いつ使用するのか、頻度は？
- 特定の期間、キャラ、コラボ限定か？
- 普段使いするのか？
- 今すぐ使わない仕様まで盛り込まれていないか？
いつリリースするのか？
- アップデートメンテ明け直後か？
  - アップデート前に〇〇している人は？
    - 引き継ぐとどうなる？
  - 新規ユーザーはどうなる？
- 時限の仕組みがあるか？
  - 事前はどうなる？
  - 事後はどうなる？
  - またぎの瞬間はどうなる？
- 解析対策は必要か？
  - 情報初出はいつか？
他の機能とどのように組み合わせて使用するか？
発生/発動するタイミングは？
- 競合するものがあるか？
- 優先度は？
お知らせ・ヘルプはどうするか？
障害発生時、取り返しがつくか？
- 補填が可能か？
- 機能を塞ぐことが可能か？
今後の拡張予定・構想は？
テストツールが新規で必要か？
スクショを撮れるタイミングがあるか？（バイラルしそうか？）
Androidのバックキー（戻るボタン）を押したときの戻り位置は？
本実装による影響範囲は何か？

大抵、その機能単体の仕組みは考えられていても、
他の機能と競合した際の処理については網羅できていないことが多いです。
仕様書に書いていないことは何か？を念頭に考えていきましょう。

その為の資料作りとして、QAは既存機能の裏仕様や歴史（この組み合わせはNG、実はこんな背景があったんですよ。。等）も含め、網羅的に知識を溜めて行く必要があります。

テストケースのレビュー

仕様書を元にテストケースができたら第三者にレビューしてもらいます。
レビュアーは企画、エンジニア、デザイナーの方でも良いですが、
必ずQAからはレビューをもらうとよいです。

▼観点リスト

このテストの方針は何か？
- 要件（大事なところ）を捉えているか？
- バグを検出するためのテストなのか、動作保証をするためのテストなのか？
各テスト項目について、なぜこのテストをするのか、理解できる書き方になっているか？
テストが全て実施できそうか？
- テストデータの準備はできているか？
- 工数を鑑みて優先度付けがされているか？
仕様書記載の仕様について全て、テスト項目があるか？
正常系だけでなく、異常系のテスト項目があるか？
- 無効な値、境界値のテスト項目があるか？
- エラー処理について、期待値が正確に記載されているか？
環境系（OSや特殊な端末固有の機能）の考慮があるか？
影響範囲のテストに関して、抜け漏れがないか？
期待値が曖昧でないか？（正しく動作すること、等）
状態遷移や他の機能との組み合わせについて、種類が網羅できているか？
- 同時期に実装されるものも考慮しているか？
無駄なテストがないか？
- データQA時にすべきテストまで含まれていないか？
- 同値分割は適切か？
類似の機能のテストケースと比較して、抜け漏れがないか？
- 過去の不具合事例がカバーできているか？
テストケースのテンプレート（標準観点）に追加できそうな項目はあるか？

テストケースについては、各チームで標準観点といったテンプレートのようなものがありますが、
レビューに対する観点も、忘れずにブラッシュアップしていきたいですね。

▼参考にさせて頂きました
https://qiita.com/ktanizaki/items/e6266899263e8f26b5e4
http://jasst.jp/symposium/jasst18kansai/pdf/S3B-1.pdf
https://qualab.jp/materials/q_te.140528.color.pdf