テスト戦略のたった3つのチェックリスト

本稿はSoftware Testing ManiaX vol.9に寄稿したものになります。ご興味ある方はJaSST、WACATE、コミックマーケットに参加して買ってみてください。

さーくるWACATE

ちなみにkyon_mmの心情的にはだいぶ押さえて書いています。本音を言えば「なんですかそのテスト計画？昼寝しながらでももっといいの書けますよ」「訓練をしないで戦地に向かうことに恐怖を覚えないなら、いますぐこのマサカリを首にかけてやる」って気持ちを必死におさえて書きました。偉いです。自分をほめたいです。 そういう雰囲気で書いているのであまり整理されていない内容ですが、皆様の何かのご参考になればと思います。突っ込み歓迎ですが、こういった文章ですのでface2faceだとコンテキスト共有しやすいと思われます！

はじめに

ソフトウェアを開発していくなかで、品質を考えるということは非常に重要なことです。品質のすべてをテストが担う訳ではないですがテストは多くの品質に対して比較的わかりやすくアプローチできる手段であると言えます。

例えばソフトウェアに対して求められる品質というのは例えば「カレンダー連携アプリケーションはだいたいこういうのが普通だ」とか「○○社が出しているソフトウェアってこういう感じ」とかもありますし、「○○ってソフトウェアはバグが発見されたら次の日には修正版がリリースされる」とか、「見やすさ重視している」とか「たくさんカスタマイズできる」とかいろいろあります。

それぞれを体系的にそれは○○品質で特性がなにで、、、のようなお話はたくさん出来ますし、有意義なわけですけど、まぁとりあえずは置いておきます。

今回はこのようにソフトウェア（もしくはそれを運用している組織）に求められる品質があり、それを鑑みてテスト戦略をたてていくとはこういう例がありそうですよ。というお話になります。

テスト戦略の目的

テスト戦略の目的というとかなり広範囲になりますし、結構立場によって違うと思います。より一般的に使えそうな目的というのはIEEE829やISO29119のような規格を読んでいただくとして、この文章では「ソフトウェア開発におけるソフトウェアテスト全体のROIやCBAを最大化するために合意するもの」としておきます。

テスト戦略のたった3つのチェックリスト。

さて、皆さんはどのようなテスト戦略（テスト計画）を立てていますか？テストフェーズ毎にスケジュールをたてて終わりとかいう残念な話は置いとくとして、IEEE829やISO29119をはじめとするなんらかのフォーマットに従って策定することもあるかもしれません。まぁそういったものがどのようなフォーマットになっているかは皆さん知っていると思いますので、すっ飛ばしまして、今回は私が何を考えてテスト戦略を策定しているか？という感じですすめます。

テスト戦略でとても重要視しているのは次の点です。

• そのテスト戦略は今達成したい品質を達成できるか
• 仮に不足してしまった品質があればそれについて成長的にリカバーできるものであるか
• プロジェクトが進むに従ってその戦略の範囲内で変更可能なことと、変更不可能なことが明示されているか

私がこれらを守るように書けばまぁなんとなくうまくいっている気はします。つまりテスト戦略のフォーマットとか挙げている項目というのはある目的に対して達成しやすそうな手段の1つでしかないので、正直そこは好きなようにしたほうがいいと思っています。「標準やフレームワークをうまく使える人間というのは、それなしでもうまく進められる人間だけなのである」というとても普遍的なことがやはり、テスト戦略のフォーマットにも当てはまる訳です。多分これを読んでいる人はそういう人ではないと思うというところもあってですね。つまりは、テスト戦略のようなある程度大きくアクティビティを決めるレベルの文書で手段を目的化するのは非常に辛さしか生まないです。（勉強しようと始める場合を除いてですね。）

では、各目的について軽く説明をします。

そのテスト戦略は今達成したい品質を達成できるか

