講演の背景・目的

テスト自動化に関わっていると、「テスト自動化」という言菜の意味が、広く使われ過ぎていることに気付きます。また、テストが勝手に行われるといった魔法の言葉のような印象を受けることもあります。そして、どうやって自動化すればよいのか、どういうツールを使うのか、といった手段が先に議論されることに危機感を覚えます。

こうした状況に対して、本稿は2つの目的を持って進めます。

そして、考慮すべきことを5WlHという形で提案します。

※本稿では、特に断りがない限り、「テスト自動化」をシステムテストの実行自動化として、話を進めます。

テスト自動化における5W1Hとは

5WlHで考える内容について、一つずつ、確認していきましょう。

Why:目的

テストを自動化する目的は、何でしょうか？それを考える前に、手動テストと自動テストが得意なこと、苦手なことを整理します。手動テストと自動テストの特徴を整理したのが、下表です。
手動テストの一番大きな特徴は、テストケースに書いていない事象に気付くことができる点です。
例えば、組み込み系のシステム開発のテスト中、一瞬だけディスプレイに何かが映り込んだ、ということがあったとします。人間であれば、テストケースに無いことでも、おかしいと判断して、追加で確認することができます。これは自動テストに無い手動テストの強みです。一方、自動テストにどういう強みがあるかを示したのが表の右側になります。大きな特徴は、繰り返し作業、連続作業が得意であることです。例えば、

といったことです。
人間が間違えやすいことも自動テストに向いています。正確に100回ボタンを押してくださいといった場合、人間だとカウントを間違えることもあります。しかし、自動化することで、正確にカウントして実行することが簡単に実現できます。
ここまでが手動テスト、自動テストの特徴です。

※1：自動テスト再入門（JaSST'19 Tokyo）ベリサーブ 藤田真広　http://www.jasst.jp/symposium/jasst19tokyo/pdf/E6.pdf
      初めての自動テスト：Webシステムのための自動テスト基礎　Jonathan Rasmusson（著）,玉川 紘子（翻訳）,オライリー・ジャパン, 2017

実際にテスト自動化を行う例を示したのがこちらです。

自動化するテストには、大きく2つの種類があります。
一つ目は高頻度で確認したいことです。例えば、お金周りは頻繁に確認することになるから、ここだけは自動化してほしい。そういったニーズは多くあります。
二つ目は、自動化したほうが楽になることです。例えば、連続で動かす必要がある、同時にアクセスしないといけない、といった安定性などの非機能要件に関わることが挙げられます。また、テストケースとなる条件の組み合わせが爆発的に多く、手動でやるにはどうしても人手が足りない、といったテストは自動化されることが多いと思います。
ここまでが自動化の特徴と、なぜテストを自動化するかというお話でした。

What/Where:テスト対象、テスト範囲

テスト対象の話です。
必ず「やりたいこと」「できればやりたいこと」「やらないこと」を決めましょう。システムテストを全て自動化しようとすることは、私のこれまでの経験上、うまくいったプロジェクトはありません。システムテストの自動化はテスト対象を広げようとすると、あるところから急激にコストが増加します。例えば、電源をON/OFFするなど、物理的な操作が発生するといった人間が操作しないとできないことを無理やり、実現しようと考えた場合です。盲目的に全てを自動化し始めるとうまくいきません。「やりたいこと」「できればやりたいこと」「やらないこと」を仮にでもよいので決めてから取り組むようにしましょう。

Who:作成担当者、運営担当者

Whoで考えることは3点あります。

誰が作成・構築するのか：自社でやるか、ベンダーに任せるか？

サービスを持つ企業が、自社でノウハウをためながらテストの専門家がいるベンダーなどと一緒に自動化を進めるとよいでしょう。筆者の経験上、サービスを持つ企業のエンジニアが自動テストでできること、自動化が難しい理由をしっかり把握しておかないと自動化を進める効率が悪いと感じます。しかし、自動化の取り組み経験がないまま自力でやろうとすると手探りになってしまい、これも効率がよくありません。日常の業務に追われ自動化に注力できないこともあるでしょう。
テスト対象、例えば、皆さんが関わっているシステムを考えてみましょう。
同じ組み込み系のテストであっても顧客層、開発手法、使っているフレームワークの構成など、さまざまな理由で自動化が難しいポイントは異なります。こうしたポイントは、特にサービスを持つ企業のエンジニアのほうが詳しいので、うまく自動化を進めるために、テストの専門家と一緒になって自動化に取り組むことをお勧めしています。

