テストの自動化を進める際、そのよしあしを確認するために、いろいろなカットからのメトリクスを取ると思います。
たとえば進捗を測るためには、テストケースを自動化した割合。効率化を測るためには、自動テストによって削減できた時間や、逆に自動テストがもたらしてしまった別の作業時間。安定性を測るためには、自動テストの失敗傾向とその要因分布。
こういったメトリクスの中で、工数の削減効果をどう表現しようかと検討していた際に、メトリクスの典型的なトラップと言えそうなものにぶち当たったことがあるので、メモしておきます。
工数削減効果をどう測るか
この記事は、「こういうメトリクスで計測するのがいい」という紹介ではないので、注意してください。
ともあれわたしは、以下のようなメトリクスを考えました。
工数削減率 = 1 - X / Y
X: 手動テストに要した工数 + 自動テストに要した工数
Y: 手動テストに要した工数 + Xの第2項をテストを手動で行った場合に要するであろう工数
Yの第2項はちとややこしいですね。具体的な計算例を見てみましょう。
まず実際のテストにおいて、手動テストに45時間、自動テストに1時間かけたとします*1。この場合、X = 45 + 1 = 46 です。
次にY。Xでの自動テスト群が実はとても面倒な作業を代替してくれるもので、手でやったら5時間はかかるよ！と想定できる*2のであれば、Y = 45 + 5 = 50 となります。
工数削減率は、1 - 46 / 50 = 8% という計算になります。
このような想定の数字を持ち込まくても、たとえば「前のバージョンと比較する」という時系列的な比較も可能ではあります。ただ実際には、バージョンごとに開発内容が違う、よってテストの所要工数も異なり、比較にあまり意味がありません。
そこでこの時は、「もし自動テストがなかったら」という時間を計上して、比較することを考えました。
なお、第2項同士を比べると、工数削減率 = 1 - 1 / 5 = 80% となりますが、この条件で「テストの工数を80%削減できた！」というのはさすがにミスリード。手動テストの第1項は落とせません。
「工数削減率」をどう上げるか
では、「工数削減率」*3を上げるには、どういう方法が考えられるでしょうか。
計算式の定義上、X / Y をできるだけ小さくすればいいことになります。
分子Xを小さくする
Xを小さくするには、 「自動テストに要した工数」を小さくすればいいですね。そのために考えられることは、たとえば以下です。
- 自動テストを実行前の環境のセットアップや、実行後のクリーンアップに人手をかけているなら、そこまで含めて、自動化・効率化を進める
- 自動テストの結果の検証に、人間の関与ができるだけ入らないようにする
- 自動テストの失敗要因を分析し、時間ロスの大きいものから対策する
自動テストの仕組みが未成熟な時期には、このあたりの対策がとれますよね。
分母Yを大きくする
Yを大きくするには、「手動で行った場合の想定工数」を大きくすることになります。
急にきなくさくなりましたね。このメトリクスのトラップの1つがここにあります。
「想定工数」の恣意性が大きいと、出したい数字に合わせて操作できてしまうんですね。 結果ありきの「想定」をしない、誠実な心が求められます。あるいは恣意性を下げるために、想定工数を算出するための基準を作っておくといった手段も考えられます。
Yを大きくするための本来の方法は、
- 手動で時間がかかっているテストを優先的に自動化する
でしょう。同じ1時間の自動テストなら、10時間かかるだろうテストより、20時間かかるテストを自動化した方がYが大きくなります。
第1項を小さくする
X / Yを小さくする今一つの方法は、第1項、「手動テストに要した工数」を小さくすることです。
上の例の通り、自動テストによって、その部分だけは80%削減できているのに、テストの工数全体で見ると手動テストの方が支配的なので、全体としては8%削減という結果になっています。この第1項の寄与を小さくするにはどうすればいいでしょう。
まず、2つ考えられます。
- テスト全体のうち、自動テストの割合を増やしていく。
- テストケースの最適化を行い、対象とするテストのボリュームを減らす。
1.はそのままですね。テストケースの件数に対する自動化率といった他のメトリクスと合わせてみると、判断しやすいでしょう。
2.には、メトリクスのトラップ2つ目があります。
テストを最適化することによって削減されるテストケースは、手動テスト分とは限りません。自動化済みのテストケースが削減対象候補になることもあるでしょう。場合によっては、何も考えず流していた自動テストの方が無駄だとわかって、削減する必要があるかもしれません。今回のメトリクスでは、「正しいことをしたのに、メトリクスは悪化する」可能性があります。
このような場合に、「メトリクスを維持するために、自動テストの削減をしない」とか、あるいは「メトリクスの値を向上させるために、何も考えずに手動テストの方を削減する」という方向に向かってしまっては本末転倒です。 上の例で、手動テストを2/3の15時間に減らせば、X = 16、Y = 20 で、工数削減率は20%に押し上げられますが、これは本当によい「削減」だったのか、ということですね。
今回のメトリクスは、端的に言うと「手動テストをさぼると値が改善する」という欠陥を持っているので、別の指標、たとえば「工数削減率」ではなく「工数削減時間」の絶対値だとか、テストの網羅性などを合わせてみないと、間違った方向につながりかねません。
メトリクスのトラップ例のまとめ
この例では、単純なメトリクスを使って、2つの罠について考えてみました。
- ほしい結果を出すために、適切でない想定で値を操作する。
- ほしい結果を出すために、適切でない行動でパラメタを操作する。
これを防止するためには、
- メトリクス自体の妥当性の確認
- メトリクスの値を改善するための施策の妥当性の確認
- 別の指標を合わせての評価
といったことが必要ですね。みんな知っていることの再確認でした。
