アーカイブ動画

テスト自動化はどうして難しいのか？

バルテス株式会社
Web・IoT品質サービス事業部　マネージャー　工藤 基成氏

最初に登壇した工藤基成氏は、テスト自動化を「導入」するうえで覚えておきたいことをテーマに、テスト自動化はなぜ難しいのかについて語った。

工藤氏はバルテス入社以降、Webサービス領域での手動テストプロジェクトを経験し、テスト自動化の専任メンバーとして、社内外のプロジェクトをPMとして数多く担当している。

テスト自動化を導入する上で覚えておきたいこととしては、「自動化の特性」「自動化の継続利用に向けて」の2つであると工藤氏は語り、それぞれ詳しく紹介した。

●自動化の特性

自動化の特性において、テストの自動化が適しているかどうかは、そもそもアプリの開発手法やフレームワーク、実装方法などに依ることが大きい。

「自動化フレームワークは万能ではない」と、工藤氏は強調する。アプリのタイプやテストケースの内容などを考慮した上で、導入を検討する必要があるからだ。

「言われたことしかできない」という特性については、まさにコンピューター、プログラムによるテストらしいと言える。具体的には、1つでも手順が抜けているとテストが動作しないため、スクリプトを細かく表現、実装する必要がある。

また、文字化けや色判定といった人の感覚に頼ることが多いテストにおいては、コストをかければ自動化は可能だが、人が行った方が速く、コスト面からも適切だという。

●自動化の継続利用に向けて

大前提として、テストの自動化を行うことは、プログラミングする作業に近いため、手動テストに比べて、5〜10倍程度の導入コストがかかる。当然、メンテナンスコストもかかってくる。

そのため「やみくもに自動化を行わない」という考えがポイントだと、工藤氏は語る。そして先の内容にも重なるが、手動で行った方がコスト面も含め効果的な場合は、手動テストを考慮することも重要となる。

2つ目のポイントは、「長く使い続けられる体制の構築」だ。こちらもメンテナンスが必要となるため、導入時からメンテナンスしやすい体制を構築しておくことが必要とされる。体制はメンテナンスを行う人材の育成や立場も考慮することであり、工藤氏が最も伝えたいことでもある。

「これまでの経験も踏まえ、私自身が常々思っていることですが、継続的に使われない自動化を導入しても意味がありません。長く使ってもらうことで、初期にかかったコストを回収できるのです」（工藤氏）

長く使い続けてもらうためには、段階的にテスト自動化の導入を進めることが重要となる。そこで工藤氏は、導入における3つのステップを紹介した。

まずは「運用で自動テストをどう使うか」、具体的には自動化構成の検討を行う。次のステップは「自動化スコープの厳選」で、初期コスト削減につながる。そして最後が「自動化ツールの利用検討」だ。こちらは導入することで、メンテナンス性の向上が期待できる。

工藤氏は改めて次のように述べ、ファーストセッションを締めた。

「繰り返しになりますが、テスト自動化は使われることに意味があるため、使われなくなった時点で、そのプロジェクトは失敗だと思っています」（工藤氏）

テスト自動化ツール「T-DASH」の導入で得た成果・気づき・課題

バルテス株式会社
エンタープライズ品質サービス第1事業部
東日本ソリューション部　リーダー　田中 駿氏

続いて登壇した田中駿氏は、「現場で気づいたテスト自動化導入の課題と対策」をテーマに、自社のテスト自動化ツール「T-DASH」の導入に関する内容を紹介した。

田中氏はWeb開発会社でシステムエンジニアとしてのキャリアをスタートさせた後、広告会社でHR系のサービス運用を経て、バルテスにジョイン。テストエンジニア、PLとしてさまざまな業界のプロジェクトに従事している。

まず田中氏が語ったのは、現在のプロジェクト概要と課題についてだ。十数年以上稼働しているHR系サービスのWebアプリケーションであり、ユーザーからの要望や法改正などにより、機能追加を繰り返しており、現在はシステムの大規模リニューアルを行っている。

いわゆるレガシー的な負の遺産を抱えるシステムであり、コードの管理もできておらず、デグレ（不具合）が頻発し、手動ではリグレッションテストが追いつかない状態だという。

Webアプリケーションのテスト自動化OSSであるSeleniumを利用したこともあるが、属人化やリソース不足により、メンテナンスができていない状態にあった。そこで、ローコストで簡便にテストの自動化が行える「T-DASH」を導入することになった。

T-DASHは、主にリグレッションテストで利用した。具体的なテスト観点は、画面やテキストの遷移や表示、文字入力、基本的な操作実行時の影響などである。田中氏は、まずT-DASHを導入したことによる成果や気づきを紹介した。

T-DASHでは、日本語で記述したテストケースが、そのままスクリプトとなる。そのため、プログラミングスキルが低い人でも、テスト自動化に必要なスクリプトを簡単に書くことができ、導入難易度は高くない。

また、コードがシンプルなため理解しやすく、メンテナンスコストが抑えられるという効果も期待される。

