イベント・ニュース
-
2025/08/12
7月25日「T-DASHテスト自動化セミナーT-DASHハンズオンセミナー～Webアプリを実際にテスト自動化してみようvol.8～」の質疑に関して
7月25日に開催しました、「T-DASHテスト自動化セミナーT-DASHハンズオンセミナー～Webアプリを実際にテスト自動化してみようvol.8～」にて、セミナー中やアンケートにて多くのご質問や課題を頂戴いたしました。
時間の都合上、セミナー中に皆さまのご質問にお答えできなかったこともあり、ご参加いただきました皆さまから頂戴したご質問・課題について、回答として掲載いたします。
ぜひ、ご参考にご覧ください。
Q&A
Q1：機能についてのリクエストになるが、データドリブンの箇所について、手入力するのは手間が大きいのでcsvファイル等で変数部分を設定できるようになれば大分手間が減ると思う。
機能に関するリクエストありがとうございます。
イメージいただいている機能と同一であるかは分かりませんが、データドリブンのデータについてはT-DASH内のスプレッドシートに対する手入力の他、excelやcsvといったファイルからのインポートにも対応しております。詳細については以下チュートリアルをご確認ください。
Q2：現在Salesforce上での画面開発を行っており、サンプルで作成した画面での入力テストをT-DASHにて作成をしてみました。
その際、画面キャプチャツールで画面定義を行った項目がテスト実行時に見つからずエラーとなり確認したところ、XPATHに以下のような違いがありました。
-----------------------------
・画面キャプチャツールで取得したXPATH：//*[@id="brandBand_2"]/div/div/div[2]/div/app_flexipage （以下略）
・テスト実行で起動した画面で取得したXPATH：//*[@id="brandBand_2"]/div/div/div/div/app_flexipage（以下略）
-----------------------------
「div[2]」という部分がテスト実行時には「div」になっておりました。
該当の要素はSalesforceのコンポーネントを使っておりタグが自動で作成されるため、実行時に上記のような違いが出てしまうのではと予想しているのですが、こういった場合はテスト実行で起動した画面から取得したXPATHで保存しておくしか無いのでしょうか。
Salesforceサービスの画面は、IDの割り振りがランダムであったり表示項目数が異なることによりHTMLの階層構造が変わったりと、ケース作成時と実行時で画面定義が異なることによりテスト実行に失敗することがあります。
XPathの書き方を条件マッチするものにすることにより画面によっては対応できる可能性はあります。XPathの表記方法見直しで対応できない場合は、要素画像を用いた動作も準備しておりますので、こちらのご利用をご検討ください。
Q3：複数のテストシナリオを同時並行に実行する事はできますか？（マルチスレッド的なイメージ）
テストの同時並列実行については非対応となります。
並列実行については複数ご要望をいただいているため、将来的なアップデートで対応できないか検討中です。
Q4：業務アプリなので、DBに登録した結果のテーブルのダンプを取得したいのですが、そういった作業の自動化は可能ですか？
「カスタム動作機能」を用いると、Robot Frameworkの各種ライブラリやPythonの各種pipパッケージを使用した処理が行えます。
これらを活用していただくことでテスト内でダンプの取得まで実現できるかと思います。
Q5：テストを行いたいシナリオ毎にシステムが用意するデータを変える必要がある場合、それぞれのデータをあらかじめ用意してテストを流すことになりますか？
一般的に、テストに必要なデータをセットしたDBをテスト専用環境として維持するものでしょうか？
あらかじめデータを準備いただいた上でテストを実行する形となります。
T-DASHはテストケース・テストスイート・テストランの単位でデータドリブンとして繰り返し実行用のテストデータを保持できるようになっております。
データドリブンのデータ設定はT-DASH内で入力できるほか、ExcelやCSVファイルから取り込みも行えるようになっております。
Q6：業務アプリとして本日日付と締め設定を比較して画面の動作を変更する機能があります。例）締めを超過すると画面の入力・編集が出来なくなる。
このようなテストを行うときに用意するデータは、納品日が昨日のデータ、納品日が今日のデータです。
納品日が昨日のデータは締め超過の為修正できないというテストを行いたいのですが、この昨日のデータと今日のデータは、あらかじめDBに登録して読み込む流れです。
本日テストをする時と、１０日後に再テストをする時の、「昨日」と「今日」は当然変わります。
このような場合、テスト自動処理を流す前に適切なデータを用意（加工）する必要があると考えます。
一般的にこのような場合、「テスト自動化」の前段階として「テストデータの自動作成」など行うものでしょうか？あらかじめ用意していたデータを「単純に維持」するだけでは、再テスト時に適切な判定が出来なくなると考えています。一般的な方法論をご教授ください。
テストを行いたい状況になるように前準備としてテストデータを整えることは、テスト自動化でも必要なアプローチです。
テスト実行環境自体のデータを準備するためにDB接続を行う場合、「カスタム動作機能」を用いて実現することになるかと思います。
「今日の日付 - 1日」や「今日の日付」を特定のDBカラムにUPDATEするようなカスタム動作を作成し、テスト実行前のテストケースに組み込むと常にテストを行いたいデータ状態で自動化を行うことが可能となります。
Q7：データを検索して画面に表示する機能について、「山田一郎」が表示される、という確認をハンズオンで教えてもらいましたが、逆に「山田一郎」が表示されない、という確認は可能ですか？
何らかの条件を指定してデータを検索すると明細が表示されるような画面で、条件指定により「○○」が表示されない、という確認を行いたい場合を想定しています。
「テキストが一致するか検証する」の対として「テキストが一致しないか検証する」手順をご準備しております。
「テキストが一致しないか検証する」手順をお使いいただくことで確認可能です。
Q8：テストの自動化を行ったときに何らかの理由で想定通りに動作しなかった場合、「バグあり」と判断されると思います。
この時、特別な記録を行ったり（テキストファイルをオリジナルフォーマットで出力する等）、警告メールを飛ばしたりすることは可能ですか？
自動処理を行ったときにSEが張り付いてみておくことをやりたくないと考えていて、流して離席し、後程結果を確認したい、という事を期待しています。
T-DASH標準として外部連携通知は対応しておりませんが、こちらも前述の「カスタム動作機能」で実現できる可能性があります。
テストケースの実行結果をトリガーとして、テストケースが失敗した場合にTeamsへ通知する手順については実績がございます。
参考
・[T-DASH] テストが失敗したら、teamsやslackに通知させる
Q9：Q8に関連して、複数のシナリオテストを実行指示して、後程結果を確認したいです。
その為、途中でエラーが起きても判定可能な記録を残し、どんどん次のシナリオテストに進んでほしいのですが、可能ですか？
T-DASHではテストケース内のいずれかの手順で失敗した場合、その時点でケースを終了して次のケースを実行するようになっております。
ケースの組み方によってはお客様のご希望を叶えられるかと思います。（テストケース内でエラーが発生した場合でも続行については非対応）
Q10：テストの途中でDBの設定値を書き換える事で画面の動作モードを変更し、Aモードの正常終了、Bモードの正常終了を確認するといったテストを行いたいです。
このモードはシステム内でユニークに設定できるものなので、１つのテスト環境に複数用意する事が出来ません。テスト実行のたびにSEが手動で切り替えるものです。
こういったテストの自動化、つまりAモードをBモードに書き換える処理（例えば、DB内のあるテーブルのある値を更新する、テキストの設定ファイルを書き換える）等の操作はT-DASHで可能ですか？
こちらについても「カスタム動作機能」でDB接続を行い、指定のカラムを変更するクエリを実行するようにすると実現可能かと思います。
弊社社員がT-DASH からクエリ実行する手順について記事を公開しておりますので、参考になされてください。
Q11：他にも質問したいことが後日発生した時、回答をいただく事は可能ですか？
回答可能です。基本的に3営業日内で回答を行っております。
1営業日内の回答やカスタム動作の作成をご希望の場合は「プレミアムサポート」サービスもご準備しておりますので、ご検討いただけますと幸いです。
Q12：テストスイートとテストランの名称について最大文字数が30文字なのはなぜか？
例えばテストスイートには『「X」というシステムの「A」という機能(画面)の「B」というドロップダウンコンポーネントの内容を確認する』というような意味を持たせようとするとどうしても30文字じゃ表現しづらくなります。
テストランも同様で、『「X」というシステムの「A」という機能(画面)の初期表示に関する検査』などの意味を持たせたい場合も30文字では限界がありそうで困っています。
テストスイートやテストランの扱い方に関する定義が御社の想定と大きくずれているのか、気になっています。
貴重な意見ありがとうございます。今後の開発に活かさせていただきます。
現在の文字数制限は、T-DASHのデータの持ち方になるのですが、複数台でプロジェクトを共有する場合にT-DASHデータをファイル名として出力します。
この際に、Windowsの場合フォルダの制約、256文字のファイルパス制限にかかるため、制限させていただいております。
Q13：検査意図とT-DASHに表記される文字列の乖離について
例えば、ある画面の初期表示時の各種コンポーネントの状態を確認するテストスイートを作成した場合、テストケースとしてはボタンA(テキストB,チェックボックスC etc...)の表示/非表示、ラベル文字列や、活性/非活性などを確認するテストケースが沢山用意されるかと思います。
このうち表示/非表示や活性/非活性などはコンポーネントに設定されたスタイルを確認する事になると思っています。
そうすると、テストケースにはクラスのこのパラメーターが有るか無いかとか、そういうテストになり、作ったテストケースが意図である「活性/非活性チェック」なのかどうか、作った時は覚えていても、再利用したり他人が読んだ場合など、分かりにくい状態になる気がしています。
こういったギャップを解決する方法はありますでしょうか？
まだ動作未確認ですが、動作セットでボタンの活性/非活性を検証する・・・というようなものが出来ればと思っていますが、あまり動作セットだらけにしたくもないし、設定値が3つ超えそうだと不安があります。
活性/非活性/非表示など、アプリケーションによって違います。
そのため、T-DASHの要素が表示されているか・または表示されていないかを検証する動作では厳密に検証できないかもしれません。
このようにより厳密に行いたい場合は、スタイルをチェックするカスタム動作を作成していただくことになります。
T-DASHで定期的にリグレッションテストを行うことで意図とちがう実装となっている際はエラーとして検知できます。
作った際の動作をチームメンバーで共有するために別のドキュメントなどで管理してみてはいかがでしょうか。
Q14：ブラウザをゲストモードやシークレットモードで起動してT-DASHでテストしたいのですが、やり方はございますか？
テスト対象サイトをゲストモードやシークレットモードで起動することはカスタム動作を用いることで可能となります。
弊社社員がカスタム動作を作成して実現する方法をご紹介しておりますので、活用いただく際は参考になされてください。
参考
・[T-DASH] シークレットモードでWEBのテスト自動化をする
Q15：ハンズオン形式で体験することが出来て、操作性が肌で感じられたので良かったです。想像していたより簡単でした。（デモサイトだからという面があるかもしれませんが）
アップロードだけでどこまで出来るのか、追って試そうと思いました。
ハンズオンを通してT-DASHを活用したテスト自動化についてご理解いただけたようで良かったです。1ヶ月の無料トライアル期間を設けておりますので、お客様環境での導入をご検討いただけますと幸いです。
T-DASHでは、T-DASH公式サイトにて様々な使い方を紹介するチュートリアルや機能についてのFAQがございます。また、ご利用に関するご不明点はT-DASHサポートまでお気軽にご相談ください。
引き続き、T-DASHをよろしくお願いいたします。
セミナーに関する情報は、>>ウェビナーやイベント情報 からご確認いただけます。
Share
