はじめに
チュートリアルや公開されている自動テスト用のページでは、使用するツールの標準機能が十分に機能することが確認できます。
しかし、これらが実際に自動化したいシステムで同じように機能するかを、確かめる必要があります。
基本的な使い方はT-DASH公式サイトのチュートリアルにあるので割愛して、
実際に私がT-DASHツールを導入するかどうかを判断する内容について、また社内への導入にあたり確認したポイントについて解説したいと思います。
これみれば、T-DASH基本的な使い方がわかります。
94dangoさんが投稿された1年前の記事です。綺麗に丁寧にまとめられている記事です。現在と違う部分もありますがまずはこれを見ると良いとおもいます。
テスト自動化ツールの導入の参考になれば幸いです。
個人的な見解で書いておりますので、偏りや誤りががある可能性があります。ご容赦ください。
テスト自動化したいシステムのUIコンポーネントが操作できるか
テスト自動化を行いたいシステムにおけるUIコンポーネントのリストを作成しました。
各UIコンポーネントが自動テストツールでの操作やチェックに適しているかどうかを慎重に確認する必要があります。
チェックした内容の一例です。
- 各UIコンポーネントを正確に識別できるか
- クリック、入力、選択などのコンポーネントを操作できるか
- コンポーネントが画面上に適切に表示され、ツールがアクセス状態にあるか
- ボタンの有効・無効状態やインジケーターの表示・非表示などツールで状態変化を認識できるか
- 異なるブラウザでコンポーネントが一貫して動作するか
自動テストツールのUIコンポーネント動作チェックリスト
T-DASHツールで「できる・できない」をチェックしました。
UIコンポーネント | 確認する内容 | T-DASHツール結果 |
---|---|---|
テキスト | 表示している文字列の値を使ってチェックできるか | できる |
入力 | テキストボックスに文字を入力できるか | できる |
シングルセレクト | ドロップダウンのアイテムを選べるか ドロップダウンで選んでいるアイテムをチェックできるか |
一応できる |
チェックボックス | チェックボックスのON・OFFできるか チェックボックスのON・OFFの状態をチェックできるか |
できる |
ラジオボタン | ラジオボタンをONできるか ラジオボタンのON・OFFの状態をチェックできるか |
できる |
ボタン | ボタンを押下できるか | カスタム動作の作成で対応 |
タブ | タブボタンを押下できるか | できる |
スプレッドシート | セルに値を入力できるか セルの値を取得できるか |
カスタム動作の作成で対応 |
グラフ | グラフの値を読み取りできるか マウスオーバーで情報表示できるか |
難しい カスタム動作の作成で対応 |
ファイル | ダウンロードしファイルの内容をチェックできるか ファイルを指定してアップロードできるか |
カスタム動作の作成で対応 |
- UIコンポーネントの操作やチェックについて、カスタム動作をつくらないとテストができない。
- グラフに関しては、スクリーンショットをとって目視確認とし、自動するテストの対象としては見送りにすると思います。
私の場合は、社内導入を進めるうえで、はずせない条件として「Playwrightを使用する」であるため、チェックするすべての操作においてカスタム動作で実装しました。
というのもあり、UIコンポーネント操作において、「できない」は殆どなく、あとはどこまで「作る」か次第でした。
自動テストツールに求める主要機能は搭載されているか
テスト自動化ツールの主要機能についてリスト化しました。
これらの機能がツールに搭載されているか、利用可能か、そして使いやすいかどうかを慎重にチェックすることが重要です。
テスト自動化する対象システム次第で過不足があるかと思いますので、必要に応じて増減すると良いと思います。
自動テストツールの主要機能チェックリスト
機能 | 使用する想定 | T-DASHツール結果 |
---|---|---|
記録・再生機能 | ユーザーのアクションを記録し、それを自動的に再生する機能。これにより、プログラミング知識がなくても、簡単にテストケースを作成できる。 | ない 操作の記録はできない |
クロスブラウザ・クロスプラットフォーム対応 | 異なるブラウザーやオペレーティングシステムでテストを実行できる機能。これにより、アプリケーションの互換性を広範囲にわたって検証できる。 | 一応できる Windows、Macをサポート |
CI/CD | CI/CDパイプラインとの連携機能。これにより、コードの変更があるたびに自動的にテストを実行し、開発プロセスを効率化できる。 | 一応できる |
パラメータ化とデータ駆動テスト | テストデータを外部から供給し、同じテストケースを異なるデータセットで実行できる機能。これにより、テストの柔軟性が高まる。 | できる |
レポートとログの生成 | 詳細なテスト結果のレポートとログを生成する機能。これにより、テストの実行状況を把握し、問題の診断が容易になる。 | できる |
オブジェクト識別と管理 | テスト対象のアプリケーション内の要素(ボタン、フォーム、テキストフィールドなど)を正確に識別し、管理する機能。これにより、テストの信頼性とメンテナンス性が向上する。 | できる |
カスタムスクリプトと拡張性 | ユーザーがカスタムスクリプトを書いて、テストのカスタマイズや拡張が可能な機能。これにより、特定のテスト要件に合わせて柔軟に対応できる。 | とてもできる |
テスト前準備 | テスト前に必ず実行される処理。 テストケースごとに必要な前提条件やフィクスチャを設定する機能。 |
できない |
テスト後処理 | テスト後に成功・失敗に関わらず必ず実行される処理。 テスト完了後に使用したリソースを解放し、後処理を行う機能。 |
できない |
多言語サポート | 複数のプログラミング言語でのテストスクリプト作成をサポートする機能。 | ない Python、robotframeworkのみ |
環境構成 | テスト実行に必要な環境変数や設定を構成する機能。 | 一応できる カスタム動作の作成で対応 |
データベースの初期化 | テストの実行前にデータベースを特定の状態に戻す機能。 | 一応できる カスタム動作の作成で対応 |
依存サービスの起動 | テストの実行に必要な外部サービスやバックグラウンドプロセスを起動する機能。 | 一応できる カスタム動作の作成で対応 |
私の場合は、カスタム動作が大前提ですのでほとんどは「できる」の判断となります。
学習コストは低いか
ここまでは、社内のニーズや要件に対してT-DASHがどの程度適しているかのチェックについて書いてきました。
ここからは、社内の様々なスキルレベルのメンバーにも使いやすいかについて書いていきます。
- テスト自動化を推進できる人を増やしたい。
- 勉強会はしたくない。使えるようになる人が勝手に増えると嬉しい。
T-DASHの標準的な使用方法については、チュートリアルやマニュアルに従うことで、その機能が十分に発揮されることを確認しました。
さらに、社内で広く活用するために、実際にツールを使用して、その適用範囲とメンバーの適応能力を評価するテストを行いました。
準備したもの
使い方の簡単なフローチャートを書きました。公式サイトにも十分な使い方チャートはあるのですが、標準的な使用方法が主であることと、充実しているがゆえに数が多く何からどう見ていけばいいかが初見では判断できないと思ったためです。
T-DASHでテスト自動化を構築する基本の流れは以下だと思います。
- テストケースの作成
- 画面定義の作成
- デバッグ機能で動作確認
1. テストケースの作成
「いいえ」のルートに、躓きポイントが潜んでいました。
① 自分で自動化するの「いいえ」
細かい手順や暗黙値など手順に書くのが非常に面倒です。
すべて手順に書くことが正しい、書いていないとテスト結果の正確性が乏しくなるとは理解しているものの全手順を起こすのは骨が折れました。
後で気づいたのですが、チュートリアルを眺めていたら「共通モジュール化」の機能がありました。
ある程度の動作をひとまとめにした1つの動作を作ることができるようです。
(1)ログインページを開く
(2)メールアドレスに○○を入力する
(3)パスワードに△△を入力する
(4)ログインボタンをクリックする
上記4つの手順を、下の1つで表すことができます。
(1)○○と△△でログインする
これはこれで、別の設計は必要になりそうですが、全手順を書くよりはだいぶ楽になると思います。
- 公式サイト
動作セットを作成しよう
② ひとつめの動作はあるかの「いいえ」
代替動作の気づきにも経験が必要ということが理解できました。
チェックリストにもあるのですが、「テキストを入力する」ではなく「キーを入力する」でないと動作しないことに気づけないが殆どでした。
セレクトボックスやチェックボックスなどについても、「要素をクリックする」で実現できるのですが、「リストから選択」「チェックをONにする」などの動作があると気づかないものだなと思いました。
カスタム動作で対応するときはちゃんとヘルプを作らないとダメな事案でした。
③ ふたつめの動作はあるかの「いいえ」
これは動作を作るしかないので、動作が作れなければどうのしようもありません。
④ カスタム動作を作ることができるかの「いいえ」
自動化できないテストケースとなるので、ツール導入前にどういったパターンが自動化できないのかを抑えておかなければなりません。
2. 画面定義の作成
こちらも「いいえ」のルートに、躓きポイントが潜んでいました。
① ハイライトされたかの「いいえ」
特定の自動化対象のパスが取得できない場合、通常のアプローチでは「取得できなければ終了」となることが多いです。
② パスが適切かの「いいえ」
Xpathの書き方に依存する部分で、適切かどうかを判断するために知識が必要です。
例えば、//*[text()="hogehoge"]
なパスの場合、「hogehoge」が固定されて問題ないか、//*[@id="xxxxx01234"]
のような動的に生成されているような値が含まれる場合に問題ないかを、Xpathを見て判断しなければなりません。特に異なるスキルレベルを持つ人々によっては難しい課題となりえます。
③ とれたかの「いいえ」
自動化できない画面項目となるので、ツール導入前にどういったパターンが自動化できないのかを抑えておかなければなりません。
3.デバッグ機能で動作確認
公式サイトの テストケースのデバッグをしよう がわかりやすい。
実際に使っての気になる点としては、アドベントカレンダーの記事でも触れられていますが、同意見です。
総評
テスト自動化ツールの選定と社内展開に際して考慮すべき基準や、進行中に遭遇する可能性のある躓きポイントを自分なりにまとめました。社内でのツール導入と展開における障壁、例えば技術的な理解の不足、トレーニングとリソースの必要性、統合の問題点、組織内の抵抗など、まだまだ考えることはたくさんあります。
T-DASHテスト自動化ツールは、簡単で使いやすいとはいえ、実際にはいくつかの躓きポイントが存在します。しかし、過去に導入したツールやコードを書く作業と比較して、このツールの学習コストは格段に低いと感じられます。そのため、社内での普及を徐々に進めていく上で、大きな抵抗はなくスムーズに進行できると考えられます。
(1)良いと思った点
- 使いやすさ
- フローを渡して一度使って見せると標準機能は使えるようになります。
- 低価格
- テストチームの人数分準備しても、「えっ、こんなに安いの?」ってなります。
- マニュアルが豊富
- 公式ページのマニュアルをみれば、使い方がわからないということはありません。
(2)改善の余地ありと思った点
- キャプチャツールで生成するXpathが、どの属性を使うのか選べない
- デフォルトは今のままでも良い。
- それを編集したいときにどの属性を使うのか、組み合わせや編集がGUI上でできるようになると良い。
- IDやNAME属性、textの値を使いたくないとき、Devtool起動してチェックするので手間。
- 記録・再生機能がない
- 手っ取り早くひろめるときには、やはりあると便利。
- 記録するとテストの手順ができあがったら凄い!と思う。
- Setup、Teardown(前準備、後処理)がない
- 不安定な自動テストになる。
- 自動テストが終わった後に、テスト自動化の対象システムの状態を元に戻すのが面倒。
- カスタム動作の動作チェックが面倒
- カスタム動作⇔テストケースの行き来が面倒です。
おわりに
Qiitaアドベントカレンダー2023では、カスタム動作を活用する方法と、テスト自動化ツールの選定基準及び導入時の一般的な躓きポイントについて投稿しました。
このツールはわずか3,960円という手頃な価格で提供されており、その拡張性を考慮すると、テスト自動化におけるポテンシャルは非常に高いと感じます。多くの場合、必要な動作を実現できないことがテスト自動化ツールの導入の障壁になりがちですが、T-DASHの場合、このような問題は少ないと感じました。低コストで高い拡張性を持つこのツールは、テスト自動化の導入を検討している多くの企業やプロジェクトにとって、有力な選択肢となるではないかと思います。
私の見解では、ツールの標準機能だけでテストを完全に自動化するのは現実的ではないと感じています。ツールの拡張機能の有無やテスト対象システムの特性に応じて、多くの試行錯誤が伴う可能性があります。T-DASHは、これらの要求を満たすことができるツールの一つです。手頃な価格設定と容易な導入の可能性は、他のツールと比較しても際立っていると思います。
参考サイト
(1)公式サイト
このマニュアルをみるとほぼ使えるようになりました。
前回も思いましたが、必要なものを見つけることができればマニュアルは充実しています。
(2)基本的な使い方
基本的な使い方の解説がなされていました。動画もあってまさに一気通貫のチュートリアルです。
最初はこれをみると良いと思います。
無許可でリンクを貼っています。ご容赦ください。