ソフトウェア品質シンポジウム2014参加レポート② レビューについて学んだよ
ソフトウェア品質シンポジウムに参加し、レビューについて色々学んできました。このエントリーは以下の前提でお読みください。
-
社内でGitをもっと有効活用するためのテストとレビューについての議論が盛り上がってきている
- 僕自身はテスト自動化の面でその議論に参加予定。なのでレビューとは？みたいなところについてきちんと理解したい
- また、業務上、テスト容易性等の観点で仕様書のレビューはするが、積極的にバグを探すためのレビューの経験はない
- そういったモチベーションで参加したレビューのトラックとレビューとテストは使い分けるべきか？というパネルディスカッションの内容をもとに書いています。
- もちろん僕のフィルターを一度通っているので、僕が間違って理解している部分等がある可能性があります。間違いを見つけた方はご指摘のほどよろしくお願い致します。
レビューについて考える上で
どういったレビューが効果的か考える上でまず重要になる事は
- まずレビューの大前提に則る
- レビューとテストはそれぞれ得手不得手としている部分が異なる
- その上でコンテキストから、レビューの目的を明確にする
の3つだと思いました。
レビューの大前提とアプローチ
- レビューの一番の目的は欠陥を見つけ出す事。欠陥を見つけ出すという目的の上ではその観点はテストと同じ。
- ただし、レビューはテストで見つけられない保守性の問題を見つけられる。また、教育や知識の共有という面もある。
- 加えて、テストはErrorを見つける事が出来るがExtraとMissingは見つけられない。一方でレビューはExtraとMissingを見つける事が可能
- 前工程であるレビューで見つけた方が、効率的にバグ修正が可能な欠陥がある。
こういった大前提を踏まえますと、
- レビューでは、レビューでしか見つけられない保守性、Extra, Missingを見つける事が最重要
- また、教育や知識の共有といった側面でレビューを行う事も組織的に有効
- それ以外の部分についてはテストとレビューの得手不得手を理解した上で、コンテキストに応じてレビューの目的を定義する
というアプローチになるのは必然ですね。
テストとレビューの得手不得手
では、テストとレビューの得手不得手は何か？パネルディスカッション中の井芹さんの事例紹介のスライドにまとめられていました。
＊注 紹介にあたって「あくまで個人の一例であり、一般的なものではない」との補足がありました。
９枚目のスライドです。
この表を踏まえて
レビューの得手として
- テストよりもレビューの方が要求や設計を変える影響力を発揮しやすい
- 再現性が低くテストでは検出コストが高い欠陥を、達人のレビューによって低コストで発見出来る
- レビューにテスターが入る事でテスト項目を減らす事が出来る
- 探索的テストとレビューは似ている
レビューの不得手や問題点として
- 観点が属人的になりやすい
- チェックリストなどにしてしまうと、プロセスが形骸化してしまう可能性がある
- レビューで網羅性の担保を考えると、得手であるスピードが下がってしまう
- スピードを重視するあまり、準備期間をとらない事で不毛な議論に終始してしまう事がある
といった点が挙っていました。
コンテキスト重要
上記のような得手•不得手が一般的に考えられますが、
- どういった欠陥を見逃すとリスクが大きいか
- どれくらいアジリティが重要視されるか
- どういう欠陥は、レビューで見つけると修正コストを少なく済ます事が可能か
といったコンテキストは会社やプロジェクトによって大きく異なる。プロジェクト毎にレビューの目的と見つけたい欠陥を事前に決めてから行う事が重要、というお話でした。
私の所属している会社ですと、ウェブ系のアプリケーションのレビュー観点というのが共通であって、その上でサービスの性質ごとにコンテキストに沿ってカスタマイズしていくのかな、と思います。
これ以上は、会社に持ち帰ってからの議論ですので今はここでは書きません 笑。
ハーベスタ
もう一つレビューに関連して面白いと思ったのは、レビューのトラックで提案されていたハーベスタという役割です。レビュー観点や見つかった欠陥についての知見を蓄積する事で、より重要な欠陥を早く見つけられるようにしようという取り組みでした。
まとめ
レビューについて全然知識がなく参加したのですが、大前提のところを理解出来たかなと感じます。また、その得手不得手についてテスト、レビューそれぞれのエキスパートの方達のお話を聞く事で、引き出しが増えたのかなと感じます。発表者、パネルディスカッション参加者の方ありがとうございました。
