リグレッション、設計してますか
品質目標を定める
不具合分析や、製品特性、人・モノ・カネ・時間などに対してのリスク、
要求される性能などに応じて、品質目標を定めます。
これは、標語的な内容だったり、数値目標（注１）になる場合もあるでしょう。
こうして、チームで目指す品質を定め、チームの認識を作っておきます。
例： ユーザーのお金に関わる不具合は出さない など
その中で、どういった内容のテストセットにしていくかを見積もります。
| テストポリシー | 品質目標 | メリット | デメリット |
|---|---|---|---|
| リスクベース | リスク回避 | 効率がよい | リスク以外は無保証 |
| 網羅性重視 | 機能保全 | 網羅的な補償 | 運用工数増大 |
| 責務重視 | 基本を担保 | 工数少な目 | 普段の使用機能以外は無保証 |
膨大なテストケース
いざリグレッションを作成するときに、心配から、際限なくテストを
追加していこうとすると、以下のような問題があります。
- マニュアルテスト： 工数が増加し続ける
- 自動テスト： メンテナンスコストが増えすぎてメンテナンスできなくなる
リグレッションは定期的に行うので、毎月相当なコストがかかります。
また、思いつきでつくってしまっては、リグレッションによって何が保証できるのかが
説明できなくなります。保証の内容をコントロールするが厳しくなるでしょう。
場合によっては、コツコツテストケースを追加した結果、
数千件に膨れ上がったテストケースを
毎週マニュアルで実行している、なんて話もあります。
リグレッションテストを整理する
こうした問題を避けるために、リグレッションのテストスイートを作っておきます。
テストスイートは、目指す品質・工数・テストの目的などを考慮して構成します。
その時のリソースや要件に応じて、流すテストセットを変えるのもよいでしょう。
また、リスクの線引きを行います。品質目標を満たす内容を考慮しつつ、
組み合わせの数、範囲、Web系ならブラウザ特性のテストパターン
などを、意図して間引きます。これは、クオリティコントロールの一環です。
間引いた部分のリスクは当然残りますが、レアケースだったり、
すぐ直せるものだったりのリスクは許容することになります。
もちろん、影響範囲が重大な製品は、簡単に間引くという問題ではないので、
基準が変わります。
無限に心配していては、生産性が下がり、機能追加が遅れ、
結局顧客満足から遠くなります。
品質基準の見極めは、高度なスキルと言えるでしょう。
また、マニュアルテストと自動テストもそれぞれ特性があるので、
考慮してリグレッションを組んでいきます。
個別の単位テストの目的・責務
テストスイートは、責務と目的のバランスを見て構成します。
一つのサンプルとしては
- 通常の業務が滞らないための基本的な機能
- 問題が起こると困る重大な操作
- コードが壊れやすい箇所を意識したテストパス
- 外部連携など、自社の努力だけでは解決できない部分
- 機能単位のテスト
などなど
これらを必要に応じて用意しておき、活用するとよいでしょう。
たくさん回すテストほど、コストパフォーマンスがよくなります。
メンテナンス
メンテナンスの工数やフローを設計することも大事です。
工数と品質リスクを考慮にいれつつ、メンテナンスが、品質基準を維持しながら
実際に運用していけるものに設計します。使える時間を考慮して、
時間がないのであればマトリクスでの管理にしたり、
設計に必要なドキュメントを簡素化して時間を作ったりなどの
工夫が必要になるでしょう。
注１
品質に関する数値目標は、本来の目的とかけ離れる場合が多いので、注意が必要です。
用語解説
インシデント
組織によって意味合いが違い、解決すべき事柄を指すこともあれば、
重要な障害を指すこともあるなど、組織によって意味合いが異なります
テストポリシー （参考： JSTQB）
目標の品質を実現するために、どういった内容でテストするかを決めたもの
テストスイート
定義は様々。ここでは、リグレッションのためのテストセット、として使っています