JSTQBテスト技術者認定Foundation：2周目-第三章(16/19=84%)

後で振り返ると、100%の正答率にならなければいけない章でした。全てが、設問を良く読んでいなかったための不正解でした。

シラバスとの比較という意味で、現場の話しを。私のチームでは、以下の４つのレビュータイプを定義しています。

• パスアラウンド
• ペア
• ウォークスルー
• インスペクション

レビュアーやモデレータ、書記を別々に確保するお金の余裕が無いので、最近はほとんどがペアレビューです。内容は、ウォークスルーとテクニカルレビューを併せたような感じでしょうか。品質管理と要員教育の場になっています。最初のうちは、

1. ドキュメントやソースコードを予め読んで、指摘事項を青・赤のペンで書き込む。
2. レビューイを呼んで、一つずつ説明し、修正してもらう。(指摘事項の電子的な記録はなく、書き込んだ紙がレビュー記録そのもの)

という形でレビューをしていました。進めるうちに、私のチームメンバーに対しては、このやり方では問題があることに気がつきました。みな、経験・知識が浅く、まだ独り立ち出来ない位のメンバーだったこともあり、

1. 指摘により、改悪をする。
2. 同じ間違いを何度も繰り返す。
3. さっと見て直ぐに気付く程度のバグが多い。
4. 修正漏れが多い。

ということが良くありました。それぞれ、

1. 指摘が正確に伝わっていなかった。伝わったかどうかを確認しなかった。
2. 自分の間違いを横展開してチェックする、あるいは、自分の間違いの傾向を分析する、という行動が身についていなかった。または、間違いを本人が深刻に捉えていなかった。
3. 作成者自身にチェックスキルが無かった。
4. 全て是正したかどうかをチェックする、という行動原則が無かった。

ことが原因だと考えています。そこで、これを是正するために、最近は、以下を義務付けることにしています。

• レビュー記録を電子ファイルとして残す。
• レビューミーティングの最後に、指摘事項をレビューイが復唱する。
• チェックシートを用意して、レビューキックオフの前にレビューイが自分でチェックする。
• レビュー開始条件を定義して、達成していない場合は、レビューを中止する。

レビュー記録を付けることにより、レビュー工数がかさむように見えますが、正確に伝わらないことによる手戻りの工数のほうが大きい(と考える)ので、この方法をとることにしました。今はその成果をモニタリングしているところです。以前よりは、各人がそれぞれのレベルで品質を意識するようになったと感じています。