WACATE 2009 夏 レビュー合宿が終了

先週末、三浦海岸で開催された「WACATE 2009 夏」が無事終了。のちほど、実行委員会のレポートがでることでしょう。

参加者によるレポートもトラックバックで受け付けてます。

　WACATE（ソフトウェアテストワークショップ）
　http://wacate.jp/

　WACATE 2009 夏
　http://wacate.jp/2009/summer/

　WACATE 2009 夏　参加者レポート集
　http://wacate.jp/2009/summer/reports.html

WACATE 2009 夏 参加申込開始

WACATE 2009 夏　の参加申し込みが始まりました。今回から年齢制限なしで受付開始です（前回までは若手優先で受付）。

　WACATE（ソフトウェアテストワークショップ）
　http://wacate.jp/

　WACATE 2009 夏　開催概要
　http://wacate.jp/2009/summer/

　WACATE 2009 夏　プログラム
　http://wacate.jp/2009/summer/program.html

　WACATE 2009 夏　参加申込
　http://wacate.jp/entry/

レビュアー7つ道具

自分はまだまだ熟練エンジニアとはいえないのだが、チーム内では比較的経験年数が多いほう。なので、レビュアーをお願いされることが多い。主に、設計レビューやコードレビュー、テストケースレビュー、メンテナンス手順レビュー。そういうレビュアーをするときに意識していることをQC7つ道具になぞらえて、レビュアー7つ道具という名目でまとめてみた。

1. チェックシート



「チェックシート」は2つの用途で使います。一つ目はレビュー観点をまとめたシートです。それはコーディング規約の類であったり、仕様書であったり、過去の指摘項目リストであったりします。例えば、コードレビューにおいて、変数の初期化、スコープが適切であるか、などなど。もうひとつはレビュー対象リストです。基本的にはある程度細かい単位でレビューすることが多いですが、関数や処理といったリストを使う場合もあります。
「チェックシート」の目的は、実施漏れをなくしたり、レビュー対象の規模を把握したり、記録用にも使います。




2. 対話



パスアラウンド方式であれば難しいところはありますが、ミーティング形式ならば「対話」というツールをうまく活用すべきだと思います。対話をさらに分けるならば「疑問」「質問」「自問」でしょうか。




• 疑問

単純にレビュアーが理解できなかったことについて解説を求めます。レビュアーの理解もそうですが、作成者にとっては説明するということが理解を深めることにもつながると思います。

• 質問

疑問と似ていますが、レビュアーがある程度推測できることや、完全に理解していることを、あえて問うてみます。レビュアーの頭の中では作成者のロジックの組み立てをチェックしたりもします。

• 自問

所感やリスク分析などを促し、作成者に考えさせて自己解決・認識させます。人に「これではだめ」といわれるよりも自分自身で「これではだめ」と気づくことも重要。



　「対話」の目的は、理解度の共有でもあり、コードレビューについていえば作成者のクセ・センスを確認することができ、この情報は今後に役立つ可能性もあると思っています。




3. 分割



「分割」も2つの用途で使います。一つ目はレビュー対象の分割を行い、単純化とレビュー時間の細分化を行います。もうひとつはレビュアーの役割分割です。自分のチームでは基本は複数名のレビュアーとしているので、各人の切り口を変えてレビューを進めたりします。
　「分割」の目的は、単純化と細分化、切り口を多くしてより多くの欠陥を探すことができると考えます。




4. ズームアウト・ズームイン



「ズームアウト」はレビュー対象を大枠で眺めることで単純化し、逆に「ズームイン」はレビュー対象の詳細について査読します。IF文の入れ子ブロックであったり、画面全体仕様と各画面の仕様であったり。大枠についての査読をした後、細かいところについてチェックをする、比較的常套手段かな、と。
「ズームアウト・ズームイン」の目的も、単純化と細分化ですが、見方によってはモデル化ともいえるでしょうか。



5. 日本語化・口語化



「対話」と関連してきますが、図表やコードをレビュアーが「日本語化/口語化」して説明して、作成者との認識チェックを行います。あるテスト技法について学ぶときも、複数の書籍を見比べて勉強したりしますね、それに似ていると思います。物事を換言することは理解を深めるときに重要だと思います。
「日本語化・口語化」の目的は、作成者の脳とレビュアーの脳が同じインプットに対して同じアウトプットが出せるか、という視点でチェックをする、みたいなイメージです。




6. 将来設計



「将来設計」とは、ソフトウェア/システムの将来的な規模、拡張性、引継ぎなどを考慮します。これにはいくつか特性があると思いますが、




• スケールアウト可能か


• 拡張・変更が容易か


