≣概要

湯本剛さんが「ソフトウェアテストにまつわるよくある疑問　テスト工数はどうやったら減らせる？」というブログを書きました。

とてもすばらしい記事なので、未読の方は、このブログより先に読まれることをお勧めします。
それで、蛇足とは分かっていたのだけれど、「テスト工数を減らす」件について

とツイートしました。ここでは、もう少し書きたくなったので蛇足を重ね、noteしています。

≣テスト工数を減らす？

湯本さんも書いていることですが、「テスト工数を減らす」ことは常に正しいことというわけではありません。

これが、「消費電力を減らす」とか「単位時間当たりの処理量を増やす」といったものでしたら、常に「消費電力は少ない方が良い」（望小特性）、「単位時間の処理量は多い方が良い」（望大特性）というように、「理想的には小さければ小さいほど（大きければ大きいほど）良い」という特性を持つものもあります。

ところが「テスト工数を減らす」ことについては、「それでは、テストをしないこと（テスト工数ゼロ）が理想なのか？」というと、言いよどみます。

「たとえ、テスト工数がゼロになったからといっても、それでバグだらけのソフトウェアをリリースしてしまったら『後が大変』だから」です。
「テスト工数を減らせ」というリクエストは「品質問題を起こさないレベルまで品質を上げ、かつ、テストのコストを下げろ」ということですから。「テストやめま～す。運用を開始したら、バグは当然でま～す」は許されません。

経験的には（私が知る限り）、「テスト工数をこれ以上減らしたら大変なことになる」と思う現場の方が多いです。
といっても、このエントリーは「テスト工数はどうやったら減らせる？」がテーマですので、以下の項ではそのテーマに絞って書きます。

「テスト工数が適切かどうか？」については「品質コスト」についての知識とビジネスの分析が必要となります。ここでは深入りしませんが、「テスト対象商品・サービスの売上高の2%程度」をテストに掛けるコストの目安とする方法があります。
例えば、3千円のゲームを10万本売ったら3億円の売上です。その2%の600万円がテストにかけられるお金の目安となります（10人月程度？）。1万本が販売目標なら60万円。
※　この計算は分かりやすいですが、あくまでも目安です。商品のジャンルや販売戦略によって適切なテスト工数は変わります。
　　（テスト原則6「テストは状況次第」を思い出してください）

≣ECRS（イクルス）

「品質を変えずにテスト工数を減らす」方法には、業務効率化のフレームワークであるECRSが使えます。

・Eliminate：捨てる
・Combine：まとめる
・Rearrange：並べ替える
・Simplify：簡素化する

の頭文字をとってECRSです。テストで言い直せば、

E: しなくて良いテストをやめる
C: まとめてテストできることは一緒にする。本質的に違うテストは分ける
R: テストする順番を工夫する
S: 自動化などで効率化する

でしょうか。E→C→R→Sの順番で効果が大きいので、まずは捨てることを考え、捨てられなければまとめ、まとめることもできなければ、実行順序を工夫し、それも無理なら自動化しようという感じで進めます。
以下、それぞれについて具体的にしていきます。

≡E: しなくて良いテストをやめる

「しなくて良いテスト」の代表例は「前工程でしている（はずの）テスト」です。
例えば、システムテストフェーズで単機能のテストをしている組織があります。ありますというより、ほとんどそうでは？ と思うくらいです。
話を聞いてみますと、

「単機能テストは開発者により終わっています。フェーズ移行審査も合格しています。私たちはシステムテストの役割なので、システム全体を組み合わせたテストやユーザーシナリオを流すテストをしたいのですが、『単純な機能が動かない』んです。このまま市場に出したら大変なことになることはわかりきっています。だから仕方ないんです。」

といいます。
しかし、これを認めてしまうと次からも（単機能テストが不十分でも納期が来たらシステムテストに渡しても良いんだと）期待します。「一つ一つの機能が仕様通りに動くことは開発した本人が責任を持ってテストする。その代わり、そこで見つかった不具合は、不具合票に起票せずにガンガン直してよい」とすることをお勧めします。

そしてシステムテストで単機能バグが出たら「大ごと」にします。「大ごと」というのは、市場で重要不具合が出たときのように、開発者が原因分析や失敗コストの計算を行い、再発防止策を立ててその再発防止策が次の開発時に徹底していることを次の単機能テストのフェーズ移行審査項目とします。

実はもう一つ、無駄パターンがあります。それは、「無駄に同じことを繰り返す」です。例えば、ある処理のパフォーマンスを測る時に「何回かやって平均値を求めてください」という指示をすると、人によっては5回も10回も行います。「10.5秒、10.2秒、9.8秒、10.3秒、9.9秒。よって平均10.14秒」といった具合です。仕様書を見たら「20秒以下であること」なんて書いてあったりします。無駄なことをしていると薄々気付いていても止まりません。
また、「再現テスト100回やっといて」と新人さんに言ってしまう人がいます。100の根拠なんてありません、なんとなくです。「科学的に無駄なくやろうよ」と思います。

≡C: まとめてテストできることは一緒にする。本質的に違うテストは分ける

例えば、構成確認テストと組合せテストを一緒にします。また、前項で書いた通り本質的に違う単機能テストとシナリオテストを分けて重ならないようにします。（重要なものだけ両方でテストする手はありますが、何が重要かは、思い付きやそのときの忙しさから決めるのではなく、テスト分析・テスト設計で明らかにすべきです）
テスト実行時に何に時間がかかっているのかを見極めて、時間がかかる要因をできるだけ共有して（時間がかかる要因をキーとしてテストをまとめることで）テスト工数を減らします。

≡R: テストする順番を工夫する

テストケースには「テストケースの目的、入力する値、テスト実行手順、期待結果、実行事前条件」を記載します。そして、同じ目的（例えばパフォーマンス測定）を持つテストケースが集められテストスイート（パフォーマンステスト）が作られます。そのときに、どういう順番でテストを実行したら集められたテストがやりやすいかを考えます。実行事前条件を大きく変更してしまうようなテストはあとにまわそうとか。順番を考えている中で、一つのテストケースにまとめられるものが見つかるかもしれません。その場合はまとめてしまった方が効率が上がります。

≡S: 自動化などで効率化する

自動化が最後の策であることに違和感を持つ人がいらっしゃるかもしれません。「テスト工数の削減」といったらまずは「自動化」だろう？ と。
自動化は上手くはまれば、すごい効果が出ます。でも、自動化のみで気付くバグは案外少ないものです。

数値計算の自動化なら期待結果を作ることは比較的容易です。前のバージョンやベンチマークとする別のシステムがあれば、それの出力結果と比較する方法が取れるからです。銀行などのシステム更新時は現行システムと新システムとの比較テストを行います。
最悪、2人それぞれで開発したものを比較しても良いでしょう。

しかし、数値計算以外は、どれもなかなか手ごわいです。「処理がもたつくバグ」をどうやって自動化で見つけましょう？　「画面がチカチカしたこと」は？　テスターが手動テストしたら簡単に気が付くことであっても、それを自動テストで見つけるためには一つずつ仕組みを作る必要があります。そして、自動化はメンテナンスが必要です。

≣まとめ

テスト技法の適用、テストの自動化、モデルチェッキング、フォーマルメソッド等々、テスト工数の削減を目的のひとつとし、さまざまな試みが行われてきました。
どれもはまれば、効果大です。でも、ECRSのような「やめるべきテストは思い切って止める」といった原始的な方法もいまだに効果があるものです。