こんにちは。CTOの松田です。

当社は開発部隊が少人数のため、仕組みよりも個人の能力で仕事をしてしまっている部分があります。しかし今年になってから人数が増えてきていることもあり、仕組み化が急務です。そこで今回は徹底的に品質管理の仕組みを作ることにしました。
本日はその一端をブログに書きたいと思います。

そもそも動作テストは何を目的に実施するのでしょうか。

開発者目線では・・・
　①実装した機能が動作するか
　②他の機能が劣化していないか

お客様目線では・・・
　③システムを利用した際に導入の目的を果たせるか

開発者の多くは「①実装した機能が動作するか」を目的としてテストを実行しているように見えます。かつて私もそうでした。

ところが、これだけでは単体テストしかやっていないことになります。他の機能の劣化やお客様のそもそもの目的に沿っているのか（仕様書の間違い）を発見することができません。回帰テストと結合テストが丸々抜けています。

以下の図でテストの範囲がどのくらい異なるのか見てみましょう。

テストの範囲は3パターン

ご覧の通りそれぞれの目線で見るとテストしなければならない範囲が大きく異なることがわかります。
このテストを怠るとお客様と大きなギャップが発生して、不具合が発見されたときに会話がかみ合わない状態になることがあります。

それであれば非常に網羅性の高いテスト仕様書を作成して全機能・全パターンのテストを実行すれば良いと思いますが、何かしらのライブラリ等、ブラックボックスな要素が必ずありますので100%網羅するテスト仕様書を作ることは現実的ではありません。
また、開発のベースにしているパッケージ製品等あればその内容もテストすることになってしまいます。それはコストと期間に無理があります。

このように制約があることを考慮しつつテストに取り組む必要があります。
そこで、テストを良い塩梅に収めつつ、不具合が出にくいようにするにはどうしたらよいでしょうか。

答えは簡単で実施するテストに重みづけをして、重点的に実施すべきテストと軽く流すテストを分類することです。

テストの優先度

ここで①～③の目的を挙げましたが、まずはこの中を優先順位付けしてみましょう。どれも非常に重要で欠けてはいけませんが、不具合修正のちょっとした修正のテストなどで必ず押さえておくポイントが見えてくると思います。
私が考える優先順位は以下の通りです。

１．③システムを利用した際に導入の目的を果たせるか（お客様の期待に応える）
２．①目的の機能を実現しているかどうか（仕様通り動作する）
３．②他の機能が劣化していないかどうか（壊していない）

これには理由があります。

まず、お客様の期待に応えることが一番です。お客様が事前に予想していたものと異なっていれば、そんなものは最初から開発を依頼しません。そのためにお客様の依頼の目的を捉え、想定しているシナリオ通りに動作するかを確認します。ここに全力を注ぎます。（設計時も同様ですよね。）

次に仕様書通りに動作することです。受託開発ならば検収条件でもあるため手を抜くわけにはいきません。この順番は賛否あると思いますが、お客様が望んでいるのは仕様書通りの動作ではありません。システムを導入して目的が達成できるかどうかだけです。そのため、この順序にしています。

最後に回帰確認です。これも重要ですが上の二つに比べると少し優先度が落ちます。そもそも「③システムを利用した際に導入の目的を果たせるか」に回帰確認が一部含まれるため優先度を落として良いとの判断です。

まとめ

ここで誤解なきよう書いておくと、優先度を落としたから手を抜くわけではありません。しっかりと影響範囲を確認して、それらが十分（100%とは言っていない）動作することを確認する必要があります。また、当然フェーズによって実施する粒度も異なり、ローンチ前のテストなのか、ちょっとした不具合を直した際のテストなのかで実施するテストの範囲と粒度が大きく異なります。
ただし、押さえるべきポイントは上記の通りで、全てのフェーズに於いてどの観点が抜けていてもテストが不完全と言えます。

テストの実施となると、どこを自動化して・・・など方法論が目立ちますが、当社ではきちんと目的を捉えてテストを実施する仕組みにしていく予定です。