ご無沙汰しています。Yoです。
JSTQB FLの学習は順調でしょうか。前回に引き続き、今回もJSTQB FL対策として、私が学習中に躓いた箇所を解説しようと思います。今回は「レビュー」に関してとなります。私が個人的に最も苦手だった箇所ですので、同じく苦手意識を持っている方の手助けができれば幸いです。
前回の記事はこちら JSTQB FL対策 弱点強化解説 ～1回目～
レビューとは？
まずは「レビューとは一体何か？」という所から説明していきます。とはいえ、レビューとは何であるかについては、詳細な解説記事がSqripts内にあるため、そちらに解説を任せるとして、ここでは簡潔に説明をします。
「レビュー」って何をするの― さまざまなソフトウェアレビューの種類・特徴を紹介
レビューは一般的に「批評」という意味であり、成果物の確認やチェックをするといった活動です。
JSTQBシラバスにおいては、主に3章「静的テスト」にて扱われています。
テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
ここではレビューも一つのテストとして紹介されています。レビューがテストであるというのはいまいちピンと来ないかもしれませんが、静的テストというものに答えがありそうです。
静的テストに関しては以下のような記載があります。
静的テスト技法では、動的テスト技法（テスト対象のソフトウェアの実行が必要）と異なり、作業成果物を人手で調査（すなわち、レビュー）したり、コードや他の作業成果物をツール主導で評価（すなわち、静的解析）したりする。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
静的テストとはプログラムを動かさずにドキュメントやコードを確認するテストのこと、とのことです。確かにこう聞くとレビューも静的テストの特性と一致しています。
静的テストもテストの1つの技法であるので、その目的は欠陥を発見することにあります。つまりレビューをおおまかにまとめると、「成果物を確認し、欠陥を見つける」活動ということになります。
レビュー種類について
レビューについて簡単な解説が済んだところで、この章では、レビューの種類について解説したいと思います。レビューには参加者や目的などで主に4種類に分けることができます。JITQBシラバスに記載の順序でそれぞれ説明します。こちらも詳細は過去の記事がありますので、簡潔に進めます。
非形式的レビュー
欠陥の検出を目的とし、形式的な方法に則らない方法です。他の呼び方として「バディチェック」、「ペアリング」、「ピアレビュー（ピア＝同僚）」と呼ばれるように、「知見のある同僚など」に「サッと見てもらう」という場合が非形式レビューになり、手順や成果物が厳密に決まっていないため、柔軟性があります。
例えば、隣の席の同僚などにサッと見てもらい、明らかな誤りなどがないかを確認してもらう。といったものも非形式的レビューになります。個人の印象ですが、簡単な修正のチェックや、もっと形式的なレビューの準備として行う事が多いです。
ウォークスルー
主に作成者が主導するレビューになります。レビュアーはチーム内のメンバーであることが主で、作成者が主体となり、他のメンバーがコメントや意見を述べる形式です。先に非形式という単語が出ましたが、これは手順や成果物が厳密に決まっていないという意味で、ウォークスルーは非形式なものもあれば形式的なものまで様々です。
開発やQAなどのチーム内で行うレビューというとウォークスルーの場合が多いかと思います。成果物の作成者が説明をしながら主導するため、チーム内の認識合わせといった側面もあります。また、非形式的レビューと同様に、より形式的なレビューの前段階として行われることもあります。
テクニカルレビュー
主に作成者以外が主導する形式的なレビューになります。レビュアーにも技術の専門家が参加する場合があるなど、非形式レビューやウォークスルーに比較してより専門的な視点から評価が行われるものとなります。
専門家が参加し、別の解決方法はないかなど、技術的な議論を行うことが目的となります。
ウォークスルーと比較し、専門家の関与といった点で、一般的に公式度合いがやや高いものになります。
インスペクション
形式的、という尺度で見ると最も形式的なレビューになります。スケジュール、開始と終了基準、参加者の役割といったものが決められており、作成者が他の役割を担わないなど、役割が役割やフローが厳密に定められています。更にレビューの成果をプロセス全体の改善に活用するなど、目的も成果物を精査する以上のものがあります。
指摘事項を修正し再度レビューをしたりすることもあります。イメージとしてはこれまでの3種よりもオフィシャルな場（チームの統括への報告、取引先とのレビューなど）で用いられることが主かと思います。
なぜ苦手なのか
ここで少し脱線です。本シリーズは弱点強化と銘打っており、私が苦手だった箇所の解説を行っています。そこで、単に解説するだけでなくどうして苦手だったかを探ってみたいと思います。弱点を克服するヒントがあれば幸いです。
共通している内容が多い
基本的に技法の解説や、ブラックボックスかホワイトボックスかといった問題はそもそも被る内容があまりないため「それは何の説明か」という1対1の理解で事足りることが多いです。が、各レビュー手法の特徴に関しては共通する内容が非常に多く、1対1の理解では対応できないことが多いです。
例えば、レビューの目的「異なる実装方法の検討」はウォークスルーとテクニカルレビュー両方に共通する目的となるため、問題を解くにあたって「共通しているのでこの目的だけでは判断できない」ということも覚えていなければいけません。
これらの問題を解消するために、各レビューの特徴を素早く覚えられるようにまとめることが重要だと考えています。そのために以降の解説では、各レビューの特長を整理することに重点を置いて解説していきます。
問題を解く上でのポイント
上記のような分かりにくさを解消するために、いくつかポイントを絞って解説したいと思います。
目的の違いを覚える
共通の内容があるということは既に説明した通りですが、それを全て覚えるのではなく、そのレビューで固有のものを1つを覚えておくことで各レビューがどういったものか判別がつきやすくなります。
シラバスの各レビューの目的の内、固有のものは以下になります。
- 非形式的レビュー：影響度の小さい問題の迅速な解決
- ウォークスルー：標準や仕様への準拠の評価
- テクニカルレビュー：新しいアイデアの創出
- インスペクション：ソフトウェア開発プロセスの改善
先ほど説明した各レビューの説明と絡めて考えると理解がしやすいかと思います。非形式レビューは「サッと見てもらう」レビューになるため、目的にもスピード感を意識したものが含まれるのが特徴です。
ここで厄介なことは、主にテクニカルレビューの「新しいアイデアの創出」についてです。ウォークスルーの目的で「さまざまな技法やスタイルに関するアイデアの交換」というものがあります。JSTQBの文言そのままであれば問題ないですが、選択肢の文章が独自のものになっていると上記二つの判別はほぼできなくなるため、目的だけでテクニカルレビューだと判断することはできなくなります。
参加者の違いを覚える
次に各レビューで特徴的なものは参加者の役割です。役割についてはシラバスでは作成者、マネージャー、ファシリテーター、レビューリーダー、レビューア、書記の6つが定義されています。それぞれのレビュー種類によってどのようになっているのか見てみましょう
- 非形式的レビュー：作成者と同僚によって実施
- ウォークスルー：作成者が主導
- テクニカルレビュー：経験を積んだファシリテーター（作成者ではない）が主導するのが理想
- インスペクション：役割が明確に決まっている ※個々の詳細は割愛
それぞれ最も特徴的な部分を抜粋しています。上記のように大きく異なる点は、誰が主導するのかという点にあります。ウォークスルーとテクニカルレビューで主導する人物が変わっているという点が1つのポイントになります。
テクニカルレビューとインスペクションでは主導する人物は同じなため、その他の役割が明確かどうかという点で差が生まれます。
レビューの特徴のまとめ
ここまででレビューの特徴の解説ですが、文字では把握がしにくい部分もあると思うので、以下にテーブルとしてまとめました。こうしてみると、形式度合いが上がるにつれて厳密になっているのが分かります。
レビューに参加するメリット
いかがでしたでしょうか。レビュータイプの特徴について整理できたでしょうか。ここからは解説ではなく、レビューへの取り組みといった内容を解説したいと思います。
要件定義などのレビューにQAが参加することのメリットをいくつか紹介します。
第三者目線、ユーザー目線の提供
QAはユーザー目線でのテストを行うことも多いため、開発者とは異なる視点から成果物を評価することが多いです。そのため、レビューの傾向が開発者目線のリスクやアプローチに偏らないようにすることが可能です。
テストに対するリスクを早い段階で検知
更に、成果物に対してどのようにテストをするかという事を早い段階で考えることができるようになるため、テストデータの必要性であったり、ブラックボックステストでは確認が困難であるなどといったテストを行う上でのリスクを早い段階で検知できます。結果としてテストの成功にも貢献することができます。
レビューの成功要因
最後にレビューの成功要因について軽く説明させてください。シラバスにはレビューの成功要件として個別にまとめられています。それだけ重要な概念となります。ここで全てを紹介すると長くなってしまうため、最も重要と考えるものを紹介します。
シラバスには成功要因の一つとして以下のような記載があります。
- 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。
スキルや知識といった内容ではなく態度や心がけに近いものですが、そもそもどのような指摘やアドバイスであっても受け手が納得しなければ意味がありません。受け手が発言を受け入れられるように態度や説明には気を配る必要があります。
最後に
これで今回のレビュータイプの解説を終了します。レビューが苦手と感じている方の助けになれたでしょうか。
ではまた次の記事でお会いしましょう。
