導入
ソフトウェア開発では、「機能テスト」と「回帰テスト」という用語がよく使われる。
しかし、この二つの境界は必ずしも明確ではない。
例えば「ログインできる」という同じテストケースでも、
- 新規実装時は機能テスト
- ログイン画面修正後は回帰テスト
と呼ばれることがある。
つまり、テストケースそのものに種類があるのではなく、変更との関係性によって役割が変化している。
そこで本記事では、変更箇所からのテスト距離という概念を導入し、機能テストと回帰テストを連続的な尺度として整理してみる。
テスト距離
用語整理
テスト距離とは、
変更箇所から、そのテスト対象まで変更の影響が伝播する距離
である。
例えば
入力チェック
↓
ログインボタン
↓
ログインAPI
↓
セッション
↓
プロフィール
例えば
「IDまたはパスワード未入力ならログインボタンをdisableにする」
という変更を行ったとする。
このとき確認したいテストとして、
- disableになる
- enableになる
- ログインできる
- プロフィール画面が表示できる
- ログアウトできる
などが考えられる。
これらはどんどん修正箇所から離れているが
- どこまでが機能テストなのか
- どこからが回帰テストなのか
- どこまで確認すれば十分なのか
を判断する明確な基準はない。
定量基準の導入
テスト距離とは、
変更箇所からテスト対象まで変更の影響が伝播するしやすさ
を表す尺度である。
テスト距離を次のように定義する。
Distance(Test)
=
Dependency
+
SharedState
+
UserFlow
各項目は次の意味を持つ。
- Dependency : 変更箇所との依存関係の強さ
- SharedState : 共有状態による影響範囲
- UserFlow : ユーザー導線・業務上の関連度
値が小さいほど変更に近く、値が大きいほど変更から離れている。
例えば、
「IDまたはパスワード未入力ならログインボタンをdisableにする」
という変更を行ったとする。
| テスト項目 | Dependency | SharedState | UserFlow | Distance |
|---|---|---|---|---|
| disableになる | 0 | 0 | 0 | 0 |
| ログインできる | 1 | 1 | 0 | 2 |
| プロフィール表示 | 2 | 2 | 1 | 5 |
| ログアウトできる | 3 | 2 | 2 | 7 |
Distance が小さいものは変更の影響を直接受けるため、確認テストになる。
一方、Distance が大きくなるほど副作用の確認、すなわち回帰テストの意味合いが強くなる。
このように考えると、機能テストと回帰テストは独立した種類ではなく、テスト距離という連続量の中で役割が変化するものとして整理できる。
この尺度を用いて、機能テスト、回帰テストを現場ごとに分割する運用ができる。
おわりに
本記事では、変更箇所からの影響の伝わりやすさをテスト距離として定義した。
従来のように「機能テスト」「回帰テスト」を独立した種類として考えるのではなく、
- テスト距離が小さいものは機能確認
- テスト距離が大きいものは回帰確認
という連続的な概念として整理できる。
また、テスト距離を
Distance(Test)
=
Dependency
+
SharedState
+
UserFlow
のような尺度で定義することで、現場ごとに「どこまでを回帰テストとして実施するか」という基準を定量的に議論できるようになる。
もちろん、この式は一つのモデルであり、プロジェクトによって重視すべき要素は異なるだろう。
しかし、「変更からどれだけ離れているか」という視点を持つことで、テスト範囲の設計や回帰テストの優先順位付けを、経験だけでなく共通の尺度で考えられるようになるのではないだろうか。