いま対象としているソフトウェア、そしてそれを提供する組織に求められている品質があるはずです。先ほど述べたような感じですね。それらの依存関係を示した上で、テストによってどの部分を達成できそうであるかを示していることが大切です。 テストをすることは手段であって目的ではありません。例えばある品質を達成するための手段です。ここで言っている品質は必ずしも「物が出来上がってから何件のバグが出ているか？」などを測るものだけではないことは前述の通りです。 そのテストで何を達成しようとしていて、何が達成できないのかがわからないとどんでん返しをくらいます。例えば「○○っぽさっていうのって確認できるのか？できないのか？」みたいなところを誰も達成しようとしていなくって、リリース直前になってそれが発覚して急にやり直しとか。つらいですね。このソフトウェアをリリースするときに達成していなければいけないものが何であるかを明示化するのは、テストだけでは非常に洗い出すのが難しいので、出来るだけチームで洗い出しましょう。その上でテスト戦略策定時にテストではここまで出来そうであるとしていきます。

仮に不足してしまった品質があればそれについて成長的にリカバーできるものであるか

プロジェクトが進むにつれて、テスト戦略を変更することはよくあることです。その中でどうしても今回は達成できなかった品質というのもあるかもしれません。例えばある組み合わせについてはおそらくはほとんど発生しないのでテストケースを削ったり、ユーザビリティ評価をせずにリリースせざるを得ない状況になったりすることです。そういった判断をする場面はありますが、ここでそのテスト戦略をただ単に一部削除してしまってはかなり意味が薄くなってしまいます。 達成できなかった品質を、リリース後にどうやって本来あるべき姿に持っていけるかというシナリオまで描けてそのテスト戦略は意味を成します。リリース後にもテストを続けるのか、マーケットでいち早く対象の品質を計測できるようなテストを考えるのか、テスト以外の方法で達成できるように別の戦略を考えるのか。 テスト戦略とは一回つくって終わりというものではありませんし、惰性でつくって終わりというものでもありません。それがどんなに軽くても重くてもです。

プロジェクトが進むに従ってその戦略の範囲内で変更可能なことと、変更不可能なことが明示されているか

計画したものというのは基本的に様々な前提条件を伴っています。プロジェクト全体の前提条件とは別に、個々のアクティビティやソリューションにも前提条件があります。例えばとあるデータベースを使っていたけれども、急に特定パターンでのみのデータ追加が膨大になるということが判明したら、テーブル設計で解消しやすいのか、データベースの選定からやり直したほうが解消しやすいのか、データベース以外の部分を変更することで解消しやすいのかはそのときの前提条件によります。それはデータベース自体の制約かもしれませんし、チームのスキルなどによる制約かもしれませんし、運用環境の制約かもしれません。何にせよ前提条件は存在します。 このようにテスト戦略にもこの戦略で対応しやすいこと、テスト戦略自体の変更で対応しやすいこと、テスト戦略以外の変更で対応しやすいことが存在します。 具体的なスキルセットやロールが指定されている人、そしてその人が関わってくれる時間、使える環境、プロダクト、要求、テスト期間などは実際のテスト戦略で決定するものでもありますが、それらがどのような条件で変動できるのかなど、変更な可能な部分と変更不可能な部分に関して明示的にされていないとプロジェクト全体でのリカバリーが難しくなるばかりです。

テスト戦略策定

テスト戦略策定手順書みたいな、つまり手順書というのは正直どうでもいい（陳腐化しやすい）です。便利なんですけどね。なので、最近自分は技術的なものは出来るだけゴールとチェックリストを明確にしたらあとはどうやってそれに近づけるかの様々な手段を勉強なりサポートなりする方がいいと思っています。という前提においてテスト戦略の策定についていくつかの手段を書きます。

状況を把握する

対象のプロジェクト自体がどのような状況であるかを把握したほうが、テストの見せ方を工夫したりテスト自体の合意する状況作りに役に立ちます。少なくともソフトウェアテストにおいては、「それはテストだから関係ない。気にしないでとにかくテストケースを考えてテストを実施するんだ」ということはありません。 状況と曖昧な言葉になっているのは、それは範囲が広いことを示しています。実際にはかなりBig IAと似通ったことをすることになります。自分がやるときは利害関係者を洗い出して、コンテクスチュアルデザインをなんらかで描くようにしたりなどしています。 また、この他にも決まっているマイルストーンやチームメンバーのスキル、守るべきルール（法律だったり社内規則だったり）や予算もあります。他にも既存で使えるものに関しても把握しておく必要があります。 また実際に言われている要求についても整理する必要がありそうです。

