レビューではこういう欠陥を、テストではこういう欠陥を
「レビューはテストを前倒しして実施するものなので、テストの観点をそのまま使ってレビューで欠陥を検出すればよい」という話を聞くことがあります。私はこれを、正しいときもあれば間違いのときもあると感じています。
ここでのテストの観点は、どういったテストを実施すべきかという方針を示したものを想定しています。テストケースの塊を分類するときに、実行結果に誤りがないか、性能は十分かといったその塊の目的を表しているのがテスト観点です。
また、ここでのレビュー は要求、設計、コードレビューを想定しています。また、プロセスレビューでは なくプロダクトレビューであり、欠陥や問題を検出することを想定しています。
テストでは、通常、なるべくテスト件数をしぼりながらも対象ソフトウェアが期待どおり作られているかを網羅的に確認することが開発関係者の間の共通認識となることが多いと思います。実際にもれなく確認することは簡単ではありませんが、「どういうテストをしないといけないか？」という問いに対しては、網羅的なテストを実施すべきという点を念頭にあれこれと考えていることが多いと思います。
レビューでも同様に網羅性をもとめる場合もありますが、網羅性が全てというわけではないように感じています。レビューで欠陥を検出したとしても後に続く開発活動において新しいバグを埋め込んでしまうと、レビューとテストでの評価作業が二度手間になることもあります。
リリースが近くなった時点で非常に大きな設計変更や方針変更によって、場当たり的な修正を余儀なくされると、「早く知っていればもっと打てる手があったのに」ということになります。レビューでは、そういった「もっと早くわかっていれば．．．」という欠陥や問題を検出することを念頭において欠陥や問題を検出することに注力すべきだと考えています。
とはいえ、「後で後悔しそうな欠陥を今検出してください」というのは「網羅的なテストをしてください」というくらい難しいので、それほど簡単ではないのはテストのときと同じなのですが．．
もちろん、リリース日は固定ではないので欠陥の修正は将来のことを見据えてじっくりと、とにかく欠陥検出のフロントローディングを、有識者がレビューで確認したという事実が大切、開発メンバの間で連帯責任の形で合意をとっておきたい、ユーザの言質がほしい、等、開発のコンテキストやレビューに期待することが異なっていれば、この前提はかわります。
研究活動において開発での課題やレビューがうまくいかないことに関して多くの状況を教えていただくことがあります。上のような状況をはじめとして普段から私が感じていることをお伝えする機会を二ついただきました。ご参加ください。
- 「ソフトウェア品質向上活動におけるプロダクトレビューの役割と効果」
レビューの役割や効果を主眼においたチュートリアルです。
2014/9/7(日) 13:00～16:00 場所は名古屋大学 東山キャンパスです。
詳細: http://jssst2014.wordpress.com/events/product-review-tutorial/
申込み: http://jssst2014.wordpress.com/participation/ - 「パネルディスカッション - レビューとテストは使い分けるべきか？」
ソフトウェア品質シンポジウム2014の1セッションとして2014/9/12(金) 12:40～14:20 場所は東洋大学白山キャンパスです。
セッション詳細: http://www.juse.jp/sqip/symposium/detail/day2/#session_D4
モデレータ:
細谷 泰夫 氏 三菱電機（株） 通信機製作所 情報技術部
パネリスト：
岩橋 正実 氏 三菱電機メカトロニクス(株) 和歌山支所
湯本 剛 氏 日本ヒューレット・パッカード㈱ アプリケーション・ビジネス サービス統括本部
井芹 洋輝 氏 株式会社豆蔵
森崎 修司 名古屋大学
申込み: https://www.juse.jp/sqip/symposium/form/step1/