テストレイヤーごとのアーキテクチャを煮詰める
テストピラミッド とか テスティングトロフィー などの、テスト戦略モデルについて、
レイヤーごとのテストアクティビティマップを作ろうというサンプルのお話です。
ここでは、サンプルとして、モデルが "マカロン型" になった例を紹介します。
スピードを重視するシチュエーションの場合、
テストピラミッド、テスティングトロフィーのいずれも
合わないケースもあるので、その場合はテスト戦略モデルをアレンジして、
レイヤーごとのアクティビティを設定します
この記事でやること
- 不具合一覧をパレート分析し、どこで問題が起きているかを把握する
- 不具合をテストレイヤーに仮マッピングし、重点レイヤーを特定する
- レイヤーごとに テストアクティビティを定義する
レイヤー（例）
- アプリケーションE2E（UI上のユーザー価値の担保）
- システムE2E（外部連携や境界を含むシナリオ）
- ドメインルール（ビジネスルール／入力制約などの小さな単位）
- ユニットテスト（最小単位のふるまい）
アプリケーションE2Eレイヤー
テストアクティビティ
（UTP2にて記載）
アプリケーションレイヤーテストツール
- Playwright
- Autify
- MagicPod
- mabl
- Shikuri
他 たくさん
システムE2Eレイヤー
テストアクティビティ
- 外部連携
- 並列処理
- バッチ
など
ＡＰＩテストツール
- Postman
- RakAPIt
など
ドメインルールレイヤー
テストアクティビティ
ビジネスの小さい単位でのルールについての仕様です。
組合せテストの因子1個に当たるものなどです。
小さい単位の仕様とふるまいについてのテストです。
例
- メールアドレスがユニークであるか
- 入力フォーマットが正しいか
ユニットテストレイヤー
最近は、AIでコードを書くこともあり、以前より手を付けやすくなっていると思います。
（ほんとはユニットテストをもっと小さくしたかったのですが、出力が難しかったです）
レイヤーを決定する
1. 不具合一覧のパレート分析
不具合を、開発プロセスのどこで起きているかマッピングします
- 外部仕様策定フェーズ
- 内部仕様策定フェーズ
- 実装フェーズ
- 開発テスト
- QAテスト
2. どのレイヤーで起こった不具合かを仮マッピング
テスティングトロフィーなり、テストピラミッドなりに仮に当てはめて、
不具合が頻発している箇所は、さらに細分化するなどを検討します。
とあるケースでは、スクラムのプロセス的に、テスティングトロフィーの
静的テストがなかったので、不具合一覧をマッピングして、頻発しているレイヤーの
テコ入れを行うことにしました。
その結果、今回はマカロン型のテスト戦略の形になりました。
これを不具合の件数でマッピングしたところ、定量化ができたので、
明らかにマカロンの中央のクリームの部分で問題が起こっていることがわかりました。
つまり、手の付け所はここだというのが可視化されたので、
ここを重点的に手を付けよう、という方針を出すことができました。
次にやりたいこと
レイヤー分けとQA活動の方針がみえたので、次はテストアクティビティマップ（上記）を
各レイヤーごとに決めて、これを重ねて3次元にし、下層で起こっていることが
アプリケーションレイヤーで起こっているようにみえる、というのを
可視化できます。
1. ユニットテストで点を
2. ドメインルールレイヤーで線を
3. システムE2Eレイヤーで面を
4. アプリケーションE2Eレイヤーで立体を
担保するイメージです。
不具合をきちんと記録できているかがポイントです！