AndroidアプリQAテスターが職場でやってよかった取り組み(2019年1Q)

このブログでは商品紹介にはてなブログ標準機能のAmazonアソシエイトを利用しています

2019年1月〜3月の間にぼっちQA teamとして職場でやってよかったっぽい取り組みについて書く。

テスト実施までの時間を短縮するための取り組み

だいたい1年前くらいにTwitterに以下の画像を投稿した。

テスト仕様書はなくても自分で書くし、仕様がよくわからなければ開発者に確認すればいいけど、「そもそもハードウェアがない」みたいな問題は基本的すぎて自分だけでは解決できないというニュアンスで描いたような気がする。

で、その頃からQA-testingに関する業務フローは個人レベルでいうと全然変わってなくて、

  1. テストケースの設計・実装
  2. テストケースに応じたデバイスの確保
  3. テストケースに応じたデバイスの環境設定
  4. テストケースの実施
  5. レポートの提出

を投げられるカードごとに繰り返しているが、それこそ上のツイートの図の「SIM」「Device」他SIP設定や外部アプリのアカウント設定などにめちゃくちゃ時間がかかっていることがわかった1

折しも開発者側もプロジェクトが乱立していて欲しいデバイスをすぐに使えないというフラストレーションがあるように見えたので、

などの基本的だけどなあなあになっていたことをやった。

Androidバイスを増やす

ランチ中「欲しいなァ〜〜〜〜」と言い続けたら候補リストを挙げるように言われたので資料を作ってSlackに投げた。

このときメインプロダクトがインストールされているデバイスのOSバージョンや機種名のリストを開発者が出してくれたのでとてもよかった。

Androidバイスにラベルシールを貼る

f:id:wifeofvillon:20190307181019j:plain

何かと嫌われがちなネームラベルだが、Galaxy S7と新しく導入されたGalaxy S7 dualの外見が完全に同じでこれもう絶対にわからんと思ったので導入した。

バイス名とAndroidOSバージョンをそれぞれ別のシールにすることで、サポート対象OSバージョンを引き上げる際のソフトウェアアップデートに備えることにした。

f:id:wifeofvillon:20190226130657j:plain

このときシールを出力するだけ出力しておき、実際に貼るのは開発者にも協力を仰いだところ、デッドストックと化していたデバイスが見つかってよかった。

Androidバイスの返却場所を決める

Android/iOSバイスの返却場所は決まってはいたが数十台のデバイスが雑然と置かれていたので、特定の1台を探すのが割と面倒な状態だった。

そこで

  • ストッカーをDIYする2
  • ストッカーをOSバージョンでエリア分けする

という施策をとった。この辺りはメルカリQA-SETチームのエントリに助けられた。

f:id:wifeofvillon:20190226130912j:plainf:id:wifeofvillon:20190226130849j:plainf:id:wifeofvillon:20190226130831j:plainf:id:wifeofvillon:20190226130736j:plainf:id:wifeofvillon:20190226130622j:plain

正直自分がデバイスを探しやすくなればそれでいい、くらいの期待値でやっていたが、どうもこれをやったあたりからみんながOSバージョンに応じたエリアに返してくれるようになった気がする3

外部アプリのインストール状況を確認するスクリプトの作成

外部アプリへの連携を含んだテストをするとき、いちいちインストール状況を確認してバージョンアップして必要ならアカウント認証を通して〜と手動でやっていたのを、インストール状況とアプリのバージョンまではシェルスクリプトをひとつ叩けばTerminalで一覧できるようにした。

やってることは配列にパッケージ名を入れておいてadb shell dumpsys package ${PKGS[$key]} | grep versionNameってやるだけなのにめちゃくちゃ楽になった。

qiita.com

継続的なE2Eテストの品質を上げるための試み

テストマネジメントツールのトライアル

メインプロダクトの正常系再帰テストは、この1年間Googleスプレッドシートで作られたテストシートを継ぎ足し継ぎ足しして実施してきたが、テストケース単位で結果を追うとか、どのデバイスでどの外部アプリと連携した時が一番時間がかかるのかとか、そういうことがやりづらいなと思ったので、TestRailのトライアルプランを試してみた。

実際にオーバースペックだと感じたので導入は見送ったものの、テストケースの差分管理してテストプランを都度作って〜とかはGASでできそうなのでこれから頑張る(と言ってしまった)。

wifeofvillon.hatenablog.com

VUI機能のテスト用スクリプトを作る

年末から先月頭くらいまでずっと咳をしていてVUIのテストが辛かったのと、あまりにも「Previous」という単語を聞き取ってもらえないのでmacOSsayコマンドで定型文を簡単に出力するためのシェルスクリプトを作った。

自分で喋らなくてもいいのはこの季節本当いいなと思った。

カスタマーサポートの仕事を楽にするための試み

Trelloのカードのテンプレを作る

東京オフィスではバグ管理をTrelloでしているが、CSをやってくれているメンバーが見れていなかったので(開発者が)彼に与える権限を再検討して、ついでに必要事項を埋めてクリックすればTrelloの特定のボード・カラムにカードが追加されるようTrello公式のブックマークレット用機能にちょっと手を加えた。

wifeofvillon.hatenablog.com

あとこれをSlackbotのカスタムレスポンスに追加して「open sesame」ですぐ呼べるようにした4

f:id:wifeofvillon:20190307184428p:plain


そんな感じで私は元気です


  1. 2時間以上かかっているE2Eテストが、実はその1/3くらいが前提環境の設定にかけている時間だったりした

  2. DIYは楽しかったけど意外と工数が嵩んだ割に強度がいまいちなので今度は普通に100円ショップで買ってこようと思う

  3. 根本的なデバイス不足とデッドストックの解消によって返却する動機付けが発生したのでは……?🤔

  4. 理想はSlackを窓口に全ての社内情報にアクセスできることだけどカスタムレスポンスには限界があるので、これ以上は社内のbotにPRを送らなきゃいけなくなる気がする