• メンテナンス・引継ぎが容易か




といったところでしょうか。
「将来設計」の目的は、文字通りの将来の品質に着目すること。




7. 休憩



1時間くらいで「休憩」を取り、頭を休めたり、作成者と会話を楽しみます。レビューは人間関係も大切です。作成者もレビュアーも作成物の品質向上とエンジニア自身の成長につながるようなレビューを心がけるようにしています。

同僚の作成物のレビュアーをする機会は多いと思いますが、皆さんはどんなツールをお持ちですか？

[本]ピアレビュー―高品質ソフトウェア開発のために

ピアレビュー―高品質ソフトウェア開発のために

posted with All Consuming at 2008. 8.12

by Karl E.Wiegers, 大久保 雅一
日経BPソフトプレス
定価： ￥ 3,045

Amazon.co.jp で詳細を見る
All Consuming でブログの評判を見る
crossreviewのレビューを見る

ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章～第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。

第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS　vol.2でインスペクションについての記事が載っている。また、ドロシー・グラハムのソフトウェアインスペクションも読んでみたいな。

レビュー設計

TEFの過去ログを1から見直そう、という活動が若手テストエンジニアの何名かで行われてます。僕のその「探検家」の一人ですが、今日は「レビュー設計」という言葉を見つけました。（設計レビューではないです）

テスト（あるいは動的テスト）という大きなアクティビティでは「分析」「計画」「戦略」「設計」「実装」「評価」というステップがありますが、レビューについてはそういったステップわけというをあまり聞いたことがありませんでした（ググってもあまり見かけないのでこの感覚は一般的かも）。過去ログを読みつつ、もんもんと考えていて、いくつか記事の中にもあったキーワード・ポイントを自分なりに整理してみました。

レビュー設計とレビュー指摘項目とガイドライン

テスト設計というのは分析した結果を元に、たとえば、ここでは論理が複雑なのでデシジョンテーブルを使おう、そこでは状態遷移が複雑なのでk-スイッチテストを使おう、といった戦略をより詳細にブレークダウンしたもの。レビューというアクティビティも同型だと考えると、たとえば、このコードについてはメンバー内ピアレビューで、このドキュメントはインスペクションで、このコード群はコミット後コードレビューもやろう、といった作業かなと。レビュー指摘項目は、より細かい勘所という意識で「変数参照に着目せよ」とか「入出力周りに着目せよ」など。ガイドラインはどちらかというと「心構え」なのかなあと考えました。

レビューと検査の違い

検査は問題を指摘することで、レビューは知恵を出し合う場・議論、という考え方があった。これについては自分の中の定義と少しギャップがあった。もしかしたら、広義のレビュー＝検査（問題を指摘し、議論・解はのちほど）＋狭義レビュー（プレゼンテーションとディスカッション）、みたいなイメージのがしっくりくるかな。

指摘本位とディスカッション本位

「限られた時間で問題をどんどん指摘してもらう」という考え方と、せっかく知恵袋が集まってるんだから、レビュー対象（やレビュー対象作成者）を練って練って練りまくるという考え方。目的には違いがあるが、レビュアーの限りある時間を頂戴する＝効率よく目的を達成させる、という前提は一緒か。前者は短期的な視点（このプロダクト・プロジェクトでの品質向上）で、後者は中期的な視点（このプロダクト・プロジェクトも品質向上させつつ、ディスカッションによる参加者の品質？向上）だろうか。

ブラックボックスレビューとかホワイトボックスレビューとか、いろんな用語をs/テスト/レビュー/gにしてみたらどうなるかな。

# ちなみに過去ログ連番だと「4098」あたりの話題。
# 全部見終わってないので、この続きがまだあるのかもしれない。

テスト設計レビューによる掘り起こし

プロジェクトが発足するときに、「とりあえずざっくりと外部仕様まとめて」という感じでドキュメント初版を作成し、その後まともな改訂が行われない場合が、僕を含めて周りでは少なくない。当然、仕様はプロジェクトが進むにつれてブレたり、変更したり、追加されるのが常。そうなると、仕様書に載っていることをベースにテスト設計を行う間にどんどん網羅率が下がっていく。しかも、当人が認識できないことも多い。

これを踏まえて、テスト設計レビューというプロセスは、テスト分析-テスト設計の妥当性をチェックすると同時に、そういった埋もれている仕様やポイントを掘り起こして、設計担当者当人に隠れたリスクを認識させる大きな意義があると僕は思う。テスト手法でよく知られている同値分割・境界値分析・エラー推測も、この場面では掘り起こしの手法に姿を変える気がする。

ここらへんはあとでまとめてみて、勉強会のネタにしよっと。