skillup

技術ブログ

ドキュメント作成 プロジェクト管理

手動テストと自動テストのメリデメについて

投稿日:2023年5月20日 更新日:

自動テスト環境で作業をするようになって1年近く経ちますが、現在の案件でも手動テストはやっております。

一般的には自動テストをがっちりと装備するのがいいと言われがちですが、やはり自動テストのデメリット、手動テストのメリットなどもあるよなと思い、今回は手動テストと自動テストのメリデメなんかを。

手動テスト

メリット

  • 実行だけに関していえばどんなテストでも手順書どおりに行えば本番同様の再現が可能
  • テスト項目書自体が仕様書になる
  • 実行者のスキルに依存しない(開発の知識がなくても実行が可能)
  • 実装者と別の人間が行うことで盲点に気づける(モンキー的なテストができる)

デメリット

  • 作業が単調になりがちで、実施者のモチベーションをキープすることが難しい
  • 項目書の作成(特に作成観点)はある程度のスキルが必要なのと、統一するのが難しい
  • アジャイル的な修正が頻繁な場合には向かない(再びテストをする必要がでてくるため、コストが膨れ上がる)
  • テスト実行前の環境用意が大変(できればベンダーごとにわけれないときつい・・・手動テストをする際、環境がテストデータがtruncateなど初期化可能かを確認しておくこと。これができないとほぼ無理)

自動テスト

メリット

  • 自動でテストが行えるため、システムの規模が大きいほど効果が大きい
  • カバレッジなどで網羅率をみることができるため、機械的な漏れに気づける
  • n×m系の組み合わせが多い場合の確認などプログラムで簡単に確認できるため、効果を特に発揮する
  • アジャイル的な開発現場の場合、再テストの時間がかからず、品質の担保が行えることと再テストがないため、テスターのモチベーション低下を防げる

デメリット

  • 自動テストの実行にある程度の制約がある(フレームワークの選定やそもそも自動テストに関する関係者の理解と構築コスト)
  • テストコードを書く時間が単純にかかる(一般的にコード本体よりも長い時間がかかる)
  • 自動テストで確認しにくい項目(UIの修正など)もある
  • 大量のデータのテストなどに向かない(データ投入に時間がかかりすぎてしまうケースなど)
  • 上記の理由のため、システムが小規模な場合、構築コストを回収できない
  • 実装者がテストコードを書く、ホワイトボックステストになりがちで、視点の抜け漏れがでやすい
  • 観点の統一が大変(テスト項目書作成と同一の観点)
  • デプロイのたびに自動テストの時間がかかる
  • 外部サービスとの連携(AWSサービスやAPI)などにおいて仮の環境(Mock的なもの)になるため環境依存の検証が難しい
  • これ以外も完全に使用ケースに即したテスト(一連の業務フローなど)を行うことは難しい

こんなところでしょうか。

一般的には自動テストが正義とされているとおもいますが、確かに限界がありますし、視点の抜け漏れに気づけないというのはありますよね・・・またピンポイントで見た場合手動テストのほうが時間がかからないという点もあります。

基本的には以下のような方針で進めるといいのでは・・と思います。

  • 組み合わせが多いものなど、一般的な業務ロジックの大部分に関しては自動テストで担保
  • 外部サービスとの連携などに関しては手動テストで動きを担保
  • 一連の業務フローの実行に関して大まかに手動テストを記述しておくことで、テスト項目書兼仕様書兼マニュアルになる

システムに限らず、人生全般にいえることですが、全てのものごとには必ずメリット、デメリットがありますし、1か0かではなく、現実的にはその中間的な手法を採用していることが多いかと思います。

当たり前のことだと思うんですが、ある技術や手法がでたりすると意外に忘れられがちな視点なので再確認しておきたいですね。

全ての現象には必ず理由がある。」はガリレオの湯川の決め台詞らしいですが、

全ての現象には必ずメリット、デメリットがある

全ての現象には必ずグレー領域が存在する

というのをここで書かせていただこうかなと。

-ドキュメント作成, プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

プログラムからとExcelからのテストデータ作成

テストデータの作成ですが、プログラムから作成するケースとExcelからシコシコ作ってSQLをがんと入れる場合があります。Excelつってもマクロを使ったりするんでプログラムですし、実際にはPHPとEx …

no image

開発時最低限必要かつ有用なドキュメントに関して

ウォーターフォール型の開発をかれこれ1年近くやっております。 自分がやってきた仕事とすると別職種に近いようなイメージでしたが、得ることも多かったため、ここに記しておこうと思います。 以前書いたことの記 …

no image

KPT法について

プロジェクトを進めていく上では、いいこと、悪いこと様々あるかと思いますが、 よかったものは続け(Keep)、 問題点に関しては直視し(Problem)、 改善を試みる(Try) のが良いかと思います。 …

no image

ログ対策(どのように情報を抽出するか)

現在、現場でテストをやってるんですが、やることは昔と変わらずテストデータ作り、ログ、エラーハンドリングになります。 3年近くまえに↓のような記事をかいてました。 ログの設計指針について テストデータ( …

no image

チーム内の行動変容(定着する、しない仕組みづくりについて)

学習塾時代からそうだったのですが、チーム内で新しいとりくみなどを始めてもなかなか定着せずに忘れ去られてしまう仕組みものというのがいろいろありました。 以下で書きましたね・・ 文化づくりについて(チーム …

アーカイブ