「実際、今回のプロジェクトでも途中でメンバーが入れ替わりましたが、特に問題なく引き継ぎが行われていました」（田中氏）

スクリプトの実装においては、最初から完璧なものを作り込むのではなく、まずは基本的な箇所から始める。そして、各機能におけるテスト自動化との相性を見極めながら、段階的に進めていく。

T-DASHの特徴を活かした配慮により、同プロジェクトではテスト自動化による効果が確認された。スピード面では、手動テストと比較して約12％の時間でテストを実施。手動テストでは見落としていたデグレも発見することができた。

T-DASHを導入したことによるメリットを、田中氏は次のように話した。

「一度作ってしまえば、あとはボタン一つで何度も実行できます。手動の場合はExcelなどに記録を残す必要がありますが、T-DASHであれば実行ログが残るため、手間が省けます。スクリプトの実行中は、他の業務に時間を充てることも可能です」（田中氏）

一方で、思ったように進まなかった点もあった。利用に際しての情報量である。同プロジェクトがT-DASHを導入した時期がT-DASHのリリース直後であったため、社内のナレッジが乏しく、課題解決に時間を要したからだ。

このような経験から、「自動化ツールを選定する時は機能面だけでなく、困ったときに頼れる情報の豊富さも重要な要素です」と、田中氏は強調した。

続いての気づきは、Webサービスの「お気に入り追加」テストに関する機能だ。2回目以降のテストでは、すでにお気に入りが追加されているため、そのまま前回のスクリプトでテストを行うと、エラーになってしまう。そこで初期の状態に戻す必要があるのだ。

テスト期間が数年に渡る場合は、テストデータの利用期限が切れてしまい、使えなくなってしまうことがある。そのため、期限はデータの作成時に（2099/12/31）などと長めに設定しておく。

また、手動テストの影響を受けないよう、チーム内で情報を共有しておく。データの末尾に「_自動化」と記載しているデータには触れないなど、運用ルールを定めておくことも重要である。さらに、テスト自動化は万能でないことを理解しておく必要がある。

「複雑な前提条件があるテストにおいては、拡張機能などを工夫すれば自動化は実現できます。ただし、コストがどれくらいかかるのか。運用コストとトレードオフの関係にあることを理解しておく必要があります」（田中氏）

田中氏はプロジェクトでの実導入を通じ、どのツールを使用するのか、どこまでのテストを自動化するのかについて、「ツールの特徴、プロジェクトやプロダクトの特性を整理した上で判断するといい」という見解を示すとともに、指標となる表も提示した。

「テスト自動化の波は確実に来ており、今後さらに需要が増すことは間違いありません。エンジニアは関連する新しいテクノロジーに日々アンテナを張り、波にいつでも乗れるように、しっかりと準備しておくことが重要だと考えています」（田中氏）

テスト自動化の浸透、成功のポイントは「人材育成」

バルテス株式会社
エンタープライズ品質サービス第2事業部
西日本ソリューション部　リーダー　田中 慶之氏

続いては、バルテスでテストエンジニア・PLとして各種テストプロジェクトに従事している田中慶之氏（以下、田中（慶）氏）が登壇した。クライアントワークに加え、テスト自動化を社内で推進するために、ワーキンググループ（以下、WG）活動といった社内業務にも従事している。

田中（慶）氏は「テスト自動化のリテラシー向上・後進育成への取り組み」をテーマに、WGでの活動について紹介を行った。セッションで伝えたいことは大きく3つあると語り、次のスライドを示した。

「テスト自動化の浸透はツールだけでは難しく、人材育成が重要です。つまり、テスト自動化で重要なのは“人”だということです」（田中（慶）氏）

バルテスでは「T-DASH」以外に、テスト管理ツール「QualityTracker」やクラウド型モバイルテストサービス「AnyTest」など、テスト自動化関連の自社ツールも開発している。

今後テスト自動化が浸透していく一方で、会社としてはこのような姿勢を明確に示しているものの、現場では実際に利用や浸透が思ったように進まないという課題があった。

「新しいものを導入するのが面倒」「そもそも使うような機会がない」という理由から、利用が進まないことでノウハウが蓄積されない。そして、利用者も増えない。このような悪循環に陥っていた。そのような状態を改善すべく、WGが形成されることになったのだ。

WGの活動目的は主に4つある。まずは、テスト自動化ツールの基礎知識の習得だ。得た知識を蓄積し、他の社員が見ることができる環境も構築する。閲覧してもらう際には実際のプロジェクトでのユースケースを紹介するなど、「利用者が理解しやすく、使いやすい環境を構築したい」と、田中（慶）氏は語っている。

さらにTeamsを活用し、整備した環境では理解できないことや、解決しなかった問いなどを相談・解決するための窓口も設置。窓口はバルテス内だけでなく、クライアントのプロジェクトで実施した際の意見も多く集まっている。

そして今後は、これらの活動で得た声や気づきを開発チームにフィードバックすることで、ツールをより良いものにブラッシュアップしていく。

