【T-DASH】俺の会社はいまだに試験用スクリーンショットをエビデンスとしてExcelに貼り付けている


この記事はアドベントカレンダー「自動化できたらうれしいテスト、してみたいテスト by T-DASH Advent Calendar 2023」の20日目の記事になります。

https://qiita.com/advent-calendar/2023/t-dash03

# （朗報）さいきん会社で有給の電子申請ができるようになりました

弊社では今年（2023年）になって、有給届が紙からWebに移行しました。

**プリンターから2対1組で出てくる届をハサミで切って半分にするのがニガテだった**ので、とても嬉しいです。

うん。
**…はい！**
### なっ！

あんまほかのところを知らないのでどのくらい「あーね」なのかわかりませんが
ないわけではないんじゃないだろうか……ないよね？

### どうして今まで電子申請がなかったのか

まあ、セキュリティ上どうしてもいろいろ持ち込めなかったりするもんね。

というわけでもなく、
今まで電子申請がなかったのは
「電子申請がなかったから」という以上の理由はなさそうです。
「（セキュリティ等）色々できない事情があった」というよりは
「**特に電子申請にする事情がなかった**」からだと思われます。

要望はあり、困っていたものの、誰も深刻には困らず、**われわれは有給休暇の申請のたびにインドネシアあたりの木々を間接的に切り倒し、紙で申請してきました。**

（森林資源を大切に！）

https://www.foejapan.org/forest/java/


社内風土もさぞかしアナログなのだろう
と思われるかもしれませんが、
わりとそうでもないです。

上の人たちが戸惑いながらも働きかけに耳を傾けてくれているように思います。

なんとなーくですが、我々よりも苦労した一世代上の人が苦労を止めてくれているんだろうな、という気がしますね。

なので僕も後輩にはラクをしてほしいな、と思っています。

## 意欲はあるけど実施はされない、テストの自動化
我々は会議のたびに新しい技術について話し合っており、
「〇〇してみたいね～」と言いあいますが、
（〇〇にはDocker、進捗管理の方式、テスト自動化などが入る）
それが実施されることはあまりないです。

とくに弊社に限ったことではないと思うのですが、
新しい技術には、**必要に迫られてはじめて手を出す**、というのが実情ではないかと思います。

「グアム行きたいね～」「いいとこらしいよね～」みたいな鳴き声なのかもしれません。

（意欲や技術がないわけではなく、Docker技術は、AI関連の仕事の絡みで必要になったチームがいつの間にか習得していました。）

新規開発案件だったら「コア技術の選定の時によさそうなやつをねじ込む」ということもできるかと思うんですが、
テストの自動化というのは、おおむね、なくても話が進んでしまいます。


# よくやっているシステム概要

![at.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/e064466b-0997-bbd9-a643-42162169d2e1.png)

よくある業務の一つとしては、
こんな感じでメインシステムがあって、A事業所には機能αとβ、B事業所には機能αだけ、C事業所にはαとβとC事業所固有のがあって……みたいな感じです。

改修により、複雑に絡み合った問題が発生することは**まれによくある**。

「固有の機能をつけたけど、ほかに影響してないかな！？
いや、全然関係ないところだし……」

影響してるんだよなあ…。
なぜか例外吐いてエラー落ちするんだよなあ…。

改造によりバグが発生し、修正版をリリースすることはそこそこあるのですが、
だからといって「今すぐにテストを自動化しよう！」という動きは一切ありませんでした。
「じゃあ、テスト項目に漏れがないかチェックしよう」「コードレビューをしよう」
といった「気を付けて、頑張る」ものになりがちです。

BtoB業務が主で、一般のお客様が使うツールではないことから、
おおむね、問題が起こってから直すほうが早い。

（たまにそのせいで飛行機で先輩が出張する✈）

## テスト自動化をしてみたい

弊社はよく帳票を出力するようなソフトを作っており、
エビデンスとしてスクリーンショットをとっていって、
取扱説明書を作ったり、Excelにペタペタ貼るような感じの業務があります。

まあ、これは、紙で有休を申請するのに比べたら、
そんなに珍しいことでもないんじゃないでしょうか。

お客様から要望があって画面を改修することはよくあるんですが、
「この『セーブ』というのを『保存』にしてほしい」
と言われたりすると、
場合によってはほとんどのキャプチャが撮り直しになります。

作る側のきもちとしてはその程度の仕様変更は全く構わないのですが、
それはそうとして、時間は取られるし、
決まったことを何度もやるのは生産的な仕事とは言えません。

場所にもよりますが、画面や帳票の数は結構な枚数になります。
さらに設定入力、印刷プレビュー、etcとすべての機能を試していくと、結構な数になります。

なんとかして、こいつを自動化できないだろうか……。
というのをT-DASHでやってみます。

https://service.valtes.co.jp/t-dash/

