最終更新日: 2023年5月18日

当ブログを運営するAIQVE ONEは、テクバン株式会社、株式会社MIXIと共催し、「【テクバン×MIXI×AIQVE ONE】3社共催!テスト自動化事例LT会」を2022年6月28日に開催いたしました。
本セミナーは、テクバン株式会社 品質ソリューション事業部が定期的に開催している、「ソフトウェアテスト」「テスト自動化」「アジャイル」「プロセス改善」など、 「QA/品質保証」に関する様々なキーワードをテーマにしたイベントです。
今回のテーマは「テスト自動化事例のLT会」とし、実際に現場でテスト自動化に取り組まれている方々にご登壇いただきました。
この記事では、テクバン株式会社 市川 駿氏、株式会社MIXI 村田 雄人氏による「TIPSTARの自動化~泣いて笑って捲られて~」と題した講演内容をお届けいたします。

<関連記事>【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】テスト自動化の魅力に気づくまで(株式会社MIXI 安里様)
<関連記事>【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】モンスターストライクのQA効率化の取り組み(株式会社MIXI 中尾様)
<関連記事>【テクバン×MIXI×AIQVE ONE 3社共催セミナーレポート】テスト自動化でフリーテストを実現することはできるのか?(AIQVE ONE株式会社 花房)

自己紹介

市川様:
まず、自己紹介になります。

テクバン株式会社の市川駿と申します。
去年の6月にMIXIさんのTIPSTARというプロジェクトにジョインいたしました。

最初はいろいろな機能を触りながら、今では1番重要な機能の1つである車券購入周りのQAをしつつ、自動化担当大臣ということで、仕事をしております。
2018年に新卒でテクバンに入社し、6月に前の現場に配属になったのですが、そこでSelenium WebDriverに出会いまして、そこから自動化歴はQA歴とともに4年になります。

では、村田さんお願いします。

村田様:
MIXIの村田と申します。

本日はお忙しいところ、ご参加いただきましてありがとうございます。
私の方からも簡単に自己紹介させていただければと思います。私は2019年の10月にこのTIPSTARのプロジェクトにジョインいたしました。

当時、TIPSTARはまだリリースされていなかったため、リリース前のQAを経て、現在は新規機能のQA、テスト設計、実施を担当しつつ、傍らでプロジェクト改善をやっているという状況です。それまでは、主にソーシャルゲームアプリや、店舗でスタッフさんが使うアプリなど、主にアプリのQAを中心としてやってきましたので、QA歴は6年半強くらいになります。

今は、JSTQBのALを取得するためにテストマネージャーの勉強をしております。次回からやり方が変わるという告知を受けておりますので、いつ開催されるか待ちながら勉強しているところです。

プロダクト紹介

では、私の方から簡単にプロダクト紹介をさせていただきます。

TIPSTARは、競輪やオートレース、昨年の10月に開幕したPIST6などの公営競技のネット投票ができるアプリです。

この後の自動化の事例のところでも軽く触れますが、ゲーム内のアイテムとしてメダルというものがありまして、これを使うことで、お金を賭けることに抵抗がある方でも公営競技を楽しんでいただけるようになっております。

ちょうど明後日(2022年6月30日)でリリース2周年を迎えまして、今月の頭には大型アップデートを行い、SNSチックなUIに、かなり大幅な改修をしました。今後の方針としましては、これらの公営競技×SNSというところでソーシャルベッティングサービスとして、ユーザーの皆様に楽しんでいただけるように、日々開発をしております。

プロダクト紹介については以上になりまして、この後の自動化の事例については、市川さんにまたお渡ししたいと思います。

使用ツール

市川様:
自動化の使用ツールというところで共有をさせていただきます。

MagicPod

まず一つ目に、 AIテスト自動化クラウドサービス であるMagicPodです。
MagicPodの売りの一つは「ノーコーディングによるテスト自動化」ですので、QAメンバー全員で、自動化をまず体験、体感したというかたちになります。

UI Automator

私としては、この2つ目のUI Automatorという、コーディングで自動化するというところがテスト自動化の本質だと思っております。ここから先の話はコーディングの話になりますので、コーディングが分からない方にとっては難しい話になるかもしれませんが、ご了承いただければと思います。

まずUI Automatorとは何かという話ですが、AndroidのUIテストフレームワークで、標準で備わっているものになります。言語としては、Javaの後継と呼ばれるKotlinで、Javaを簡単に書いた言語になります。TIPSTARの実装言語でもありますので、エンジニアの方も分かりやすいです。IDE統合開発環境としてAndroid Studioを使っております。

UI Automatorはコーディングで自動化するというところで、皆ができるというものではないため、一部のやりたいというメンバーで、エンジニアの方にサポートいただきながら実装しているというかたちになります。

1つのツールに依存するというリスク回避という意味で、UI Automatorも使って自動化を進めております。

初アプリ自動化の所感~泣いて~

初アプリ自動化の所感ですが、このサブタイトル「泣いて」からも分かるように、非常に苦戦を強いられました。

第一の壁:想像以上に苦戦

1. Webブラウザの自動化の知識だけでは太刀打ちできない

Webブラウザで自動化をしておりましたが、やはりアプリの自動化は似て非なるものでかなり癖が強いため、日々大変な思いをしています。

Androidのエンジニアのサポートが必須であったり、Webブラウザのときにはあまり使わなかった正規表現や、そもそもアプリの構造などの知識が必要なのかなという印象です。

2. Kotlinの記法知識が必要

少なからずKotlinの記法知識は必要ですし、そもそもJavaを継承しているものなので、コンパイルなど、プログラミングチックなノウハウもかなり必要になってくるため、非常に苦戦しておりました。

