テストピラミッドについて

Last updated at 2024-10-16Posted at 2024-10-10

はじめに

テストピラミッドについて、個人的な解釈のメモを書き残しておく。
どうも、私の周りの感覚と違うので。。。

テスト自動化での文面でよく出てくる有名なテストピラミッド。

というものになっています。

E2E、UI のテストは以下のようにする

コレに違和感を感じるのです。
そして、これがあるべき姿だとして『システムテスト』は非効率、ROI が悪いという主張だけが跋扈して独り歩きしている感じがしています。

テストピラミッドは『テスト自動化』の視点(文脈) だと認識しています。

『テスト戦略モデル図』と言われてますが、『テスト自動化戦略モデル図』と勘違いしていない？
と思うことがよくあります。(自動化どこ行った？)

私が認識しているのは、おおよそは、以下のほうです。
https://gihyo.jp/dev/serial/01/savanna-letter/0005

『単純』な機能のテストはE2E、UI の段階では少なくすべき、という認識をしています。

例えば、E2E のテストの段階で、入力チェックなどの単純なテストをするのは非常に効率が悪いということで、ユニットテストで実施せよ
システムテストになって、単純な入力ができない、設定が保存できないとかあると、再現性の特定、調査、修正で莫大なコストがかかるということです。

E2E のテストは、様々な条件が重なってきて、かなりフレーキーな結果となり、その結果を吟味しながら保証できるかを判断していきます。
こんな状況で、単純な機能の欠陥のために、時間を大幅に費やすのはもったいないということです。

入力データ、環境を変更しながら、数日、欠陥の患部特定していた結果、「プログラムの条件式間違えてた、テヘペロ」とかで終わることもあります。

私の概念では、テストピラミッドの土台(底辺)は単機能の品質を保証するための重要なテスト。
これが崩れると、全ての保証が崩れるという認識です。

単機能ゆえに、自動化しやすく絨毯爆撃で全テストしやすいため、自然に量も増えるという認識をしています。

テストピラミッドの頂点で、システム構成された状態での保証する重要なことは4つぐらいに絞られるかなと考えています。

ピラミッドの頂点のテストで、絨毯爆撃は非効率で、テスト要求分析などを実施をしたうえでユーザーストーリーやリスクベースなどをあげて、保証しなければいけない状態・状況で欠陥を発見する(逆に、保証する)テスト活動することだと認識をしています。

昨今のアプリケーション、サービスは、ユニットテストだけで品質を保証できると全く思っていません。

1つ1つのテストは、土台の方がコストは安いです。
当然です。
だって、単機能のテストをするわけですから。

さらに、欠陥に気づいたとき調査・修正も開発担当者が見つけて修正するので情報ロスも少ないのでコストは低いです。

そして、この土台となるユニットテストは単一(単体)での機能を保証するものなので、これが動作しないと、他も全く動作しないということになります。
動作しないだけならいいけど、システムとして動作させると場合によっては、破壊的な挙動する可能性もあります。

よって、基礎工事となる土台は、非常に重要なのでユニットテストはおろそかにしてはいけません。

だからと言って、ピラミッドの土台、頂点で工数が変わらないとも考えています。

土台のテストは量が多くなる傾向ですが、「1つテスト時間 * テスト数」と考えると、保証活動時間としてはそこまで変わるか？と思っています。

よって、システムテストが ROI が悪いとも思っていません。
ユニットテストだけで、システムテストで保証する内容を包含すると、それこそ全組み合わせの実施になりかねないと思っています。

テストピラミッドは自動化の文脈で使わないと、「システムテスト」は ROI が悪いから削減しようという使い方を間違い始めることになる

っという思いが強くなりました。