ヒューマンクレストの高橋です。
今回はQA担当者が、レビューへ参加する際のTipsを書きます。

ここでの「レビュー」は開発側より提示されるデザインレビューを指しています。
レビューの種類としてはウォークスルーです。

レビューはQA担当としては、テスト実施前の品質確認の場であると同時に、テスト準備にあたり
貴重なイベントです。

そこにQA担当が望むために必要な心がけておくことを偉そうに書きます。

①要求仕様に合致している設計になっているかの確認

当たり前ですが「要求仕様どおりにプロダクトが作られているか？」が一番重要な観点になります。

そのため、要求仕様の把握とそれを実現するための機能と大まかなアルゴリズムについては
事前に情報が入っている場合は、理解しておいて、疑問点・誤りを指摘します。

スケジュール等の問題で事前の情報が少ない場合は、その説明を求めた上で、疑問点・誤り
を指摘します。とても重要な作業です。

なお、設計側でソースコードのレビューは行っているはずなので、コードに対しての
本格的なレビュー（インスペクション）は実施する必要はありません。

ただし、コードとその流れについては、説明を受けたほうが良いです。
（もちろん、膨大なコードをレビューするのは無理なので、キモになる機能の一部のコードに限ります。）
設計時のアルゴリズムとコードとの整合性の確認は必要だと考えます。

②ユーザーの視点を持ってレビューに望む

QA担当者は開発側サイドの目線もさることながら、ユーザーが持つ視点で
レビューに望む必要があります。

ユーザーに出る前のプロダクトの品質の最後の砦になっているのが、QA担当です。
そのため、障害が発生するケースについて想定しておき、その障害が及ぼすインパクトは
どのくらいになるかを意識し、レビューに望みます。
このレビューで得た、障害が発生する可能性のあるケースをテストケースに盛り込んで
おきます。

③テストに必要な情報を引き出す

私はレビューの場をレビューだけに留めず、テスト準備の場としてとらえています。
どのようなテストを行えばよいかということを意識して、レビューに参加します。

「A機能はどのテスト手法を使えばいいかな？」
「どのようなユースケースがあるだろうか？」
「どのようなテスト機材、テストスタブが必要であるか」
「自動化するにはどうしたら良いか？」

といったことを意識してレビューを受け、不明点があれば質問を行います。
レビュー時には、上記のことについては、開発側に聞くようにしています。

開発側で実施する結合テストの項目内容も併せてレビューできると良いです。
不足している観点があれば、その場で指摘し、追加して実施してもらうようにします。

その上で、
私の場合は「どの機能を重点的にテストしてほしいか？」といったことを
聞いたりしています。どの機能がウィークポイントとなっているのかといった情報を探ります。
（ただし、その回答を全て鵜呑みにしてはダメですが。）

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

その他のレビューについての情報やポイントについては、書籍やネットにも多数載っておりますので、
参考頂ければと思います。

次回は、最近、個人的にはまっている、シェルを使うことが多いので、
「シェルスクリプトで楽をしよう」とか、「品質に関する様々な指標について」のどちらかに
しようかなと思っております。

最後まで、読んでいただきありがとうございました。

Tweet