3. 時間に制約がある仕様だと自動化しづらい

TIPSTARは、競輪やオートレースなどのレースに対して車券を買って、賭けるということになりますので、時間に制約があることを加味してコーディング、実装をしていかなければなりません。そのような点で、私が以前やっていたWebブラウザの自動化よりも制約が多いという印象でした。

4. Webに参考になる記事が少ない

こちらもSeleniumと比べてということになりますが、Webで調べても参考になる記事が少ないなという印象でした。

第一の壁をどう乗り越えたか~笑って~

第一の壁ということで今4つご紹介させていただきましたが、続きまして「笑って」ということで、ここで転機が訪れます。それぞれの壁があったのですが、それを解決した方法を共有していきたいと思います。

まず、1つ目の「Webブラウザの自動化の知識だけでは太刀打ちできない」という点についてです。正規表現に関してはやはりエンジニアの方に聞いた方が早いということで、質問するようにしました。アプリの構造に関してはUI Automator Viewerというものがございまして、これは後ほど詳しくご説明いたします。

2つ目、3つ目の、Kotlinの記法知識や、時間に制約のある仕様に対する自動化に関しては、とにかく調べまくって、自分でいろいろ試行錯誤しながらやっていました。ただもちろん、それで解決できたことの方が少ないので、エンジニアの方に聞きながらやっております。個人的に、もともとこの業界に入った理由として、プログラミングを志望していたということもあり、自分でもスクールに通って勉強もしています。

4つ目、Webに参考になる記事が少ないというところで、無いなら作ればいいじゃないということで、MIXIさんの社内ナレッジ共有ツールに記事を都度公開しております。ワールドワイドで公開しているわけではないので、もし公開してほしいという声があれば、僕の気力があれば公開したいなと思います。

では、詳しく説明していきたいと思います。

1. Webブラウザの自動化の知識だけでは太刀打ちできない

まず正規表現のところですが、TIPSTARの資産は、TIPメダル、TIPマネーの2つあります。例として「TIPメダルの値を取得する」というところで、こんな感じのコードを書いております。

正規表現についてはこの、By.textの後ろですね。今見ると簡単なコードなのですが、これが最初は思いつかないというか、なかなか書きづらいというところでした。今ではいろいろ調べながら、「ここはこういうふうに対応しているんだね」ということがわかるようになってきました。

UI Automator Viewerは右側の画像です。TIPSTARの画面をスクリーンショットすると、今は念のためモザイク処理をしてありますが、画像の右側にアプリの構造がずらっと出てきます。それを見て「このボタンはこういうIDが振られている」とか、「このボタンの下にこのボタンがある」というような構造が分かるようになっています。

これを駆使してやってはいるのですが、UI Automatorのスクショの精度があまり良くないので、これからもしUI Automatorを使いたいという方は、 Layout Inspector というものをおすすめいたします。

2. 少なからずKotlinの記法知識が必要


続きまして、Kotlinの記法知識というところですけれども、上からpackageですとかimportですとか、classとか、そういうプログラミングの知識がだんだんとわかってきました。

3. 時間に制約のある仕様だと自動化しづらい


たとえば、締め切りが近いレースの車券を買いたい場合を想定したときに、こんな感じでコードを書きました。Androidアプリの知識がないとちょっとよくわからないかもしれませんが、リサイクラビューというものがありまして、それでベット場一覧をリスト化し、その後、ここでも正規表現を使っています。

「締め切りあと」と「締め切り」というテキストがあれば車券が買えるパターンですので、それを変数に入れ、それをリストの中から探していくみたいなことが書いてあるわけです。これを言葉にしてしまうと簡単といえば簡単なのかもしれませんが、これを実装するとなるとかなり時間を要しました。今となってはいい思い出です。

第二の壁~捲られて~

第二の壁、「捲られて」というところで、かなり光が差してきたなと思いつつ、またちょっと運用面で苦戦しております。

・ケース単体では動くが、一括実行すると何故か動かない

ケース単体では動くのですが、ファイルを一括実行していくときに、何故か知らないけど動かない、という問題が発生しました。一括で動かすから重いのかなと思いつつも、やはりケース自体に不備があるいうことが分かってきました。

もちろん、凡ミスみたいなものもあるのですが、アプリの実装内容を見ないと解決できないようなものが多い。「なんでこのボタン押せないんだろう、見えてるのに」みたいなことが結構多発していました。

例えば、ある機能では、アプリ側は、TrueかFalseかを画面に遷移してから取得しています。もう少し詳しく言いますと、画面に遷移してからそのボタンが活性か非活性かを判断しているのですが、UI Automatorはそんなことは考えないので、TrueかFalseかを判断せずに問答無用でボタンを押しに行ってしまう。なので、この例では、活性か非活性かを判断するという条件をつけてクリックするように実装していました。

・待機(Wait)

また、これはあるあるかなとは思うのですが、待ってほしいときにすぐエラーが起きて、全然待ってくれない。待たなくていいところですごく待つということがあります。

まとめ

最後のまとめになります。
コーディングによるアプリ自動化は相当しんどいということで、これからもしやられる方がいたら、覚悟しておいてください。Webブラウザは経験していましたが、アプリはかなり癖が強いという印象でした。

ゆくゆくは、アプリの実装を見ることになると、恐らくエンジニアとやっていることはほぼ変わらない領域にまで行くのではないかと思っています。そこで、類まれなる努力をし、エンジニアの方にサポートしていただくことで、また実装に光が差してくると思います。今現状、運用でまた曇ってはいるのですが、いつか晴れると信じています。ご清聴いただき、ありがとうございました。

テクバン株式会社
https://www.techvan.co.jp/ 

株式会社MIXI
https://mixi.co.jp/