開発者としての「テスト自動化」の基礎

2018年5月28日(月)
山口 鉄平

はじめに

本連載は、開発を加速・効率化させるソフトウェアテストをテーマに解説を進めています。前回の解説で、読者の方々はソフトウェアテストの新たな分類やそのアプローチを知ることができたのではないでしょうか。

今回は、「開発者としての」という視点で「テスト自動化」の実践に向けた基本を解説します。なお、ここではテスト自動化を下記のように定義することとします。

「ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること(ソフトウェアテスト標準用語集(日本語版)Version 2.3.J02)」

その上で、皆さんが開発者にとってのテスト自動化を知り、テスト自動化をどのように実施するかチームで議論・決められるようになることを期待しています。

開発者にとってのテスト自動化のメリット

テスト自動化とは人手で行うことをソフトウェアで実施することになるため、そのメリットは基本的に「効率化」です。

ただし、実際にはそれに留まらず、テストを人手で行うことにより発生する「うっかり忘れ」「テスト操作のミス」などをなくすことに加え、効率化の実現によりテスト範囲を広げることもできるため、不具合の社外流出などを防ぐことが可能になります。

一般的なテスト自動化のメリットは上記のとおりですが、特に開発者にとっては「安心」というメリットもあります。テスト自動化することで、頻繁にテストを実施できるようになります。開発しながら頻繁にテストを実施できれば、開発上の問題を早期に知ることができます。正に安心を得ながら開発を進めることができるのです。

テスト自動化の留意事項

上記のようなメリットがあるテスト自動化ですが、留意点も存在します。筆者らが属しているテスト自動化研究会ではそれら留意点などを議論し、「ソフトウェアテストの7原則(ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02)」にならい、「テスト自動化の8原則」として公開しています。

「原則」と書いていますが、テスト自動化を始めることで新たに発生することや観測されること、効果的にテスト自動化するためにすべきことをまとめたものです。

ここでは、テスト自動化の8原則の中から、下記の2つを紹介します。

「5. 自動テストシステムの開発は継続的におこなうものである」
「6. 自動化検討はプロジェクト初期から」

自動テストシステムの開発は継続的におこなうものである

テスト自動化とは、大まかに言うと「テスト対象のシステムに対してテストをするもう1つのシステム、言い換えれば自動テストシステムを新たに作ること、それと合わせて自動テストシステムを効果的に利用するためのルールなどを決定・運用すること」となります。

その自動テストシステムは1度作れば終わりというものではなく、テスト対象の変化への追従など、テスト自動化の効果を持続させるための継続した開発・修正が必要となります。加えて、自動テストの高速化や安定性を向上させるための開発・修正なども必要です。

自動化検討はプロジェクト初期から

自動化を考慮せずに開発したアプリケーションやシステムを後からテスト自動化することは困難です。自動テストのための入出力取得や操作可能にするための大きな改修が必要となるためです。

したがって、テスト自動化に取り組む際にはプロジェクト初期から検討し、設計に織り込む必要があります。これによりテスト自動化するコストが低くなるとともに、開発の初期から自動化の恩恵を受けられるようになります。

「テスト実行」の自動化を始めるには

テスト自動化はテスト活動全般を対象として定義していますが、現時点ではテストプロセスにおける「テスト実行」を対象とすることが多いです。なお、テスト実行の自動化とは、

「テストの実行、実行結果と期待結果の比較、テスト条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること(ソフトウェアテスト標準用語集(日本語版)Version 2.3.J02)」

です。これは、テスト設計やテストをマネジメントする方法の多様性、ツール不在などの要因が考えられますが、テスト実行の自動化の容易性や自動化による効果の高さから「まずはテスト実行から」自動化が行われているのではないかと筆者は考えています。

そこで、以降ではテスト実行の自動化の始め方を解説します。前述のとおり、テスト実行の自動化とは自動テストシステムを新たに作るとともに、そのシステムを効果的に利用するためのルールなどを決定・運用することです。

その自動テストシステムを含むテスト自動化を実現するシステム(以下、テスト自動化システムと呼ぶ)を、筆者は相互に関係する次の4点を考えつつ、実際に利用できる形にしながら作り込んでいきます。

  1. どのようなテスト対象に対してテスト自動化するのか
  2. どのような確認したいことをテスト自動化するのか
  3. どのような実施の形態のテストとするのか
  4. どのような自動テストシステムを継続的な開発・修正するのか

早期に実際の利用形態を形作る理由は、当初想定する利用形態と実際の良い利用形態は多くの場合で異なるためです。

テスト実行の自動化の目標が手動テストを自動テストに置き換えることだとしても、自動テストは継続的インテグレーション内で実施するなど手動テストとは利用形態が変化するため、利用形態を早期に形作り、それをより良い形に修正していくことをお勧めしています。

