ただ読んでいるだけのドキュメントレビューは今日で卒業です。（2023年6月&7月振り返り）

この記事は？

ご無沙汰しております、まままです。
2023年6月に思ったこと（起きたこと）をまとめます。
僕の反省の振り返り（思い出話）をしつつ、皆さんのヒヤリハットな的ものだったり、皆さんの気づきに繋げて貰えればと思っています。

6月&7月はテスト設計のレビューをする機会が多かったので、その話を記録に残します。
テスト設計のレビューは、いつも実施しているのですが、6月&7月は複数プロジェクトでテスト設計期間だったり、差し込み超特急レビューが来たりと、レビューにかける工数が多かったです。
ここからは、結合テスト／総合テストでのExcelやスプレッドシートベースでのテスト設計をイメージして読み進めてもらえればと思います。
僕のレビューの意識を簡潔にギュッと書きました。

テスト設計のレビューの意義

・ドキュメントに不備がないかのチェック
ドキュメントとして不備や不足項目がないかをチェックします。
どこまで丁寧にテスト設計を作成するかにもよりますが、後で見返した時のためにも最低限の記載項目やケース／バグ数の集計ズレがないかくらいはチェックしておいた方が良いです。
・テスト設計の目的、妥当性の確認
テスト工程、テスト対象に対するスコープと合っているかを確認することでテスト実施のズレ防止に繋げます。
・カバレッジの確保
テストパターンの漏れや考慮不足を検出することでテスト全体の網羅性の担保に繋げます。
・仕様の明確化、仕様漏れ（バグ）の検出
テスト設計に落とす段階で、仕様漏れや開発設計段階での考慮不足に気づく場合が意外とあります。
開発チームにフィードバックすることで、バグの早期発見に繋がります。
（バグは可能な限り早く見つける方がコストが抑えられる。）

テスト設計のレビューの前提

・テストベースのドキュメントをレビュー時に必ず参照する
・全量はレビューできない前提でレビューを進める
・大枠でズレていないか、後述する意識するポイントや押さえるべきポイントを元にレビューをする

テスト設計のレビューで意識するポイント

・仮説を持ってテスト設計を組めているか
・一番バグが出たらヤバそうな部分はどこか、そこのテストケースはどうなっているか
・意味のないテストをしていないか
・無駄なテスト（冗長なテスト）になっていないか
レビューで意識しているポイントは上記の4点です。
特にテストの目的と一致しているかやこのテストをすることで品質担保につながるのかを意識しながらレビューをしています。
また、テスト範囲でバグが出たら一番不味そうな部分はどこか？、テスト範囲で致命的なバグはどのようなものがあるか？を自分の中（レビューアー）でも仮説を持てレビューをするようにしています。
また、冗長なケースになっていないか、意味のないシナリオになっていないか、過剰品質になっていないかに関しても重点的にレビューをしています。

テスト設計のレビューで確実に押さえること

・テストベースが網羅されているか
・テストベースと全量でトレーサビリティが取れているか
・テスト観点／テスト条件に不足がないか
上記、3点は必ず押さえます。
①まず、参照のテストベースが全量洗い出せているか？
前工程までの成果物を辿っていき、参照すべきドキュメントの全量がテストベースとして参照できていることを付け合わせします。
②今回の改修要件、変更箇所が全てテストケースに登場しているかを付け合わせします。
③テスト観点として不足はないか、テスト条件は網羅されているかの点でテスト観点、テスト条件を洗い出せているかを確認します。

まとめ

テスト設計のレビューは、ソフトウェア品質の向上とプロジェクトの効率化に貢献する重要なプロセスです。バグの早期発見や仕様の明確化など、多くのメリットに繋げることができます。
適切なポイントを押さえつつ、明確な目的のもとでレビューを行うことで、プロジェクトの品質向上に向けた一歩を踏み出しましょう。