はじめに
こんにちは、あるいはこんばんは。2025年度入社の江森です。
私は文学部の出身で、在学中はITとは縁遠い日々を過ごしていました。在学中最も使用したPCのソフト（ブラウザを除く）は「Word」です。これだけでなんとなく察しがつくと思います。
本記事では、このように絵にかいたようなIT未経験、文系エンジニアである私が業務で実際にT-DASHを使った体験を踏まえて、初めてT-DASHを使う時にすべき準備や工夫を共有します。
この記事が、私と同様にITのバックボーンが無いながらもこの業界に飛び込んだ人の助けに、少しでもなれば幸いです。
※T-DASHの用語の説明は一部割愛しますので、T-DASH公式チュートリアルと併せて読んでいただければと思います。
T-DASHについて
まず、今回取り扱うT-DASHについて簡単に紹介します。
T-DASHはバルテス株式会社が提供する、テストを自動化するローコードツールです。
T-DASHにはWebサイトを操作するうえで必要な基本的な動作（クリック、入力、選択など）があらかじめ搭載されており、それらを組み合わせてテスト実施の流れ（シナリオ）を作成します。
出来上がったシナリオに従ってT-DASHが自動的に一連の動作を行い、テストが実行されていきます。
基本的にノーコードで使用できますが、より複雑な動作が必要な場合は、Pythonによる「カスタム動作」を作成することで実現可能です。
コマンドなどは必要なく、テキストの入力、ドラッグ＆ドロップ、クリックのみですべての操作を完結させることができるため、IT未経験者でも比較的容易に使うことができます。
新米文系エンジニアが初めてT-DASHを使ってみた結果
部署の研修を終え、私が一番最初に行ったのがこのT-DASHを使用したITaの打鍵です。
初めてで不安を抱えながらも、T-DASHの優れた機能と操作しやすいUIのおかげで、未経験なのにサクサク打鍵を進め、インストラクターに褒められ、部内でも期待の新人として名を馳せる！
……ことはできませんでした。むしろ業務で使い始めてからしばらくは、予定の半分ほどのペースでしかケースを消化できていませんでした。
その原因は、自動化を効率的に進めるための準備ができておらずに発生した、無駄な手間や多くの手戻りでした。エラーと格闘しながら徐々に環境を整えて打鍵を進めた結果、ギリギリ期限に間に合わせることはできましたが、打鍵を終えた瞬間に、「あらかじめ準備できていれば…」
という思いが頭を駆け巡りました。
このもどかしさを供養するという意味も含めて、「ああしておけばよかった」「こうしておけばよかった」と感じたことについて書いていこうと思います。
それでは、順を追って説明していきます。
T-DASHによるテスト実施の流れ
T-DASHのチュートリアルによると、テスト実施の流れは大まかに以下の通りです。
①準備する→②テスト作成→③デバッグ→④テスト計画→⑤テスト実行→⑥テスト結果の確認
今回は上記のうち、②の「テスト作成」に注目していきます。
「テスト作成」における準備
前段として、T-DASHを使う上では欠かせない、「画面定義」について簡単に説明します。
T-DASHにおける「画面定義」とは、ざっくり言うと、画面内に「なに」があって、それが「どこに」あるかをT-DASHに登録する作業です。より具体的には、画面内の要素とXPathをT-DASHに登録することを意味します。
画面内の要素とは、入力フォームや「次へ」ボタンなど、画面を構成するパーツのことです。またXPathとは、これらの要素が画面の中でどこに位置しているかを特定できるパス、言うなれば要素までの道順のことです。
このXPathをT-DASHに登録することで、T-DASHが各要素（入力フォームやボタン）を見つけ、記入や押下などの動作を実行することができるようになるのです。
やっておけばよかった①：テストに必要な画面表示パターンを漏れなく洗い出し、各要素のパスを取得しておく
理由：画面が動的に変化する際、要素を指すパスが変化してしまうため
画面キャプチャを活用し、表示されているデフォルトの画面を定義すれば終わり…ではありません。
動的なサイトの場合、テキスト記入やクリック、計算などの動作・処理によって、同じ要素でも指定するパスが変化することがあります。
例えば、入力フォームに数字を入れ、「確定」ボタンを押し、最後に「合計」ボタンを押すことで合計値を出力して完了、という動作があるとします。このシステムが、数字を「確定」させなければ計算を実行しない、という仕様だったとき、パスのずれで「確定」ボタンが押せないことで、ゴールである「合計値」の出力ができなくなってしまいます。
この問題自体は、ずれたパスを必要な要素分だけ取得しなおすことで解消できます。ただ、「動的サイト」という発想すらなかった私は、エラーの原因としてパスのずれを見つけるのに非常に時間がかかりました。
なぜなら「ずれる前」の要素のパスは、デフォルトの状態であれば、画面定義としては「正しい」、もので、まさか要素のパスがほんの少しでも変わるなど微塵も思っていなかったからです。
デフォルトの画面のパスを取り直しては「あってるけどなぁ…」と首をひねる無駄な時間が、少なくない長さで発生していたのはなかなかにもったいなかったと、今振り返ってみても思います。
動的サイトであるからパスが変化することがある、ということを頭に入れておくことが有効ですが、そもそもそのような事象が発生しないに越したことはないです。
多数の要素のなかで、どの要素のパスがずれているかを特定するのには時間がかかりますし、パスを取得しなおすのも、積もれば大きな時間のロスになります。
このような時間や労力のロスを減らすために、あらかじめテストに必要な画面表示パターンを洗い出しておき、それぞれの画面表示から要素のパスを取得しておくとよいでしょう。
やっておけばよかった②：探しやすく、わかりやすい命名規則を決めておく
理由：シナリオ作成の手間とストレスを減らすため
画面の要素が両手で数えられるくらいであればよいですが、ものによってはかなりの数の要素を持っているものもあるでしょう。
要素が増えてくるとシナリオ作成の際に必要なものを探し出すのが非常に骨の折れる作業になります。
また、異なるページ間で共通の要素（「戻る」ボタンなどありがち）があるときは、今目の前にある要素がどのページの要素であるかの判別が難しくなります。
ここで業務の中で実際に行った工夫をいくつか紹介します。
- 検索しやすいように、一定の区分けごとに番号やアルファベットを振る
T-DASHには動作や要素を検索できる機能があります。そこで、ログイン画面は先頭にU01を振る、申込画面にはU02を振る…という風にしていくと、一種の絞り込みが実現できます。
ログイン画面のテストシナリオを書く際には、とりあえず01で検索すればログイン画面の要素が表示されるので、必要な要素をそこから選ぶだけで済みます。
ユーザー画面の要素にはU（User）を、管理者画面の要素にはA（administrator）を付けるなどするとよいかもしれませんね。
- 要素を登録する際に、タイプ（フォーム、ボタン...）まで書く
例えば、要素に「合計」と書かれていた時、シナリオ作成者はこの要素を何だと感じるでしょうか。 合計金額の表示？合計金額の入力フォーム？または合計金額の計算ボタン…？
ボタンに対してテキストの入力をしても仕方がないので、どの要素のことを指しているか確認する必要がでてきてしまいます。これもまた、積み重なると時間のロスになるのに加え、要素が出てくるたびに二つの画面を見比べてタイプを確認するのはストレスにもなります。
一方で、タイプまで書いたものがこちらです。
このように、要素のタイプが一目でわかることは大量の要素を組み合わせてシナリオを作る人の負担の軽減につながります。要素の種類を確認するため、いちいち画面を実際の画面や画面定義を見に行くといった手間とストレスを減らすことができるのです。
まとめ
テスト作成における準備
・テストに必要な画面を漏れなく洗い出し、必要な要素のパスを取得しておく
・探しやすく、わかりやすい命名規則を決めておく
本ブログで挙げた事柄は、T-DASHを使う上でのいわば基本の「き」であり、いずれも比較的容易にできることです。しかしテストの件数が増えれば増えるほど、その重要性が増していきます。それはこれまでにも述べた通り、打鍵の手前の余計な手間や手戻りを減らすものだからです。
もちろん、今回挙げたこと以外にも効率的に進めるための準備や工夫は数多くあるでしょう。今後使用回数を重ねていく上で見つけたものを一つずつ記録し実行することで、T-DASHを最大限に活かした、効率的な打鍵を実現していければと思います。
