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が仕組みの構築よりも自動テストの方に注力したい場合、こうしたツールの方が向いていると言えるだろう。
「どっちがいいという単一的な話ではないので、組織の状況や体制などに応じて選んでいただくことが重要だと思います」（伊藤）
