過去の自分に伝えたいこと：レビューをなめるな！

はじめに

長年、SE兼PGとしてシステム開発に従事してきました。

そのキャリアのかなりの部分を先人たちの不具合対応に費やしてきました。

その経験を活かして、2023年9月にISTQB（International Software Testing Qualifications Board：国際ソフトウェアテスト資格認定委員会）のCertified Tester Advanced Level Test Analyst (CTAL-TA)の資格を取りました。

ISTQB は、ソフトウェアテスト技術の普及とそのスキル認定を行っている国際団体です。日本では、ISTQBに加盟するJSTQBという団体が資格試験の運営を行っています。

CTAL-TAは、ソフトウェアテストの技術的な側面に精通したテストエンジニアのための応用的な資格です。

https://www.istqb.org/certifications/test-analyst

ISTQB® Advanced Level Test Analyst (CTAL-TA) 認定資格は、ソフトウェア開発ライフサイクル全体にわたって、構造化された徹底的なソフトウェアテストを実施するために必要なスキルを提供します。
標準的なテストプロセスの各ステップにおけるテストアナリストの役割と責任について詳しく説明し、重要なテストテクニックについて解説します。

この記事では、私が自身のキャリアを通じて学んだこと、CTAL-TAの勉強をしつつ自分のキャリアを振り返って気づいたことを紹介したいと思います。

レビューはもっとも効率的なテストだ

要件定義して、レビューして、設計書書いて、レビューして、実装して、レビューして、テストする。

これが典型的なウォーターフォール型の開発の流れです。

このときのレビューって何なんでしょう。

ミスや見落としがないようにダブルチェックをしている？

違うんです。

レビューってテストなんです。それも、もっとも効率的な。

ISTQB用語集のレビューの定義を見てみましょう。

レビュー（review）

個々人が作業成果物やプロセスの品質を評価する<u>静的テスト</u>の一種。

レビューは、<u>静的テスト</u>の一種と書いてありますね。

ここで静的テストとは、テストアイテム（すなわちテスト対象のソフトウェア）の実行を伴わないテストのことです。

静的テスト
テストアイテムの実行を伴わないテスト。

つまり、テストはソフトウェアを構成するコンポーネントやシステムの品質を評価するためのプロセスであり、レビューもテストに含まれているのです！

テスト
コンポーネントやシステム、および関連する作業成果物の品質を評価するための、ソフトウェア開発ライフサイクル内のプロセス。

レビュー（静的テスト）とテスト（動的テスト）の比較

では、レビュー（静的テスト）とテスト（動的テスト）は何が違うのでしょうか。比較してみましょう。

比較項目	レビュー（静的テスト）	テスト（動的テスト）
目的	欠陥を<u>早期に</u>発見する	欠陥を<u>網羅的に</u>発見する
手法	<u>目視</u>で検査（静的）	<u>実行</u>して動作を検証（動的）
対象	設計書、仕様書、コードなどの<u>開発成果物</u>	実行可能な<u>ソフトウェア</u>とその機能
時期	設計や実装の<u>初期段階</u>	設計や実装の<u>実施中または完了後</u>
アウトプット	レビュー指摘一覧など	テスト計画書、手順書、成績書など
ツールの利用	コードレビュー用ツールやドキュメント管理ツール（例: GitHub PR、Confluence）	テスト実行ツールや自動化ツール（例: Selenium、JUnit）
人的関与	チーム間の議論やレビューを通じて進める	テスターやエンジニアが動作を確認し問題を報告する

テストと比べると、レビュー（静的テスト）は設計書、仕様書、コードなどの幅広い開発成果物を早期に点検する手法と言えそうです。

レビュー（静的テスト）の優位性

では、テスト（動的テスト）と比較した際のレビュー（静的テスト）の優位性について見てみましょう。

テストは準備に手間がかかる

一般的なテストでは、テスト計画作成から成績書作成までの一連の作業を行います。

1. テスト計画作成
2. テスト手順作成
3. テストデータ作成
4. テスト実施
5. テスト成績書作成

この一連のテストのアクティビティを通じて供試体（SUT: System Under Test)が要件や設計に対して正しく作られているか確認します。この確認を英語ではVerifyと言います。

供試体の規模や開発プロセスにもよりますが、これらの一連のテストのアクティビティは設計や実装と比べて、労力が大きく時間とコストを要することも多々あります。

なぜそれだけの労力がかかるのか。

テストを実施するには、供試体を呼び出すためのテストハーネスと試験環境で供試体を動作させるためのモックが必要です。

component sut as "System Under Test"

component test_harness as "Test Harness"