誰が保守運用をするのか

自動化したらそれで終わりということはありません。例えば、仕様変更により画面遷移が変わった場合、自動テストもそれに合わせて修正する必要があります。また、テストを自動実行した後に失敗するテストケースがあった場合、不具合が起きているのか、テストコード側が誤っているのかを判断するのは人間です。こうした自動テストの運用·保守は、誰が実施するかを決める必要があります。

誰と協力する必要があるのか

三つ目は、誰と協力して進めるかという点です。
特に、CI/CD環境（Continuous Integration: 継続的インテグレーション，Continuous Delivery: 継続的デリバリー）を構築するインフラ担当との協力は必須です。
自動テストを作ったけれどもテストが実行されない、必要なタイミングで動かないということが起きます。夜中に実行するように準備していても、サーバーメンテナンス中で実行されないことはよくある話です。実行環境への自動テストの組み込みを依頼すること、実行環境が利用可能な時間を調整することが必要になります。
インフラ担当以外にも、自動テストを組み込みやすくするためのプログラム本体の実装の工夫、APIの開発など、開発チームとの協力も大事です。

When:時期、実施タイミング

テスト対象のシステムが、どのタイミングで自働テストが必要になるのか、という話をします。
顧客やシステム開発側の要望の一つとして、必ず実施タイミングを確認します。そのタイミングに対して計画を立てなければいけません。自動テストの場合、一度、テストを作って実行できるようになれば、その後、同じテストの実行には、ほとんど工数がかかりません。しかし、最初に、自動テストを作るところに時間、工数がかかります。また、手動でテストできないものは、自動化できません。自動テストを作り始める時期を決めるため、まず、手動でテストできるようになる時期を確認しましょう。

How:導入手法、アーキテクチャ、開発プロセス、ツール

まずは、どこまで現実的に自動化ができるのか、検討します。
対象となるシステムによって異なるので、ただ一つの正解はありません。実際にテストケースを手動でテストしてみて、自動化できるところを検討していただくとよいでしょう
自動化の検討が終われば、ツールの選定です。
操作を録画するように記録して、操作を再実行するキャプチャ＆リプレイツールがよいのか、ソースコードのようなテスト用のコードを書いたほうがよいのか、というところでツールの種類は大きく2つに分かれます。
有償のツールもあれば、無償のツールもあります。大事なことは、やりたいことが実現できるかということです。試しにツールを使ってみるとよいでしょう。
もう一つ、How muchということにも少し触れておきます。
テストのコストダウンの話です。開発を繰り返す中で、確かに2回目以降のリリースでは、既存部分のテストのエ数は少なくなります。実際に削減したコストに関するレポートもありますので、ご参考ください。※2
しかし、本来求められているのは、テストのコストダウンではなく、開発全体のコストダウンではないでしょうか。自動化したことで、これまで手動テストをしていた人が、他の活動をできるようになり、より開発に注力できるのではないかと思います。目先のコストダウンにとらわれ過ぎないことが大事です。

※2：東芝レビュー 73巻3号（2018年5月）「ソフトウェアのテスト工数・期間を削減するためのシステムテスト自動化支援」

ケースで考えてみましょう

私が実際に携わっているシステムは、お客様の情報であるためお話することはできません。書籍のケーススタディを参考に5WlHをどのように考えていくか見ていきましょう。参考にした書籍※3から、保険の販売員が使う保険契約の申し込みシステムを取り上げます。

＜書籍からの引用＞
システム：保険系（販売員が使う保険契約の申込みシステム）
自動化したい内容：手動の回帰テストを自動化

