L3で取るテストとL4で取るテストを混同すると、QAの評価を間違える
この記事は、マカロンレイヤーのうち L3/L4 の違いを説明するための概念整理です。Oracle Check や AMB 抽出の詳細な手法・評価については扱いません。
この記事では、私が整理している「マカロンレイヤー」という考え方を使って、
QAの評価について考えます。
この記事で扱うこと
マカロンレイヤーとは、テストやQA活動を「テスト」とひとまとめにせず、確認対象のレイヤーごとに分けて考えるための整理です。ざっくり言うと、次のように分けます。
- L2：仕様判断、期待結果、不明点、判断分岐を扱う層
- L3：API、DB、ジョブ、非同期処理、権限、外部連携など、内部処理を扱う層
- L4：画面操作、ユーザー操作、業務フロー、E2Eを扱う層
ここでいうL2/L3/L4は、一般標準の用語ではなく、私がQA活動を整理するために使っている「マカロンレイヤー」上の呼び方です。
そして、ここで大事なのは、L3とL4では「見ているもの」が違うということです。
なお、この記事では議論を簡単にするため、実装・UI・コード・ログなどから得られる観測候補を扱うL1は省略します。
L4はユーザーから見える品質を見る
L4の画面E2Eでは、ユーザーが画面を操作して、業務フローとして問題なく進むかを確認します。これはとても重要です。ユーザー影響、業務上の違和感、受け入れ条件、操作の自然さなどは、L4で見るべき領域です。
一方で、L3は画面の裏側にある処理を扱います。たとえば、APIが正しく状態を更新しているか、DBの整合性が崩れていないか、ジョブが二重実行されないか、非同期処理の失敗時に状態が宙ぶらりんにならないか、権限チェックがAPI側でも効いているか、といった領域です。
この2つを混同すると、評価を間違えます。
たとえば、本番でDB整合性の問題や非同期処理の不具合が出たとします。それを「QAが画面テストで見逃した」と評価すると、本質を見誤ります。
本来それは、L3で確認すべき内部処理リスクが、L4の画面E2Eに後払いされていた状態かもしれません。
L3は画面の裏側の品質を見る
L3で取るべきテストをL4で代替しようとすると、L4担当QAの努力量だけが増えます。しかし、画面から見えない処理、ログを見ないと分からない処理、DBの中間状態、ジョブの再実行条件、API側の権限境界は、画面操作だけでは保証できません。
その結果、改善策もずれます。
本当はAPIテスト、DB確認、ログ確認、ジョブ確認、自動テスト、開発者テスト、CI組み込みが必要なのに、「QAのテストケースを増やす」「もっと画面で確認する」「非エンジニアQAでは足りない」という話になってしまう。
これは、QA担当者の能力評価ではなく、テストレイヤー設計の問題です。
L4 QAにもL3リスクを見つける価値はある
もちろん、L4 QAがL3に無関係という意味ではありません。L4 QAは、L3をすべて実装・確認できなくても、L3リスクを見つけることはできます。
たとえば、
「この画面操作では成功に見えるが、裏の状態遷移が不安」
「この処理は非同期なので、画面だけでは完了を保証できない」
「この権限はUIだけでなくAPI側でも守られている必要がある」
「このジョブはL4の操作では観測できない」
こうした指摘は、L4 QAからでも十分に価値があります。
L3確認には技術的に確認可能な役割との協業が必要
ただし、L3の確認を完了させるには、技術的に確認可能な役割との協業が必要です。
たとえば、開発者、SET/SDET、SRE、テスト自動化担当などです。
QA単独で完結できるものではありません。
「エンジニアでなければQAできない」ではない
つまり、問題は「エンジニアでなければQAできない」ではありません。
正しくは、
L3をQA単独で閉じるにはエンジニアリング支援が必要。
しかし、L2やL4には非エンジニアQAでも強く価値を出せる領域がある。
L3で取るべきテストとL4で取るべきテストを混同すると、QAの評価を間違えます。
まとめ：未確認のレイヤーを見逃し扱いにしない
L3の未確認を、L4 QAの見逃しとして扱ってしまうと、テストアーキテクチャとして
不十分になります。それは個人の能力不足ではなく、確認すべきレイヤーと責任者を
分けられていない、製品品質につながるプロセス品質の問題になります。
この整理は、テストで見るべき側面を明示する Test Aspect の考え方とも近いと思っています。
テストアスペクトのスライド（英語）
略語
SET（Software Engineer in Test）/ SDET（Software Development Engineer in Test）