テスト自動化で「失敗しない」ために、何がいる？ 必要なツールと手順をおさらい：一から分かる！ テスト自動化（2）

テスト自動化に取り組みたいけれどノウハウがない、過去に導入していたがうまくいかなくてやめた人に向けて、テスト自動化の「あるある」な失敗事例とともにどうすればうまく取り入れられるのかを解説する本連載。第2回は自動化ツールの種類やテスト自動化に必要な手順について。

[江添智之，バルテス株式会社]

　今回は、テスト自動化の導入について、ツールの種別や必要な手順を解説していきます。

　まず、はじめに押さえておくベき、最も大切なことは「テストの全てをいきなり自動化しない」ということです。テスト自動化ツールにはさまざまな種類があり、それぞれのツールに得意、不得意があります。また、テストにもさまざまな種類があり、ある1つのツールで全てのテストが自動化できるわけではありません。

　テスト自動化を導入する場合は、テスト自動化に向いている領域から始めていくことがポイントです。成果の上げやすいところから徐々に自動化を進めていき、自動化の領域を広げていく、というのがよい戦略といえるでしょう。

テスト自動化ツールの種別

　テスト自動化ツールには以下のようなものがあります。

テスト自動化ツールの種別

UIテストツール

　UIテストツールは、人間が操作するように実際にUI（ユーザーインタフェース）を操作してテストを実施します。Webシステムであればブラウザを自動操作し、その他のアプリケーションでも、実際の画面を操作するような仕組みとなります。具体的なツールとしては、「Selenium」や「Ranorex」また、弊社が提供している「T-DASH」などがあります。

APIテストツール

　次に紹介するユニットテストツールとUIテストツールの中間に位置するといえるのが、APIテストツールです。主にUIの裏側に位置するAPIと呼ばれるインタフェース部分のテストに使用します。Webアプリケーションを例に説明すると、Webブラウザ上でユーザーが操作した内容は、APIのコマンドとしてネットワーク上で送受信されます。そのAPI部分を直接操作し、入出力の妥当性を評価するためのツールがAPIツールです。APIツールには「Swagger」や「POSTMAN」などがあります。

ユニットテストツール

　ソースコード単位でテストを実行する際に使用します。ユニットテストで使用されますが、TDD（テスト駆動開発）をする際に使用することもあります。ソースコードのメソッドなどを直接呼び出し、戻り値などを検証します。具体的なツールとしては、「xUnit」と呼ばれるツール類があります。xの部分はプログラム言語によって変わり、Java用の「JUnit」、.NET Framework用の「NUnit」などがあります。

パフォーマンス／性能テストツール

　非機能特性とも呼ばれる、システムの性能を検証する際に使われるツールです。例えば、システムへのアクセスが想定を超えても問題なく動作するかどうかといった点や、負荷が集中した際のスループットやレスポンスタイムが問題ないかを計測するために使用します。具体的なツールとしては、「Apache JMeter」などが有名です。

静的解析ツール

　厳密な意味でのテスト自動実行ツールではありませんが、同様に使用されることも多く、また非常に有用であるため、こちらでも紹介します。

　静的解析ツールとは、ソースコードの記述内容を解析し、問題のあるコードなどをチェックするものです。プログラムを動作させずにチェックするため「静的」解析と呼ばれています。例えば変数の型変換など、コンパイラでは問題がなくとも潜在的にバグが発生しやすい記述などを洗い出すことができます。また、ソースコードの記述フォーマットなどのコーディング規約のチェックツールもこれに含まれます。具体的なツールとしては、「SonarQube」や「PGRelief」などがあります。

　このように、テスト自動化ツールにはさまざまな種類があります。その全てを一度に導入するというのは現実的ではないでしょう。しかも、単独のツールを導入する場合であっても簡単というわけではありません。ここからは自動化導入に当たっての進め方や注意点を見ていきましょう。

テスト自動化の失敗パターン

　導入部分でも書いた通り、全てのテストをいきなり自動化しようとすると、多くの場合は破綻につながってしまいます。ここでは2つの事例を紹介していきます。

技術的に困難な部分の自動化

　まずは、自動化に向いていない部分のテストを自動化しようとして、途中で破綻してしまうというケースです。

　例えば、新しい技術を使用してシステムを構築している場合、テスト自動化ツールからシステムへの連携がうまくいかないことや、場合によってはデータ連携ができないといったことが発生します。