T-Dashのうれしいところは、なんといっても**Windowsアプリケーションに対応してくれている**ところ！！


# 自動的にスクリーンショットを取ってほしい

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/5f6183a3-434d-4b93-06c1-37df75cad3c7.png)

さすがお仕事用アプリを出すわけにはいかないので、
非常にシンプルなアプリを作ってみました。

ボタンABCがあり、それぞれ押すと対応したアルファベットが出てくる画面が出ます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/59194cd9-39bb-54b3-adc3-323d8bb27175.png)

業務用アプリだと、帳票Aボタンー＞（帳票の細かい設定）ー＞帳票、みたいな感じです。
（本当はもっと日付やパラメーターを入れたりして、細かい入力をする必要があります。）

ひとつのところでフルセットで入ることはありませんが、帳票自体にはかなりたくさん種類があります。

### 画面や要素の定義
まず、画面やボタンの定義からはじめましょう。
付属のT-DASH WinToolを用いて、画面の要素のパスなどを取得します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/1f746048-d1f7-65d5-1096-cb8c00138201.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/71d20a66-c5e3-64c4-f75f-49cd84781aa0.png)

選択行からトラッキングを自動反映、にしておくと楽に取得できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/da0368a6-54e9-ea70-e95c-33c4799a19c2.png)

X-Pathがおぼつかないときは画像でも判定ができます。
どちらを使うかはケースバイケースになりそうですね。
パーツの文言や画面サイズが変わったりして見た目が変わっちゃいそうな場合はX-Pathがいいんじゃないかと思います。
逆に、X-Pathが一定じゃないときは画像がよさそうです。

今回はX-Pathでとくに問題がないので、X-Pathにしました。

### テストケースの作成

「すべての画面を撮影する」テストスイートを作りました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/308220d7-8ccb-2f38-7adb-ce2578d6ac46.png)

ありがたいことに、特殊操作にきちんと「画面のフルスクリーンショットを撮る」があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/9875dd7c-05bf-66dd-0dc1-e73e36a1dfc4.png)


選択したテストを実行……。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/27443118-4284-e9fd-89f0-d9b70a00328e.png)

成功してくれました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/237e72af-432b-01f5-3351-c35ccac09ce6.png)

詳細を見ると、きちんとスクリーンショットが撮れています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439672/60255b8f-2b72-c7fc-aa4e-45ce11913cfb.png)

これをすべての画面に繰り返して実施するようにしておけば、自動的にスクリーンショットが撮れます。
ややRPA的な使い方ではありますが、かなーり大切な一歩だと思います！

## 良いところ◎
- 表面的な仕様変更があってもサクッともう一度テストができる
- 試験する人の技術に依存しない試験ができる

これでお客様の要望に応えて「要素をもう少し右に」とか言われてもスクリーンショットの撮り直しの手間が省けます。
また、たぶん初期でテストケースを登録していくのはわかってる人がやんないときついんですが、しっかり試験のフローさえ組んでおけば、「これやっといて」って新人ちゃんもできるようになりそうです。
Excelの試験規格書が一気に試験成績書になりますね！

この作業、だいたい下っ端がやることが多いので、
「自動化したい！」って言ってもあんまり伝わらないんですよ！

## これからに期待……。
- 開発用パソコンのみ
ライセンス管理で、T-DASHアプリを動かさないとならない。本番環境のものはそのまま納品するので入れられない）
- 画面だけのスクリーンショットには切り出しが必要そう

弊社は機器の納入まで扱うことが多いので、実際にテストしたいのはお客様のパソコンになります。
本番用の環境に好き勝手にアプリを入れられないのは少し難点かもしれません。

ただし、疑似環境でスクリーンショットをとることもよくありますし、開発用パソコンで試験ができるだけでもありがたいです。

ざっと全部のボタンを押してとにかくエラーで落ちないことを確認するとか、そういうときにしっかり活躍してくれそうです。

なんていうか、全部のボタン押してほしいことって結構あって…。
理論上は絶対大丈夫なんだけど一応みたいな試験は…省略しちゃうこと、結構あって…。

機械だったら、再試験もめんどくさがらないですからね。

## おわりに

T-DASHはWindowsで内製ソフトを作っているベンダーにはありがたい位置づけのソフトですね。

弊社のようなところだと、便利なツールがあっても、「やってみたい！」という段階ではちょっと足りないみたいです。

**「やったらできました」まで持っていかないと上手くいきません。**
（それで、使い続けられるかはまた別の話だと思いますが…）

で、「試しにやってみましょうよ」って言って、無理やり引き込んでみると、いつの間にか手放せなくなったくらいで、なんかしれっとみんな使ってて、誰も前のやり方には戻そうとは言わなくなっているわけですね。

会社とお客様を困らせない範囲であれこれ試して実績を積ませて導入したい。