テスト自動化成功の大きな鍵「テスト自動化アーキテクチャ」
テスト自動化アーキテクチャはその名の通り、テスト自動化の仕組みを構築するためのアーキテクチャを意味し、テスト自動化が成功するか失敗するかの大きな鍵と言われている。
本セッションは、mablのQuality Advocateを務め、TestingやQAの啓蒙活動に取り組むおだしょーこと小田祥平氏のファシリテーションのもと、カカクコムのQAエンジニアとしてチームの立ち上げや複数の開発チーム支援を担当する伊藤由貴氏による解説が行われた。
テスト自動化アーキテクチャは、具体的な構成を決める「汎用テスト自動化アーキテクチャ（gTAA）」、実際に動く仕組みとなる「テスト自動化アーキテクチャ（TAA）」、それを実装した「テスト自動化ソリューション（TAS）」の3つのステップにおけるアーキテクチャで構成される。
まずは、それぞれのアーキテクチャについて簡単に説明していきたい。
汎用テスト自動化アーキテクチャ（gTAA）とは
汎用テスト自動化アーキテクチャ（generic Test Automation Architecture）は、テスト自動化ソリューションで最終的に作りたい仕組みであり、その汎用的な元となる全体概要となる。個別に考えるものではなく、すでにあるテンプレートやフレームだというふうに捉えるといいだろう。
以下スライドのように、主に「テスト生成レイヤー」「テスト定義レイヤー」「テスト実行レイヤー」「テスト適合レイヤー」の4つの層で構成されている。
「例えば、テスト適合レイヤーを作る場合、GUIを操作するテストを自動化したいのか、それともAPI、サービス、プロトコル、データベースなのかをこの図を元に考えていきます」（伊藤）
テスト自動化アーキテクチャ（TAA）とは
テスト自動化アーキテクチャ（Test Automation Architecture）は、gTAAを元に各要素を自分たちが実現したいものを具体化していくアーキテクチャだ。適切なアーキテクチャをつくるために、さまざまな検討ポイントがある。例えば、以下の3つが挙げられる。
- どの段階の、どの内容のテストをサポートするか
- どんな役割の方が用いるのか
- テスト対象のどんな技術要素をサポートすべきか
「例えば、そのテスト対象のアプリケーションがどんな言語で作られているか、どんなフレームワークで作られているのかによって、テストの仕組みを検討する対応が必要となります」（伊藤）
テスト自動化ソリューション（TAS）とは
TAAで検討したポイントを具体化して実装し、最終的に出来上がったものが、テスト自動化ソリューション（Test Automation Solution）である。テストハーネスやテストライブラリなどの成果物も含まれる。
「こうした汎用テスト自動化アーキテクチャから3段階のステップを経て、実際に動く仕組みを作っていくのが、テスト自動化アーキテクチャにまつわる考え方になります」（伊藤）
このように、テスト自動化アーキテクチャを考えることによって得られるメリットとしては、大きく2つが挙げられる。
1つは「考慮漏れを防止する」こと。特に、テスト自動化の仕組みづくりが初めてや経験が浅い場合は、必要な要素や考えるべき要素が漏れたりすることが多いが、gTAAの図をもとに考えていくことで、それが起きにくくなるメリットがある。
もう1つは「テスト自動化ソリューションが構造化される」ことだ。アーキテクチャなしで考えていくと、密結合なものが出来上がりがちだが、きちんと適切に構造化されて出来上がるメリットがある。
gTAAをもとにテスト自動化ソリューションを作る2つの例
gTAAをもとに、ツールを使ってテスト自動化ソリューションを作るパターンの代表例が2つ紹介された。
1つ目は、Webブラウザのシステムテストを自動化する際によく使われる「Selenium」というライブラリを使って自動化するアーキテクチャだ。Seleniumで自動化する際は、その上のテスト実行レイヤーやテスト定義リーダーを用意して、テスト生成レイヤーを自動化する。
Seleniumは以下スライドのオレンジで囲まれた部分をカバーして自動化するのが、ライブラリの特徴である。
もう1つは、E2EのテストやAPIテストなどさまざまな種類のテストが自動化できるプラットフォーム「mabl」だ。
mablがカバーする範囲は以下スライドが示すように、テスト定義レイヤーからテスト実行レイヤー、テスト適合レイヤーのオレンジ色に囲った部分であるGUIやAPI、サービス辺りがmablの担っている範囲となる。
mablを使って自動化しようと思ったときは、もちろん他のツールで補完が必要な場合もあるが、ほぼカバーすることができる。
こうして比較すると、mablの方がカバー範囲は広く、利便性が高いと思われがちだが、それぞれメリット・デメリットがあるので、システムのニーズや目的に合わせて考える必要があると、伊藤氏は指摘する。
さまざまなライブラリを組み合わせるSeleniumのようなツールと、単一のツールで広くカバーするmablのようなツールでは、それぞれ特徴やカバー範囲、テストする担当者のロールなど、それぞれ適切なアーキテクチャは異なる。
例えば、Seleniumのように部分的にいろいろなライブラリを組み合わせることが可能なツールであれば、自分たちの裁量でニーズに応じた柔軟な構成が可能となる。従って、例えばデベロッパーがテスト自動化の仕組みを作って直接実行する場合や、SREやSET（Software Engineer in Test）といったテスト自動化に関連するスキルを持つ担当者が柔軟に構築する場合に適している。
一方、mablのように広い範囲をカバーしてくれるツールを用いることで、自動テストの設計・実装がスピーディーに行うことができる。自前でいろいろ考えなくていいという大きなメリットがあるので、例えばQAが仕組みの構築よりも自動テストの方に注力したい場合、こうしたツールの方が向いていると言えるだろう。
「どっちがいいという単一的な話ではないので、組織の状況や体制などに応じて選んでいただくことが重要だと思います」（伊藤）
テスト自動化は、単なるツール導入ではなく仕組み構築
最後のまとめで伊藤氏は、一番伝えたかったポイントとして、「テスト自動化をしようと思った場合は単一のツールの導入じゃなくて、仕組みの構築である」ことを挙げた。
システムテスト自動化の仕組みを構築する際は、テスト自動化アーキテクチャを理解して設計することが必要となる。その際の考え方として、伊藤氏は以下のようにまとめ、セッションを締めた。
「テスト自動化の仕組みを作っていく上で、一つのプラットフォームで広くカバーしていくのか、それともツールやライブラリと組み合わせて柔軟に作り上げるのかは、ざっくり2つのパターンがありますが、どちらがいいのかに正解はないので、チーム状況に応じた判断をして、考えていきましょう」（伊藤）
また、汎用テスト自動化アーキテクチャ、テスト自動化アーキテクチャ、テスト自動化ソリューションの考え方は、「テスト技術者資格制度 Advanced Level シラバス テスト自動化エンジニア」に詳しく掲載されているそうなので、興味のある人はチェックしてみよう。
