自動テスト環境で作業をするようになって１年近く経ちますが、現在の案件でも手動テストはやっております。
一般的には自動テストをがっちりと装備するのがいいと言われがちですが、やはり自動テストのデメリット、手動テストのメリットなどもあるよなと思い、今回は手動テストと自動テストのメリデメなんかを。
手動テスト
メリット
- 実行だけに関していえばどんなテストでも手順書どおりに行えば本番同様の再現が可能
- テスト項目書自体が仕様書になる
- 実行者のスキルに依存しない(開発の知識がなくても実行が可能)
- 実装者と別の人間が行うことで盲点に気づける(モンキー的なテストができる)
デメリット
- 作業が単調になりがちで、実施者のモチベーションをキープすることが難しい
- 項目書の作成(特に作成観点)はある程度のスキルが必要なのと、統一するのが難しい
- アジャイル的な修正が頻繁な場合には向かない(再びテストをする必要がでてくるため、コストが膨れ上がる)
- テスト実行前の環境用意が大変(できればベンダーごとにわけれないときつい・・・手動テストをする際、環境がテストデータがtruncateなど初期化可能かを確認しておくこと。これができないとほぼ無理)
自動テスト
メリット
- 自動でテストが行えるため、システムの規模が大きいほど効果が大きい
- カバレッジなどで網羅率をみることができるため、機械的な漏れに気づける
- n×m系の組み合わせが多い場合の確認などプログラムで簡単に確認できるため、効果を特に発揮する
- アジャイル的な開発現場の場合、再テストの時間がかからず、品質の担保が行えることと再テストがないため、テスターのモチベーション低下を防げる
デメリット
- 自動テストの実行にある程度の制約がある(フレームワークの選定やそもそも自動テストに関する関係者の理解と構築コスト)
- テストコードを書く時間が単純にかかる(一般的にコード本体よりも長い時間がかかる)
- 自動テストで確認しにくい項目(UIの修正など)もある
- 大量のデータのテストなどに向かない(データ投入に時間がかかりすぎてしまうケースなど)
- 上記の理由のため、システムが小規模な場合、構築コストを回収できない
- 実装者がテストコードを書く、ホワイトボックステストになりがちで、視点の抜け漏れがでやすい
- 観点の統一が大変(テスト項目書作成と同一の観点)
- デプロイのたびに自動テストの時間がかかる
- 品質の担保に仕様の理解がいる
- 外部サービスとの連携(AWSサービスやAPI)などにおいて仮の環境(Mock的なもの)になるため環境依存の検証が難しい
- これ以外も完全に使用ケースに即したテスト(一連の業務フローなど)を行うことは難しい
こんなところでしょうか。
一般的には自動テストが正義とされているとおもいますが、確かに限界がありますし、視点の抜け漏れに気づけないというのはありますよね・・・またピンポイントで見た場合手動テストのほうが時間がかからないという点もあります。
基本的には以下のような方針で進めるといいのでは・・と思います。
- 組み合わせが多いものなど、一般的な業務ロジックの大部分に関しては自動テストで担保
- 外部サービスとの連携などに関しては手動テストで動きを担保
- 一連の業務フローの実行に関して大まかに手動テストを記述しておくことで、テスト項目書兼仕様書兼マニュアルになる
システムに限らず、人生全般にいえることですが、全てのものごとには必ずメリット、デメリットがありますし、１か０かではなく、現実的にはその中間的な手法を採用していることが多いかと思います。
当たり前のことだと思うんですが、ある技術や手法がでたりすると意外に忘れられがちな視点なので再確認しておきたいですね。
「全ての現象には必ず理由がある。」はガリレオの湯川の決め台詞らしいですが、
「全ての現象には必ずメリット、デメリットがある」
「全ての現象には必ずグレー領域が存在する」
というのをここで書かせていただこうかなと。