＜書籍情報だと検討に不十分のため、追加した情報＞
システムテストケース：900件と仮定
開発期間：1年間
テスト対象：Webシステム（タブレット上でブラウザ操作）
自動テスト開始時期：商用リリース後（毎月不具合修正、機能追加が入る）
組織：テスト自動化を行うのは社内では初めて。開発は大部分を委託

※3：「Experiences of Test Automation」Dorothy Graham（著）,Mark Fewster（著）,Addison-Wesley Professional, 2012

Why

なぜ自動化するのか、というところから考えます。サンプルケースに記述がありますが、回帰テストのコスト削減を目的とします。さらに、これまで手動テストを行っていたメンバーを機能追加、不具合修正にアサインするという目的にします。

What/Where

自動化するスコープを決めましょう。サンプルケースにはWebブラウザから実行すると記述されています。ブラウザ操作の回帰テストを自動化することにします。Webブラウザのテストでは、どのブラウザで対応するのか、どのバージョンをやりたいのかという話が出ます。ここでは、Chrome、Internet Explorerのリリース時の最新バージョンのみと決めます。

Who

自動テストを誰が運用·保守していくか考えましょう。
自動テストを作成する人が必要です。＜Why＞で決めた手動テストを行っていた既存のテストメンバーに加え、自動のテストを作る人を新たにアサインします。自動テストの保守は、自動テスト作成メンバーの一部が同時に担います。
今まで実施していた手動テストは、既存のテストメンバーに任せたいですが、既存のテストメンバーは、すでに自動のテスト作成をやっているので、必要があれば、臨時で手動テストを行っていただく人を確保する必要があります。ベンダーに要員追加を依頼することも考えます。

When

いつ自動化するのかといった話です。
すでにシステムができあがっているので、すぐに自動化に着手できます。
いつ自動テストを実行するかという話ですが、毎月、不具合修正、機能追加のリリースがあるので、そのタイミングを目指します。ただ最初に自動テストを実装するには時間がかかります。例えば、最初の3ヶ月で自動化を予定している全体の10％を自動化することを目標にします。まずは目標を決めることが大事です。決めてしまえば、それに対して効率よくできたのか、問題があって進められなかったのかということがわかるようになります。まず、目標値を決めます。その後、実際に自動テストを運用して、運用の結果を見て、計画を見直していただきたいと思います。

How

ツールとしては、キャプチャ＆リプレイツールを採用します。
開発は多くの部分を委託しているという記述があります。スクリプトを作るというのは難しいと想像します。今同は、キャプチャ＆リプレイツールを採用します。

以上が、サンプルケースを基に大まかに考えた5W1Hです。

今後のテスト自動化

最近では、AIを使ったテスト自動化ツールが出てきています。
いろいろ種類はありますが、システムの変更を検知し、テストを自動修復（セルフヒーリング）する機能を持ったツールが増えてきている印象です。こうしたツールが徐々に使えるようになることで自動テストのメンテナンス工数が減っていくだろうと、私たちも、現在、見守っているところです。
ただ実際に自動修復された内容、具体的には、あるボタンの変更があったので、別のボタンを押すように変更した、という修復がされた時、それが正しいかどうか、人間が判断する部分は残ります。今後、そうした判断も、AIに任せられるかもしれませんが、まだ人間の判断が必要な状況は続くと思っています。

まとめ

お伝えしたいメッセージは3つあります。
一つ目は、「テスト自動化をする目的を明確にする」ということです。明確な目的がないままトップダウンからの指示だけで自動化を進めて失敗した例をたくさん見てきました。失敗しないために、まず目的を明確にしてください。
二つ目は、「費用対効果を高めるためにPDCAを細かく回す」ということです。やってみて、何かがわかって、次のアクションを決めて、進めていくことが大事です。システムとの親和性、想定コストとの差異を観察し、範囲やスケジュールを変化させていくことが必要です。
三つ目は、「組織、システム、開発状況によって、最適な自動化の進め方は異なる」ということです。他社、他のプロジェクトの前例やアンチパターンに振り回されず、自分たちのノウハウをためていくことが大事です。
サービスを持つ企業のエンジニアの方と、我々のような自動化のプロが手を携えて、試行錯誤して進めていければと思います。

この記事をシェアする