現在のWGメンバーはT-DASH、QualityTrackerの2チームから構成されており、総勢7名。週に一度、各チームが隔週でテーマを持ち寄り、ディスカッションを行っているという。

田中（慶）氏はWGでの活動を通じて改めて得た成果や相乗効果について、それぞれ紹介を行った。

まずは、若手社員の育成である。WGのメンバーの半数以上は、プログラミング未経験のメンバーも参画しており、QAエンジニアとしてだけでなく自動化エンジニアとしての経験も積むことができた。

またファシリテーション能力や、問題解決能力も育むことが出来たと成果を述べ、「メンバーは固定せずに、ローテーションすることも考えている」と、思いを語った。

2つ目の相乗効果は、WGを通じて開発チームに相談できる環境が整い、実際に判断が難しかった案件の課題が解決したことである。また、頻繁に使われるカスタム機能があることを開発チームに伝えることで、標準機能に昇華した。

「WGのおかげで、ツール開発チームとテストエンジニアの関係性が活性化されました。利用者やノウハウが増加するなどの相乗効果を生み、結果として人や組織の成長につながっています」（田中（慶）氏）

【Q＆A】参加者からの質問に登壇者が回答

Q&Aコーナーでは、ソフトウェアテスト業界の第一人者である石原一宏氏がQ&Aモデレーターとして加わり、イベント参加者からの質問に回答した。

バルテス株式会社
テスト・アライアンス事業部　事業部長　石原 一宏氏

Q．改めて、テスト自動化導入に向けての注意点を知りたい

工藤：人の手が必要な箇所の自動化はツールでも可能ですが、メンテナンスが大変なため、結果として使わなくなるケースが多いです。人の介入が大きい部分は、手動テスト前提で進めた方がいいでしょう。

田中（駿）：自動化に向けて複雑過ぎる箇所もメンテナンスコストが大きくなるため、判断が必要です。適切なところから着実に進めましょう。

石原：単独でエンジニアが孤軍奮闘するのではなく、社内外含めて、いかにサポートしていくかが重要だと思います。

田中（慶）：まさに現在、現場の声を集めており、将来的には導入のサポートまで担えればと考えています。

Q．テストデータの作成について、状態を実行前に戻せないケースもあるのではないか？

田中（駿）：テストデータは事前に投入しておき、スクリプトの中で使用する流れです。仮に実行前の状態に戻せない性質のデータがあった場合は、回避方法をメンバーと模索するアプローチをとりますが、個人的にはテスト対象から外した方がいいと思います。

工藤：テストデータの準備においてはフロント画面、UI上でテストデータを作成できるかどうかを見ています。可能であればテストとは別に、データを登録する操作を作ることが多いです。できない場合は、PythonでAPIを叩きDBにつなぎます。ただ後者の場合はプログラミングが必要になり、メンテナンスコストも発生するため、自動化には不向きです。

Q．テストの自動化を入念に準備していたが、仕様変更により、大幅に修正する必要に迫られたことがあった。テストコードの共通化も含め、アドバイスが聞きたい

田中（駿）：テストコードを作る場合は、肥大化も含め、しっかり精査してむやみに作らないことがポイントです。作った後も棚卸しを行い、見直しを実施しましょう。肥大化を防ぐには、マニアックなデータパターンなどは使わずスリム化を図るという方法もあります。

工藤：自動テストの項目の整理をすることが大事です。整理のポイントは、自動化は繰り返し使うこと。外からの要因で失敗するようなリスクは極力省きます。現在、自動テストを行っているのであれば、改めて最低限の機能を見直すことで、余計な手間の減少につながると思います。

Q．自動テストの管理について。QA部門が行うのか、それとも開発部門が担当するのか

田中（慶）：必ずしも開発者である必要はないと思います。開発の知識がなくても、日本語でテストコードは書けるからです。

田中（駿）：私もプロジェクトのポリシーとして問題がなければ、QA担当でいいと思います。開発者は先入観を持っていることが多いので、テストで気づけないこともあるからです。バルテスが第三者、QA部門としてテストを行っているのもそのような背景からです。

石原：いずれにせよ大切なことは1人しか担当できないような、業務が属人化している状況では、自動化はうまく進みません。多くのステークホルダーが自動テストの管理を行える仕組みや体制作りが大事だと思います。

Q．テスト結果はどのようなフォーマットに出力できるのか

田中（駿）：T-DASHのテスト結果は、Webブラウザ上で見ることもできますし、Excelにエクスポートすることもできます。

石原：T-DASHは基本的な設計思想として、通常使っている環境と相互乗り入れできるように開発しています。詳しくはT-DASHの専用ページに記載しています。

※参考：https://service.valtes.co.jp/t-dash/

Q．WGでT-DASHを利用している案件例は？

田中（慶）：あるWebアプリケーションにおいて、大容量のデータを人が40分ほどかけて入力する業務があったのですが、さすがに辛くて自動化を検討。T-DASHを導入し、入力の確認を人が行うという業務にシフトしました。

バルテス株式会社
https://www.valtes.co.jp

バルテス株式会社の採用情報
https://recruit.valtes.co.jp