　あるソフトウェアのUIテストを自動化しようとした際の経験談ですが、そのソフトウェアは画面の入力フォームにサードパーティー製のライブラリを使用していました。他のフォームに対してはツールによる自動入力がうまくいったのですが、そのフォームに対して文字列を直接入力することができませんでした。

　苦肉の策として画面上の位置情報とキーボード入力を使用してデータを自動入力するようにしました。当初は問題なく動作したのですが、仕様変更によってそのフォームの場所が変わるたびにスクリプトの方も修正が必要となり、あまりにも工数がかかり過ぎるため、その部分の自動化は途中で断念せざるを得なくなりました。

技術的に困難な自動化

再利用できないスクリプト

　次は技術的には困難ではなくても、スクリプトの作成方針の問題で自動化ができないという事例です。

　あるシステムのマイグレーション（古いシステムを新しい技術によるシステムに置き換えること）を行っていた際に、大きな問題となったのが、現新比較です。今動いているシステムと新しいシステムで、処理の結果に違いがないかどうかを確かめるテストでした。

　全てを手動で実施することは現実的ではなかったため、テスト自動化のスクリプトを大量に作成しツールで実施することにしました。その際、テストスクリプトに対して直接パラメーターを記載してしまったり、処理が共通な部分があっても個々のスクリプトごとに実装したりしていました。結果、現新比較自体はうまくいきましたが、そのスクリプトを後で使用することができず、大半のものが1回限りの使い捨てとなってしまいました。当時は時間がなかったためにそのような作りになってしまったのですが、もう少し工夫していればその後の作業効率化につながっていたと思います。

　ここまで、失敗事例を2つ紹介しました。いずれの例もうまく進めようと思えばできたかもしれませんが、最初の段階で方向性を十分に検討できていなかったために、望ましい結果となりませんでした。

テスト自動化のピラミッドとアイスクリームコーンのアンチパターン

　上記のような失敗をしないためにはどのようなことに気を付けるべきでしょうか。基本的な考えとして、テスト自動化は下記のようなピラミッド構造で、テスト自動化のしやすい部分、しにくい部分があります。

テスト自動化のピラミッド

　こちらは、「テスト自動化のピラミッド」と呼ばれているものです。ピラミッドの下層に行けば行くほど、その大きさが増えています。つまり、テスト自動化をする際には下の部分がテスト自動化可能な領域が多いということになります。もちろん、ユニットテストレベルのテストが全て簡単に自動化できるというわけではありませんが、この比率自体はどのようなシステムであっても変わらないでしょう。

　UIテストツールの進歩もめざましく、以前はうまく自動化できなかった部分についても簡単に実装できるようになってきています。しかしながら、テスト全体に対する比率についてはやはり大きく変わることはないでしょう。ですので、まずはユニットテストでできる部分から検討を進めていくことが基本的な進め方といえます。

　逆に、UIテストを厚くすることを「アイスクリームコーンのアンチパターン」と呼ぶことがあります。

アイスクリームコーンのアンチパターン

　前述の通り、UIテストは技術的に難しい場合や、スクリプトのメンテナンスコストが高くなる場合も多いため、あまりお勧めはできません。ただし、現実問題としてユニットテストの自動化が難しい場合もあります。例えば、レガシーシステムを使っていて自動化ツールが対応していない場合や、古くから使われているソースコードに対して、コードの置き換えやリファクタリングが難しい場合です。そのような場合はいったんUIテストレベルで全体の挙動を担保しつつ、レガシー部分に手を入れていくという方法も考えられます。原則は原則として知っておき、実際の開発プロジェクトの状況に合わせて戦略を練り、進めていくというのがよいでしょう。

テスト自動化に必要な準備

　それでは、テスト自動化の導入について具体的な進め方を紹介していきます。上記のような失敗をしないために考慮するべき事項や、その他の注意点についてもここでまとめておきます。

テスト自動化導入の進め方

1．テスト対象システムの理解

　ここまで解説した通り、テスト自動化は「取りあえず」や「なんとなく」という形で行うべきではありません。対象となるシステムの構成や、開発プロセスを整理し、どの部分からどのように自動化を進めていくのかを考えておく必要があります。主に下記のような内容を確認していくことになります。

• テスト対象システムのインタフェース

　テスト対象システムを自動化ツール側で操作できるようなインタフェースが存在するかを確かめます。UIテストツールであれば、ユーザーが操作するような形でテスト対象システムを操作しますが、APIツールやユニットテストツールが使用できるかどうかも確認しておく必要があります。それに応じて、使用できるツール選択の幅が決まります。

• テスト対象システムの複雑さ

