TEFの過去ログを1から見直そう、という活動が若手テストエンジニアの何名かで行われてます。僕のその「探検家」の一人ですが、今日は「レビュー設計」という言葉を見つけました。(設計レビューではないです)
テスト(あるいは動的テスト)という大きなアクティビティでは「分析」「計画」「戦略」「設計」「実装」「評価」というステップがありますが、レビューについてはそういったステップわけというをあまり聞いたことがありませんでした(ググってもあまり見かけないのでこの感覚は一般的かも)。過去ログを読みつつ、もんもんと考えていて、いくつか記事の中にもあったキーワード・ポイントを自分なりに整理してみました。
レビュー設計とレビュー指摘項目とガイドライン
テスト設計というのは分析した結果を元に、たとえば、ここでは論理が複雑なのでデシジョンテーブルを使おう、そこでは状態遷移が複雑なのでk-スイッチテストを使おう、といった戦略をより詳細にブレークダウンしたもの。レビューというアクティビティも同型だと考えると、たとえば、このコードについてはメンバー内ピアレビューで、このドキュメントはインスペクションで、このコード群はコミット後コードレビューもやろう、といった作業かなと。レビュー指摘項目は、より細かい勘所という意識で「変数参照に着目せよ」とか「入出力周りに着目せよ」など。ガイドラインはどちらかというと「心構え」なのかなあと考えました。
レビューと検査の違い
検査は問題を指摘することで、レビューは知恵を出し合う場・議論、という考え方があった。これについては自分の中の定義と少しギャップがあった。もしかしたら、広義のレビュー=検査(問題を指摘し、議論・解はのちほど)+狭義レビュー(プレゼンテーションとディスカッション)、みたいなイメージのがしっくりくるかな。
指摘本位とディスカッション本位
「限られた時間で問題をどんどん指摘してもらう」という考え方と、せっかく知恵袋が集まってるんだから、レビュー対象(やレビュー対象作成者)を練って練って練りまくるという考え方。目的には違いがあるが、レビュアーの限りある時間を頂戴する=効率よく目的を達成させる、という前提は一緒か。前者は短期的な視点(このプロダクト・プロジェクトでの品質向上)で、後者は中期的な視点(このプロダクト・プロジェクトも品質向上させつつ、ディスカッションによる参加者の品質?向上)だろうか。
ブラックボックスレビューとかホワイトボックスレビューとか、いろんな用語をs/テスト/レビュー/gにしてみたらどうなるかな。
# ちなみに過去ログ連番だと「4098」あたりの話題。
# 全部見終わってないので、この続きがまだあるのかもしれない。
最近のコメント