テスト戦略パターンの作り方 #swtestadvent

はじめに

これはソフトウェアテストあどべんとかれんだー 2014 の一日目の記事です。

明日は id:nobkz さんの「Lispとテスト」になります。

概要

テスト計画やテスト戦略をつくるために、ある偏りを見ることによって分類し、テスト計画やテスト戦略策定を補助する方法について紹介します。これに新規性や素晴らしさはたいしてありませんが、私は多少なりとも有効に使えている気がします。 これは「テスト戦略自身」ではなくて「テスト戦略を見つける方法の1つ」と思ってください。

重要なこと

これはkyon_mmが言っていることであって、業界の標準的な何かとかではないです。

テスト計画、戦略とはなにか

テスト計画、戦略とは何かという長大な話をしたいわけではないので、引用します。

計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。

ソフトウェアテスト標準用語集（日本語版）Version 2.3.J01　テスト計画

組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。

ソフトウェアテスト標準用語集（日本語版）Version 2.3.J01　テスト戦略

ようは、テストを安全に進めていくための拠り所となるようななにか。といった感じです。

方法論の全体像

テスト戦略をパターン化するということはなんらかの形で定型化してみようというわけです。基本はリスクとの関連を調べて、なにをすべきか決定していくスタイルです。簡単にするために、リスクなどこれから出てくる分類の1つずつ自分で定義したものを項目と呼びます。 例えば、リスクにおけるリスク項目というのは「国際化対応周りで文字コードに関して不正確にデータを保存してしまうリスク」などのようなイメージです。 リスクの各項目自体には最低限次の項目が入っていると仮定します。

• 誰のリスクか
• どんなリスクか
• 発生する頻度
• 影響度

では、リスクとなにの関連をみていくのかの各カテゴリの例をあげてみます。（これらをリスクの定義に含めることもあると思います。）

• リスクの項目 : システムアーキテクチャの項目
• リスクの項目 : 保守期間
• リスクの項目 : システム中でテストダブルを使うべき項目
• リスクの項目 : 回避していることを立証できる頻度
• リスクの項目 : 回避する度合い

簡単にためしてみるにはExcelでマトリクスにするのがいいのかもしれません。で、まぁ見づらさとかを考えないなら、縦にリスクで横がリスク以外みたいな感じにしてみるという手段もありますが、最初発見したいときにはいいかもしれませんが、最後には分割するなりなんなりしたほうがいいかなぁ。できればアプリ化するなり。 僕はいまは面倒なので、Groovyのスクリプトで書いています。

リスクとシステムアーキテクチャの項目でマトリクスする例（もっと大きな表なんですけど、おさまらないのですごい小さくしてあります。

------------	HTTPハンドル	アプリレイヤ	ドメインレイヤ	インフラレイヤ
中東のユーザーが日本にきてアプリケーションを使うと文字化けして、使えないリスク	0	1	1	1
～～～なリスク	1	0	0	0
～～～なリスク	0	1	1	0
...	...	...	...	...
サマリ	5	2	5	20

このようなマトリクスをつくり、交点となるセルには「このリスクに関わるかどうか」というフラグを持たせておきます。 そして、サマリで各項目がシステム全体でどれくらい密接にかかわっているのかはわかります。これを保守期間の項目で分類したり、していきます。

こうすると何がわかるかというと、 「こういったリスクを回避するアプリケーションには、システムのこの部分がネックになっていて、保守期間がどれくらいであり、、、」などがわかります。そうして、このレイヤで「テストダブルを使うべきかどうか」と「どのくらいの頻度で立証できるか」が入ってくることによって「システムの作り方」をテスタブルにするということが可能になります。（もちろん、テストダブルを使わないほうがいいテストもあるし、頻繁に確認しなくてもいいこともあるという意味もあります）

これを繰り返すと「前にやった、システムアーキテクチャの項目と保守期間は今回のプロジェクトのプロトタイプ的に使えそうだ」とかなり、「このチームでやるなら、リスクに大してこうやって対処するパターン」みたいなのが出来てきます。

すごく大切なこと

重要なのは、ここであまり重み付けをしないことです。重み付けになやむくらいなら、リスクや関連の分類の各項目を細分化するほうがマシです。重み付けは気軽に変更できるものだけに制限するほうが、つくったものへの変化を促しやすくなります。言い換えると、マトリクスで重み付けをしたときに、それを一貫した基準で重み付けできるくらいに賢い人間だけがそれをやれるし、私はそうではないということです。 変化を促しにくくする仕組みはできるだけなくしながら、俯瞰しやすく、全体を早くつくるための仕組みを構築すべきです。（この例が素晴らしいと言っているのではなくて、僕はそう思って、これで少しはよくなったというだけ。

また、これは本来であれば「コンテキスト」や「フォース」といったパターン・ランゲージのような項目が必要になると思います。なので、大人数で適用したい！とかいう場合には「社内に展開する前にはコンテキストを書くこと」のような制限をつけるといいかもしれません。小さいチームではおそらくそれほど重要ではありません。必要だと思うときに書きましょう。