概要

手動テストと自動テストの比較に関する話です

この資料の目的

ターゲット

自動テスト自体に関する前提知識がほとんどない開発者が大半を占める現場に
自動テストの有用性を理解してもらうため に、一番最初に見せる大枠を説明するためのものです。
テストの種類・手法・例外的なケースなど、細部についてはあえて触れていません 。

テストの導入率

自動テストは、かなり普及してきたもののいまだに導入したことがない現場 や
触れたことのない開発者 は多いのではないでしょうか。
特にシステム開発に携わる会社の経営層や開発職を卒業してから長年経った偉い人たちは
「自動テスト？何それおいしいの？ 」ぐらいの認識であることも少なくはないと思います。

どのくらいの現場が自動テストを導入しているのだろう？
そこで資料を探してみました。 2012 年のものです。

• テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ - Publickey

少し昔とはいえ、たったの8.5 % とは。JUnit などの情報が日本国内で表にではじめたのが、
2000 年頃であることを考えると2012 - 2015 年で一気に普及が進んでいるとは考えにくい 気がします。
そのため、現状でも自動テストについて前提知識がほとんどない開発者（経営者なども） に対して、
そのメリット・デメリットを伝えなければならない機会 は様々な現場で起こりうると思います。

──=≡=͟͟͞͞(＼( ⁰⊖⁰)/) 自動テストがあるケース

メリット

• 回帰テストのコストが下がる
  • 開発速度の維持
  • リファクタリングしやすい
    • 保守性が上がる
• テストの実施が正確になる
• 開発者のモチベーション、集中力を削がない
• 開発者にとっては手動のテストよりも、プログラムとしてテストを書くことのほうがモチベーションが高まる例が多い

デメリット

• テストコードを書くコストがかかる
• テストコードを書くスキルを身につける必要がある

₍₍⁽⁽(＼( ≧ө≦)/)₎₎⁾⁾ 自動テストがないケース

メリット

• テストコードを書くコストが不要
• テストコードを書くスキルを身につける必要がない

デメリット

• 回帰テストのコストが高い
  • 開発速度の低下
  • リリースのためにテストを省略し、結果として障害を生む
  • リファクタリングしにくい
    • 保守性が下がっていく
• 手動テストのオペレーションミスが発生する可能性がある
• 退屈なテストを繰り返すことは開発者のモチベーション、集中力を削ぐ

テストに関わるあれこれ

コスト

想定は単体テストとします。

手動テストはテストケースを精査し、テスト仕様書を作成 するコストがかかるものとします。
またテストの実施は手動 であるためコストが大きくかかります 。
SI'er 出身・在席の方は、Excel 方眼紙にテストケースを書き出し、
手動で 1 件ずつ実行し、実行結果を記載していく過程を想定していただけると分かりやすいと思います。

自動テストはテストケースを精査し、テストプログラムを作成 するコストがかかるものとします。
テストケースの精査については手動テストでも行うためコストの差はないものとします。
プログラムの実装がある分、テスト仕様書の作成よりもコストがかかります 。
またテストの実施は自動 であるためコストが非常に小さいです 。

テストのコスト想定値

• テスト作成時間
  • 手動テストの 1 件あたりのテスト作成コストは 5 分とする
  • 自動テストの 1 件あたりのテスト作成コストは手動テストの 4 倍とする

• テスト実施時間
  • 手動テストの 1 件あたりのテスト実施コストは 5 分とする
  • 自動テストは非常に短い時間で実行できるため、 0 分として扱います。

10 ケースのグラフ

縦軸はコスト（分）。横軸はテスト回数。
2 回目のテストで自動テストだと 50 分の損失です。
3 回目のテストでは手動・自動のコストが変わりません。
4 回目のテストで手動テストだと 50 分の損失です。

50 分 = カップ麺 16 杯分です！

1,000 ケースのグラフ

縦軸はコスト（分）。横軸はテスト回数。
2 回目のテストで自動テストだと 5000 分の損失です。
3 回目のテストでは手動・自動のコストが変わりません。
4 回目のテストで手動テストだと 5000 分の損失です。

5000 分 = カップ麺 1,666 杯分です！
5000 分 = 83時間 = 一人の社員の標準労働時間の約半分です

仮に平均給与が月 30 万で、月に 1,000ケースの自動テストを 4 回実行する場合、
約 15 万円分も得をし、
10 回実行する場合、
約 105 万円分も得をする
ということになります。

自動化有無の判断