言及すればまだまだキリがないのですが、重要なのは状況を把握しているということで何をどこまでやれば把握していると言えるかはプロジェクト次第になります。自分がやってきたプロジェクトでは上記のようなことは最低限やっておきたいことになりますが、それもまた別の組織では別の回答になりそうな気はしています。 これは私だけなのかもしれないのですが、自分がユーザーだったとしても実際に自分が使う場面を絵やシナリオ的に書き出したあとにソフトウェアを設計してみると最初の想定とはずいぶんと違い、それによってまたテストもかわってきたりというのがよくありました。

全体の品質を達成する方法を複数用意する

目的と手段は相互に影響し合うので、達成する品質が決定してから方法を考えるのも、方法を考えてから品質が決定するのも行ったり来たりであるので、どちらであるかはあまり気にしないでいただきたいという前提で。 ある品質をどのようなテストをすることで達成するかは実に多種多様です。ある面においてはそれはテスト技法の選択方法（ドメイン分析に時間をかけるのか、リスク分析に時間をかけるのか、AllPairに時間をかけるのか、など）によるかもしれませんし、ある面においてはどのような手段でテストをする（例えば○○環境によってこの範囲で動的テストをするのか、WorkInProgressなプルリクエスト形式のコードレビューをするのか、毎日テスト担当者を変えるのか、など）かもしれません。 自分の場合なのですが、テスト自体は開発と違う視座で考えられることが多いのですが、テスト自体が狭い視野になっていることがあり、考えたテストが唯一の方法であるかのように振る舞ってしまうときがあります。 ちょっと飛躍した比喩ですが、「○○駅に行く」という目的を達成するためには「GoogleMapを見ながら歩いていく」「自転車で行く」「自家用車で行く」「タクシーで行く」「電車で行く」「誰かに迎えにきてもらってつれてってもらう」という方法はありますよね。テストもある品質を達成するためにはいろいろな方法があると思います。それにあまりにも毎日行かなければ行けないのであれば「近くに引っ越すために長期的に取り組む」という方法も出てきます。これはソフトウェア開発で言うとよく保守性とかブランディングと言われているような時間をかけて取り組む品質と似ていますね。なんにせよ、様々な方法を備えておけばおくほど変更に強くなります。自転車で行くのが慣れている人でも、雨が降った日には電車で行きたくなりますよね。でも、電車の乗り方を知らないと困りますよね。で、それで電車がない田舎だと車がないと困る訳で、免許がないと雨の日は遠いと出かけにくくなってしまいますね。ということで、あらかじめ備えておく必要が出てきます。みたいな。

テストのROIを計算する

テストのROIは正確に出せるなら出した方がおそらく予測がよりたてやすくなるのですが、まずは相対的な値でいいので自分たちがやろうとしているテスト、今回はあきらめるテスト、今後継続していく活動などのROIを出しておくと、戦略で変更可能なものと変更不可能なものがわかりやすくなってきます。 どんな項目を使えばいいのかは対象によってかなり変化するので難しいですし、詳細はRisk Reduction ROIやCBAにお任せします。相対的でもいいのでROIやCBAを作ることになれていると、開発やテストにおける設計の小さめな意思決定にも簡単に使えるようになってなにもないよりは比較的客観的で説明しやすい理由付けをできます。 テスト戦略自体は多くの人と共有する必要が出てきやすいものですし、比較がわかりにくいままの状態での意思決定はあまりに職人芸になりがちです。職人芸を否定する気は全くありませんが、私個人のスキルではどうにもならない部分もありましてこうしているという感じです。

まとめ

ちょっと手薄な感じもしますが、あまり語られないテスト戦略についてどうあるべきかについてkyon_mm個人の経験を少しまとめてみました。 テスト戦略だけではありませんが、あまりフォーマットや手順にこだわらず、ですが今後少なくとも自分が成長するために残していくのはとても有意義だと思いますし、そのチェックリストおよびサポート的な手段を紹介しました。あくまでkyon_mm個人の経験とかスキルに依存した話でしたが。 今後もテスト戦略についていろいろ議論していきたいと思っています。

基本から学ぶソフトウェアテスト

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則