　テスト対象システムがシンプルな場合、テスト自動化ツールも単純な方が向いている場合があります。先述の例であった、スクリプト内にパラメーターを直書きするなど、高度に共通化しない方が場合によっては分かりやすくなることもあります。逆に、テスト対象のシステムの規模が大きかったり複雑だったりする場合は、テスト自動化の仕組みも複数のツールを組み合わせるなどして、効率的にスクリプトのメンテナンスや実行が行えるように工夫する必要があるでしょう。

• サードパーティー製のソフトウェアの使用状況

　こちらも先述の例にあった通り、開発チームが実装している以外の部分にテスト自動化が適用できるかどうかは慎重に調査する必要があります。場合によっては別のツールを使用してサードパーティー製の部分を自動化する必要があります。

2．テスト対象システムに適したテストツールの選定

　前項の内容を調査した後、使用するテストツールを選定します。第1回でも解説した通り、テスト自動化においてもっとも大切なことは費用対効果です。継続して使用できるかどうかが選定のポイントになります。そのために、どのレイヤーでテスト自動化を適用するか、テスト対象システムに合致したものか、テスト自動化の方針に合ったツールなのか、サポートは充実しているか、といった検討要素を挙げ、幾つかのツールを試用してみるのがいいでしょう。

3．環境の構築

　テストツールを選定したら、それを実行する環境を構築していきます。場合によっては新たなハードウェアやライブラリを準備する必要が生じるかもしれません。また、自動化ツールとテスト対象システムを同じ環境で動作させる場合、パフォーマンスに影響を及ぼす可能性があります。そのような点も事前に検証できるとよいでしょう。

　テスト自動化環境がいつでも使用できる状態にしておくことは、自動化導入成功のカギを握っているといっても過言ではありません。自動テストを実施するタイミングはプロジェクトの中で常時発生するわけではなく、間が空いてしまうことがあります。そのような場合、「しばらく使っていなかったら動かなくなってしまった」という状況が発生してしまうことがあります。テスト自動化にとってこういう状況は最悪です。にもかかわらずそのようなことがよく発生しがちです。次項のトレーニング計画も含めて、環境の保守についても十分に考慮しておくことが重要です。可能であれば、CI（継続的インテグレーション）ツールなどを併用して自動テストを常に実施するようにし、環境的な問題を早めに検知できるようにしておくといいでしょう。

4．トレーニング

　第1回でも解説した通り、自動化ツールの属人化は発生しやすく、かつ自動化戦略全体に影響する問題となります。そうならないようになるべく複数の人が自動化ツールの仕組みを理解しておくことが重要です。サポートチームを構築できればよいですが、そこまでの人的余裕がない場合でも、誰か特定の個人に作業を集中させることは避けた方がよいでしょう。さらに、テストに携わる人全員がテストスクリプトの記述内容を理解し、改修できるようにしておくことが理想です。

　これを実現するためには、それ相応のトレーニングが必要となります。時間を確保してグループ内での勉強会を行う、新規プロジェクトやバージョンアップの際には新しいメンバーに自動化作業を依頼し、既存メンバーはサポートに回る、などの方法でノウハウを共有するとよいでしょう。

　今回は、テスト自動化の準備に必要な考え方を紹介しました。次回は構築が難しいUIテストの自動化を中心に、フィージビリティスタディーを導入して効率的に検証を行う方法を解説します。

参考文献

ISTQBテスト技術者資格制度 Advanced Level シラバス テスト自動化エンジニア 日本語版 Version 2016.J01

テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社／リサ・クリスピン、ジャネット・グレゴリー 著／榊原彰 監訳・訳／2009

筆者紹介

江添 智之

バルテス株式会社

クロス・ファンクショナル事業部 R&C部 マネージャー

Web系、エンタープライズ系、医療系などさまざまな開発業務にプログラマー、システムエンジニア、プロジェクトリーダーとして携わった後、バルテスにてテストエンジニア、コンサルタント業務に従事。現在は、主にテスト業務に関する研究開発および人材育成を担当。Scrum Alliance認定スクラムマスター、ディープラーニング検定（G資格）、ネットワークスペシャリスト、データベーススペシャリスト、JSTQB Advanced Level（テストマネージャ、テストアナリスト）など、ソフトウェアの開発およびテストに関する資格を多数取得。JaSST Kansai 実行委員。同社が運営するソフトウェア品質向上プラットフォーム「Qbook」の執筆を担当するなど、ソフトウェア開発に携わるエンジニアに対しての情報発信を積極的に行う。