今回のサンプルの条件で単純にコスト面で判断なら、3 回テストを実行するかどうか が　自動テスト導入判断の分かれ目になります。

しかし、事前に触れた通り

• テストの正確さ
• モチベーション

などの効果もあるため、決定基準はより緩い ものとなるでしょう。

正確さ

手動で行うテストには、実施時にどうしてもオペレーションミス がつきまといます。
自動で行うテストは、実施時にオペレーションミスが入り込む余地がありません 。

スキル

メリットの多い自動テストですが、テストを書くためのスキルが必要 です。

• テスティングフレームワーク
• モック、スタブ
• 保守性の高いテストの記述
• 適切なテストデータの決定

などのスキルが必要となります。

モチベーション

手動テストそのものが退屈で面倒なものであり、
さらに回帰テストなどが発生するとより退屈になります。

モチベーションが落ちれば集中が低下し、

• 作業の精度が落ちる
• 他のタスクに移ってからも調子がでない

などの悪影響があります。

具体例

手動テストのケース

ケース1: ぽちっとな、あ？（怒）

部下「できたどー！みちくり、上司。みちくり」
上司「いいだろう。（｀・ω・´）((ｷﾘｯ 」
上司「よし、ぽちっとな。」
プログラムNullPointerException!!
上司「あ？（怒）」
上司「お前動作確認したのか！？」
部下「してないっすよ 。簡単な修正だしすぐ動くと思ったんで」
上司「もぅ、部下ったらダメだぞっ。めっ（ﾃﾞﾚ）」
部下「わりぃわりぃ、まぁ俺とお前の仲だろ？気にするなって。」

ケース2:デグレード

上司「ででーん、松本・仕様変更！！ 」
部下「あかーん。ほんとええ加減にせいよ、山崎～。」
上司「実装したら、 1 日ぶり 11 回目の再テストや。ぜんぶやで」
部下「うす（もう飽きてきたし適当にちょっとだけやろう ）」：
部下「山崎～、おわったでー。」
上司「よし、ステージング環境にデプロイするで。」
上司「手のぬくもりを大事に するんやで。赤子を扱うようにデプロイするんや。 」
部下 ｶﾀｶﾀｶﾞｺｯ！ｶﾀｶﾀｶﾞｺｯ！
上司「Enterキーに恨みでもあるんか、お前・・・」
部下「（無視）」
：
部下「よし、デプロイおわった。では、テスターのみなさーん。」
部下「第 11 回チキチキ回帰テスト、いってみよう！！」
テスター「よし、なおっとるな。」
テスター「・・・ん？前動いとったところが動かんようになっとるやないか。」
テスター「ででーん、松本・デグレ・アウト－！！ 」

ケース3: 意図的な回帰テスト省略

ここに実装とテストがあるじゃろ？
( ＾ω＾)
⊃実装・テスト⊂

納期を加味して・・・

( ＾ω＾)
≡⊃⊂≡

あら不思議、実装だけになって無事納品！
( ＾ω＾)
⊃実装⊂

運用開始すると・・

( ＾ω＾)
≡⊃⊂≡

バグ満載！
( ＴωＴ)
⊃バグバグバグ⊂

自動テストのケース

ケース1: レベルの低いバグの減少

標準的なテストケースについては、テストクラスで作成するため
ちょっとしたバグの発生頻度が下がります。

ケース2:デグレードしにくい

自動テスト化された部分に関しては、修正後即実行し変更が影響していないことを確認できます。
そのため、デグレードが発生しにくくなります。

ケース3: 意図的な回帰テスト省略が必要ない

テストの実施コストが低いため、確実に回帰テストが実施されデグレード確認ができます。
これにより、プログラムの変更の敷居が下がります。
結果としてリファクタリングが行いやすく なり、システムの品質・保守性が向上 します。

自動テストでも防げないもの

仕様の誤認

仕様自体を誤認すると、テストケースの設定自体が誤ったものになるためテストが成功していてもバグが混入します。

テストケースの観点に対するレビュー などで対応するのが一般的です。

スキル不足

• 境界値等、適切なテストデータを作るスキルが低い
• テストコード自体にバグを仕込む

など、習熟度が低い場合はバグが混入しやすいです。レビュー、ペアプロ、組織的な教育制度 などによりスキルレベルの向上 を図ります。

外部資料

• 自動化されたテスト vs 手動テスト - Ryuzee YOSHIBA - slideshare
• ユニットテストにまつわる10の勘違い - 渡辺修司 - Developers.IO
• テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ - Publickey