component mock as "Mock"

test_harness --> sut
sut --> mock

テストハーネスとは、ソフトウェアテストにおいてテスト対象のモジュールを呼び出し、テストケースを適用してテストを実行するソフトウェアです。

モックとは、なにかを模擬するオブジェクトです。データベースや外部システムなど、供試体の動作に必要だが、テスト環境には存在しないものを模擬するために使用します。

テストではこれらのテストハーネスやモックを用意したうえで、動作に必要となるデータや手順書を整備しなければなりません。

要するにテストというのは、事前準備に相当な時間がかかるのです。

レビューの準備はカンタン

一方で、レビューどうでしょうか。

事前に用意したチェックリスト、レビュワーの経験、過去の実績など、比較的容易に準備できるものをベースに、要件定義書や設計書などのドキュメントが要件や設計に対して正しく作られているか確認します。（Verify）

レビューは、比較的容易に準備できるものだけを使って実施しますので、テストに比べると労力は小さいです。

レビューは効果的とは限らないが効率的ではある

テストは、実際に供試体を動作させるため、検証の網羅性や正確性の観点でレビューより効果的（Effective）と言えるでしょう。

一方で、かかる労力を考えると必ずしも効率的（Effecient）とは言えません。

レビューとテストを組み合わせる

レビューをテストの一種だと考えて、効率的なレビューと効果的なテストを組み合わせることで、ソフトウェア品質を高めることができます。

レビューの方式

では、レビューにはどのような方式があるのでしょうか。

以下は、ISTQB日本語用語集に基づくレビュー方式の一覧とその概要を日本語でまとめた表です。

レビュー方式名	概要
ウォークスルー	レビューの一種。作業成果物を通じて作成者がレビューのメンバーを主導し、懸念事項の可能性に対してメンバーが質問およびコメントする。
テクニカルレビュー	技術的に認められたチームによる形式的なレビューの一種。作業成果物の品質を検査し、仕様や標準からの逸脱を識別する。
インスペクション	形式的レビューの一種。役割を定義したチームおよび測定値を使用して、作業成果物の欠陥の識別、およびレビュープロセスとソフトウェア開発プロセスの改善をする。
ピアレビュー	同じ作業を実施できるスキルを持つ他の人が成果物をレビューするレビュー方法。
インフォーマルレビュー	定義されたプロセスに従わないレビューの一種。形式に則った文書の作成は伴わない。
シナリオベースドレビュー	この用語が使われているシラバスレビュー技法のひとつ。作業成果物が特定のシナリオに対処できるかを判定するために作業成果物を評価する。
チェックリストベースドレビュー	質問または確認項目のリストを使用して行うレビュー技法。
マネジメントレビュー	ソフトウェアの取得、供給、開発、運用、保守、といったプロセスを体系的に評価すること。管理者や管理者の代理者が、進捗を監視し、計画やスケジュールの状態を判定し、要件やシステム割り当てを確認し、目的遂行用に最適化されるようマネジメントアプローチの効率を評価する。
専門家による使用性レビュー	専門家がレビューする非公式な使用性レビュー。専門家は、使用性の専門家、特定分野の専門家、またはその両方である。

かなりいっぱいありますね・・・。

実は、これらのレビュー方式はWho：誰がレビューするのか？、What：何をレビューするのか？、How：どのようにレビューするのか？という3つの軸で分類できます。

1. Who：誰がレビューするのか？
   レビュワーが誰なのかによる分類です。
   1. 専門家：専門家による使用性レビュー
   2. 同僚：ピアレビュー
2. What：何をレビューするのか？
   何を元にレビューするのかによる分類です。シナリオ、チェックリストなどレビューを実行する組織（＝会社や開発チーム）が「正」とするものを元にそこからの逸脱がないかレビューをします。
   1. シナリオ：シナリオベースドレビュー
   2. チェックリスト：チェックリストベースドレビュー
   3. 仕様：テクニカルレビュー
   4. プロセス：マネジメントレビュー
3. How：どのようにレビューするのか？
   どのような方法でレビューをするかによる分類です。作成者が主導して1つずつすべて説明していくウォークスルーから、レビュー記録をしっかり残しながら実行する形式的なインスペクション、記録は残さずぱっと実行するインフォーマルレビューまでさまざまな方法があります。
   1. 作成者が主導：ウォークスルー
   2. 形式的に実施：インスペクション
   3. 非公式に実施：インフォーマルレビュー

このように、レビューはWho, What, Howの観点でさまざまな方式が発案されており、これらを組み合わせることで効果的に欠陥を検出することが可能です。