はじめに

★ソフトウェアテストの小ネタ Advent Calendar 2024 23日目

私の所属するチームは、QAが計画段階のレビューで仕様の漏れや欠陥を指摘し、チームに貢献する割合がとても大きいと思っています。
レビュー活動は担当者の経験やスキルがものをいう面もありますが、この記事では、レビューのときにできる「行動」は何か？に焦点を当てました。
まだ「レビューで欠陥を検出する」がピンと来てないよ、という方に読んで頂き、少しでも何か伝えられたら嬉しいです。

こんな人に読んでほしい

レビューでチームにGiveしていきたい！
漏れや欠陥をスマートに指摘して一目置かれたい！
だけど、どう気付けばいいのか分からない…
後輩を良いレビュアーとして育てたい！
テスト分析やレビューが大好き！（共感求む）

また、この記事では「既存の製品に機能追加や仕様変更を行う」場合を想定しています。
新製品のテストだと当てはまらないことも多いかもしれません・・・　ご承知おきください。

本題

レビューにより漏れや欠陥を検出するためには、とにかくレビュ―対象（仕様）について深く理解することが大事です。
これを踏まえ、私がレビューの際に意識していることは以下の3つです。

1. まずは、現行仕様について理解する
2. 実際の画面や機能イメージに置き換える
3. 残った情報を整理し、管理する

まずは、現行仕様について理解する

成熟したプロダクトの要望対応では「独立した新しい機能を付ける」よりも「現行の機能に何かを付け加える」、もしくは「現行の機能の一部仕様を変更する」ケースが多いと思います。

まずは現行の仕様と向き合いましょう。
追加や変更の内容が腹落ちしやすくなりますし、何より、のちのち現行仕様との不和や矛盾を発見するために必要な工程です。

実際の動作確認だけでなく、仕様について十分なドキュメントがある場合は一度確認しておきたいです。「何そのマニアックな仕様？」となること請け合い。
プロダクトに慣れている方も油断なさらず。過去にテストした機能でも、細かな仕様については意外と忘れていたりするものです。

実際の画面や機能イメージに置き換える

ここから追加や変更の内容を紐解いていくわけですが・・・
みなさんは、どのような形で対応内容について知らされることが多いですか？しっかりした仕様書は渡されますか？

以下は私がよく観測するケースです。
テスト担当にはペラ紙が渡されます。そこには現行画面にオートシェイプを貼り付けた雑な画面イメージが数枚と、申し訳程度に以下のような一文が書いてあります。

商品のレビューができるようにする。
商品の「あとで買う」登録ができるようにする。
（私の関わっているプロダクトの例だとイメージし辛いと思うので、ECサイトで置き換えた例になります）

・・・これは少し極端な例だったかもしれませんが、
開発サイクルの序盤で作成されるドキュメントには、本当に”概要”レベルの機能説明や、（機能そのものでなく）機能により得られる"価値"しか記載されていないことがあります。

具体的な操作フローを頭の中で再現し、手が入る（or入りそうな or入るべき）箇所を洗い出し、言語化していきましょう。
文言やEnabled変化などの細かい仕様まで確認するのは大変なので、製品マニュアルが作成できるくらいの粒度を想定すると良いです。

「あとで買う」登録の例で考えてみます。

・商品の個別ページに「あとで買う」登録ボタンを設置する。
・登録した商品はどのように確認する？
　　・「あとで買う」リストを表示する新規の画面を作成する？
　　・商品カート内で参照できるようにする？
・「あとで買う」登録後、解除したい場合はどのようなフローになる？
・「あとで買う」登録後、購入したい場合はどのようなフローになる？
・「あとで買う」登録済みの商品を購入したとき、自動で解除されたりする？　・・・

「全くイメージが湧かない」「こういうことなのかな？」「ここも変化するべきだよね？」「この仕様駄目じゃね？」など、不明瞭な点が出てきた場合は確認を取ってください。

確認を進めていく中で、こう言われることがあります。

「確かに、この仕様だとまずいですね」
「それ、やらなきゃ駄目ですね」
「何その（現行）仕様？」
「想定漏れでした」

これが漏れや欠陥です。グッジョブです。
この時、今後の判断やアクションの助けになる情報を懐から出せると、更にシゴデキですね。

この洗い出し作業→確認作業を繰り返し、対応内容の全貌が見えてきたら、いったんレビューは終わりです。

残った情報を整理し、管理する

上記の作業が一通り終わると、手元には以下の情報が残ると思います。

決まったこと
決まっていないこと
まだ確認を取っていないこと

これをそのままにしておくと、

決まったことが実装担当者や要求保持者に伝わっていない
いつまでも決められずに放置される
確認しなければならないことを忘れる

・・・このような悲しい事態になる可能性があります。

残った情報を整理し、今後きちんと処理されるよう管理していきましょう。

チームの状況や規模にもよりますが、スプシやLoopなどのチームで共有の場に投げ、全員で管理してしまうのもお勧めです。

あとがき

なんだろう・・・「長い」「薄い」「分かり辛い」内容になってしまった気がしています。軽い気持ちで参加しましたが、想定していたより大変な作業でした。コンスタントにアウトプットされている方の凄さを実感します。定期的なアウトプットのトレーニングが必要ですね。
早期の欠陥検出により「GJ！」「ありがとう！」と言われる瞬間は、QAとして非常に喜ばしく、自信に繋がるものです。そのため、経験の浅い人にこそ、レビューに挑戦してほしいと思います！
読んで頂き、ありがとうございました！！