なお、どのようなテストから自動化していくかについては第2回「ソフトウェアテストのスムーズな導入」、筆者らとともにテスト自動化研究会に所属する太田健一郎氏の「テスト自動化のROIを計算してみよう」という記事で解説しています。

具体的にはROIに基づいて決定すると良いでしょう。ただし、テスト実行の自動化を初めて行う場合、効果は大きいが難易度の高いテスト自動化システムづくりに取り組むことはお勧めしません。システムづくりの難易度が高いと、結果的に実現できず途中で諦めてしまうことが多いように思えます。

どのようなテスト対象をテスト自動化するのか

どのようなテスト対象をテスト自動化するかにより、テスト自動化システムおよびその中に含まれる自動テストシステムは異なります。 第4回の「ピラミッドとサイズによるテストの大枠を整理する」「テストサイズを開発に適用する」 で解説したように、メソッド単位で確認するテストとアプリケーションやシステム単位で確認するテストは実行環境が異なります。前者は開発環境と同等、後者はアプリケーションやシステム自体の実行環境です。

また、テスト対象によって利用形態は異なります。メソッド単位で確認するテストは頻繁に実施されることが望まれ、開発者の手元の環境で任意の実施や継続的インテグレーション内での実施が主となります。一方、アプリケーション単位のテストは1つのテストの実行時間が長いこともあり、開発者の手元の環境では実施せず、プルリクエストごとやリリースプロセス内での実施になりがちです。

このように、どのようなテスト対象をテスト自動化するかを考えることで、自動テストシステムや利用形態などテスト自動化システムの具体化を進めていくことができます。

何を確認するためにテスト自動化するのか

前項でテスト対象を考える際に併せて考えることにもなりますが、何を確認するためにテスト自動化するかでシステムの形は異なります。機能を確認する際にはある入力に対する出力結果を確認するようなシステムが必要になるのに対し、パフォーマンスを確認する際にはある入力に対する処理がどの程度の時間を要しているかを確認するシステムが必要になります。

加えて、手動テストの際に目視で確認していたことをどのように自動テストとして実現するかを検討する必要があります。

文字列や数字による確認は自動テストとして容易に実現できますが、画像やランダム性があるものによる確認は自動テストとして実現が困難となります。そのため、手動テストとは異なる、新たな自動テストでの確認方法を決めなければなりません。

このように、何を確認するためにテスト自動化するかを考えることで、必要となるテスト自動化システムの具体化を進めていくことができます。

どのような利用形態のテストとするのか

自動テストは実行コストの低さや速度の面から、手動テストとは利用形態が変化します。また、テスト対象のアプリケーションやシステムの状況によって確認したいことが変化し、それに伴って利用形態も変化することがあります。

例えば、テストコードが少ない際はすべてのテストを継続的インテグレーション内で実施していたとしても、テストコードが増えてきたら実行時間の問題からテストコードをいくつかのグループに分割し、グループによって毎回や1日1回など実行頻度を変化させることがあります。

このように、良い利用形態は状況によって変化するため、利用形態を早期に形作り、それをより良い形に修正していくことをお勧めしています。修正していく際の基本的な考え方は、「どのようにすれば高頻度でテストが実施できるか」です。

高頻度でテストを実施することで開発を加速・効率化できるので、これらを実現できるような利用形態を模索していきます。

どのような自動テストシステムを継続的に開発・修正するのか

テスト自動化システムでは、テストを実行させる環境とその環境上で動作するテストコードから構成される自動テストシステムが必要です。そして、テスト実行の自動化を進める際には、この自動テストシステムを継続的に開発・修正します。

そのため、テスト自動化に携わる人々が効果的・効率的に開発・修正を行える自動テストシステムが必要となります。

そこで、テストを実行させるシステムやテスト対象の実行システムの制約、携わる人々のスキルなどを考慮し、テストコードの記述言語や管理方法、自動テストシステムの構成を決めていきます。

テスト自動化を実現するテストツール

テスト自動化ではソフトウェアを使うことが前提となるため、テスト自動化を実現する多くのテストツールが存在します。本連載でも第2回の「とりあえずのオススメは静的解析ツール/単体テストの自動化/CI」や第5回の「まずは構造を浮き彫りにするテストから入るのもよい」などで多くのテストフレームワークやテストツールを紹介していますが、すでに紹介しているテストツール以外で、筆者がよく利用しているテストツールを紹介します。

なお、これらのツールすべてを1つのアプリケーションのテスト自動化で利用しているのではなく、1つのアプリケーションごとに1つもしくは複数を組み合わせて利用しています。

【「テスト設計」のテストツール】
・組み合わせテストの自動設計
PICT:効率的な組み合わせテストのテストケースを設計する際に利用
PictMaster:ExcelからPICTを利用する際に利用
FMPict:マインドマップツールのFreeMindのモデルからPICTを利用する際に利用

