自動テストを書けば手動のテストはいらなくなる？

Question

ネットを見てると「まだチマチマ手動でテストやってるの？」

みたいな意見をよく目にしますが、流石にユニットテストを導入したからと言って手動での単体テスト/結合テストがなくなるというのは極論に思えてしまいます。

しかし、手動でのテスト仕様書作成や単体テスト実施をユニットテストと同じ粒度でやるというのはいささか本末転倒な気もします(ユニットテストの意義はテスト実施の効率化だけではないとはいえ)

今勤めている会社はユニットテストの導入が遅れているのでイマイチ勝手がわからないのですが、この辺りどんな感じのバランス感でやるべきものなのでしょうか？

漠然とした質問ですいません……

Answer 1

こんにちは。

プログラムの品質保証と言う観点で必要なテスト・セットを決めることはできると思います。そのテスト・セットを全て自動化できるならそれに越したことはないです。
しかし、実際の場面では、プログラムの品質保証をするためのテストはテスト工数と取り合いが発生します。できるだけ少ない工数でできるだけ高い品質を保証したいです。

この要件を満たすためには、闇雲に全てのテストを自動化するのはナンセンスですね。結合テストや機能テスト等、外側に近づくほどテストの自動化の難易度が上がります。自動化工数が膨大になる部分は手でテストした方がよいでしょう。

しかし、逆に何度も何度も繰り返しテストが必要になる部分は、自動化すると効果的ですね。いちいち手でテストしていると工数がどんどん増えますから。
繰り返し行うテストの代表は、リグレッションテストでしょう。
そして、こちらも結合したモジュールが多い程、頻繁にテストが必要になると思います。

頭痛いですね。自動化したい部分程、自動化工数が増えがちです。
しかし、うまくモジュール分割し、テストを自動化し易い部分を的確に抽出できれば、自動化テスト開発工数を減らして、より外側のテストを自動化できると思います。その辺をうまく見極めることが重要ではないでしょうか？

---

さて、逆に細かいモジュールのテストを繰り返し行うケースってどの程度あるでしょうか？
基本的にリグレッションテストが必要になるのは、何かを修正した結果、変わってはいけない動作が変わっていないことの検証です。細かいモジュールでそれが発生する確率は低いと思います。細かいモジュールの場合、他のモジュールの影響を受けにくいものが多いですから。（なるべく疎結合で設計しますし。）
なので、正直単体テストの自動化による品質改善に対するコストパフォーマンスは高くなりにくいと感じます。

ただし、例外があると思います。新人さんがソフト開発している部分です。
経験があまり豊富でないので、どんなテストを行うべきか的確な判断ができない場合が少なくないと思います。そのような人はTDDで開発すると、思い込みを排除しやすいため、アウトプットの信頼性が上がることを期待できます。
できの悪いアウトプットが減ることで、結合テストが順調に進み他の経験豊富な方の工数を減らせ、全体の工数削減を期待できる可能性はありそうに感じます。
（こちらは、実際にやったことはないので、想像です。すいません。)

Answer 2

テストは品質保証と開発中の心理的安全性の確保のために行われます。
それは手動であっても自動であっても同じです。

テストを自動化すると、その「自動化したテストでカバーできる範囲」の手動テストは不要になります。
しかし、カバーしきれない部分は別途何らかのテストをするか、カバーしないかを取捨選択することになります。

そういったものだと思います。
ひとまず、自動化している部分を手動でも確認するといった、二度手間になるようなことは避けるべきですね。

Answer 3

自動化されたユニットテストをしたことがないならば、手動でのテストは一切減らさず導入してみてください。単体レベルでのテストで、必ず何カ所かのバグフィックスをすることになると予想されるモジュールでユニットテストを導入するのがおすすめです。

やってみればわかりますが、既存のユニットテストはコーディングが完成して、結果をテストするものです
が、自動化されたユニットテストはコーディングの途中で、テストを行う感覚になります。

バグフィックスは、早い段階で行う方が効率的なので、モジュールの完成が効率化できます。

これに網羅性を持たせれは、単体テストとして認めてもらえるとおもわれますが、バグを作りやすいコードの場合は使い捨てであったとしても効果があります。

既存の自動化したユニットテストをしたから、既存の手動のユニットテストをいきなりなくしてしまえば、
自動化したユニットテストに慣れていないため、問題が起こるでしょう。

コーディングレベルから少しずつ、チームにあった速度で適用範囲を広げていくとよいと思います。

---

しかし、手動でのテスト仕様書作成や単体テスト実施をユニットテストと同じ粒度でやるというのはいささか本末転倒な気もします(ユニットテストの意義はテスト実施の効率化だけではないとはいえ)

単体レベルであれば、手動のテストより粒度は細かく、実行できます。というのも、手動ではコマンドラインや画面レベルからのテストですが、自動化されたユニットテストでは、関数レベルでのテストが行えます。そのため、よりこまやかなテストが簡単に行えます。

このことはプログラムの設計にも大きく影響し、自然と粒度の細かい読みやすいコードに近づきます。このことの方が実は効果が高いと私は考えています。（効果の定量化は難しいですが・・・）

---

以下は余談になります。テストを自動化するとテスト仕様書は、テストコードになり、テスト結果は実行ログになります。

現状、単体レベルでもテスト仕様書を書かれているようですが、テストの結果を承認する方はユニットテストのコードを読んでくれそうですか？私はこの点で苦労しました。上司がCOBOLしか読めなかったのです。

導入時には、お気を付けください。

Answer 4

ひとつずつ回答します。

1. 単体テスト/結合テストがなくなるか？

多くのテストエンジニアが考えるように、答えはNoだと思います。
理由は、主に以下の2点です。

• 人間にしか気が付けない誤りがあるから
• Frontに近いテストを書くのはメンテナンス工数が大きすぎるから

手動テストケースは、探索的テストの導入も検討されると良いかも知れません。

1. 自動テストと手動テストのバランス感

テスト自動化のピラミッドを参考にされると良いと思います。下記リンク参照。
https://qiita.com/mwakizaka/items/91b8f18c4750a92838c2