【「テスト実行」のテストツール】
・ブラウザアプリケーション/システムのend-to-endテストフレームワーク
Selenium:ブラウザの自動操作フレームワーク。Nightwatch.jsやGeb、Selenideといったテストフレームワークのベースとなっている
Nightwatch.js:テストケースを開発する人がJavaScript/Node.jsを得意としている際に利用するケースが多い
GebおよびSpock:テストケースを開発する人がJava/Groovyを得意としている際にこの組み合わせを利用することが多い
Selenide:テストケースを開発する人がJavaを得意としている際に利用することが多い

・スマートフォンアプリケーションのテストフレームワーク
Appium:Windowsアプリケーションにも利用できるが、Android/iOS両アプリケーションにend-to-endテストを自動実行する際に利用
UI Automator:Androidアプリケーションにend-to-endテストを自動実行する。特にテスト対象のアプリ内部の詳細な実装が不明な際や、テスト端末上で設定などを操作したい際に利用
XCTest/XCUITest:iOSアプリケーションにコンポーネントテストやUIテスト、end-to-endテストを自動実行する際に利用

上記のテストツール以外にも、多くのテストツールが存在します。それらの一部をまとめたものとして、特定非営利活動法人 ソフトウェアテスト技術振興協会(ASTER)のテストツールワーキンググループが公開している「テストツールまるわかりガイド」があります。興味がある方は、そちらもご覧いただくとテストツールの多さが分かります。

テスト自動化のスキル

テスト自動化を効果的に行うためには、知識だけでなくスキルの向上が欠かせません。テスト自動化自体は長年行われているものの、注目されるようになったのが最近なことや従来は異なる技術分野と見られていたテストと開発を横断して関わるため、まだ学ぶべき基本やスキルの整理が進んでいないのが現状です。

このような現状に対して、テスト自動化研究会ではASTERが公開している「Test.SSF」を参考に「AutomationTest.SSF」の作成を進めています。

AutomationTest.SSFは、テスト自動化研究会が2016年に開催した「システムテスト自動化カンファレンス2016」で「α版」を、2017年に開催された「JaSST'17 Tokyo」で「β版」を公開し、現在はクローズドに試験利用している状態です。遠くない時期に一般公開できると考えています。

AutomationTest.SSFは、テスト自動化に関わる人たちが学習するための指標を作れるようになることを目標にしています。例えば、自分は何が弱いのか、自分はこれから何を学習すれば良いのか、自分の役割にはどのようなスキルが必要なのか、などを把握できるようになることです(図1)。

図1:AutomationTest.SSFの利用想定

そのため、テスト自動化全体を範囲とし、特定のテストレベルに依存しない内容となっています。また、数多の種類のテスト自動化が存在することを踏まえ、現場でカスタマイズして使うことを前提に作成しています。

なお、現時点でのAutomationTest.SSFでは、次の4つのカテゴリに分類したスキルとタスクで構成しています。詳細は「AutomationTest.SSF β版」を参照ください。

【テスト自動化システム関連の管理】
・テスト自動化プロジェクトを進めるスキルおよび構築したテスト自動化システムを維持するスキル
【テスト自動化戦略の策定】
・テスト自動化システム開発ライフサイクルとテスト自動化戦略をまとめるスキル
【テスト自動化システムの開発】
・テスト自動化システムを作るスキル
【自動テストケースの開発・実行】
・自動テストケースを作って実行するスキル

上記のようなテスト自動化の個別スキルの向上には、それに適したソフトウェア開発およびテストスキルを向上するための書籍や資料などが利用できます。皆さんには自身が弱いと感じるスキルについて学びを深めていただき、より効果的なテスト自動化を実現していただきたいと考えています。

おわりに

今回は、「開発者としてのテスト自動化」という視点で、テスト自動化のメリットや留意点、テスト実行の自動化の始め方について解説しました。加えて、テスト自動化のスキルについても紹介しました。テスト自動化はソフトウェアテストの側面だけでなくシステム開発の側面もあるため幅広い知識や経験を必要とします。ただし、テスト自動化を始める前は必要な知識や経験も見えづらいので、まずは自分ひとりでできる範囲から始めることをお勧めします。

次回は、ソフトウェアテストを行うために必要となるテスタビリティを解説します。

テスト自動化研究会 / ヤフー株式会社
モノづくりを試行錯誤する中でアジャイル開発やテスト技術に出会い、それらの研鑽や普及をおこなっている。現在の主な活動は、テスト自動化研究会 お世話係、(一社)スクラムギャザリング東京実行委員会 理事、(一社)アジャイルチームを支える会 監事など。共訳書に『Fearless Change(2014 丸善出版刊)』がある。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています