読者です 読者をやめる 読者になる 読者になる

Mercari Engineering Blog

We're the engineers behind Mercari. Check out our blog to see the tech that powers our marketplace.

「Be Professional Day」でちょっと便利なQAテストツールを作った話

f:id:daipresents2:20170403193758p:plain:w400



こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。

先月のおわりに、Be Professional Day (BPD)というイベントが開催されました。BPDとは以下のような取り組みです。

この先、人やコンポーネントが増えて複雑になる中で、プロダクト開発と既存コードのメンテナンスなどのバランスを取っていく必要があります。 短期的にはプロダクトの利益にならないことも、中長期的に開発効率やクオリティに影響することがありますので、そうしたものを少しずつでもやる機会を作りたい、というエンジニアリング的な背景が、最初の主目的です。 転じて、プロデューサ、Product Development Coordinator、QA、デザイナーなどプロダクト開発に関わるすべての人が、Be Professional なことをやる日、として定義します。

このイベントに、テスト自動化チームとQAチームで参加しました。今日は、BPDにQAエンジニアと自動化エンジニアで、普段なかなか手を付けられない課題に取り組んだときのお話です。

BPD! BPD! BPD!

f:id:daipresents2:20170403193926j:plain:w600

集まったメンバーで以下のようなアクションを考えました(殴り書きですいません・・・)。

  1. 全画面のスクリーンショットを撮る自動スクリプトを作る
  2. Postmanを使ったAPIテストを勉強する
  3. 簡単なコマンドでアプリ操作できるツールを作る
  4. この数ヶ月で起きたトラブルやバグ情報のふりかえりを行う
  5. テスト管理ツールを作る
  6. 機能一覧の整理整頓をやる

今回のBPDは2日間開催されました。基本的にやることは自由に選べますが、最終日に開催される発表会をゴールに設定しています。

また、途中に4の「ふりかえりMTG」や、「せっかくだし担当とは違うアプリを使ってみよう大会」などの時間もスケジュールに組み込んでいます。

f:id:daipresents2:20170330175711j:plain:w600

チームは円卓に集まってアクションに取り組みました。集中してプログラミングするメンバーもいたり、異なるチーム同士でお菓子を食べながら情報交換したり、京都の面白い神社の話をしたり、みんなでどうぶつ占いをして「あー、それすごくあたってるわー」とか話題になったり。

時間はあっという間に過ぎていきました。

Postmanを使ってAPIテスティング

発表までにはいたらなかったのですが、QAエンジニア2名と僕で、Postmanの使い方を調べました。使い方についてはこれまでにいろいろ調べたり使ってみたりしていたのですが、QAエンジニアと一緒に、実際の利用を想定してユースケースを考えたのはとても面白かったです。自動化するにしても、何がどうなればハッピーなのかは、担当するプロダクトや開発チームごとに微妙に異なります。今回は、

  • 新規テストユーザを作るPostman
  • ユーザ名を指定して、そのユーザで商品を出品したデータを作るPostman

などを作成しました。APIドキュメントは社内で公開されているので、そこから必要なAPIを見つけ、必要なデータをセットして送信・・・。ここまでできれば、あとは自由自在にAPIを活用できます。

BPD終了後に、一緒に作業したQAエンジニアからコメントをいただきました。

  • APIの仕組みを知ることができたので、よりテストのイメージが湧くようになった。
  • Postmanを使ってテストデータの作成が効率よくできるようになった。もっと早く知っておけばあんなときこんなとき苦労しなかったのに!
  • 唯一残念なところは、作ったパーツをRunnerでうまく再利用できない点。APIのテストを自動で行うのは悩ましいところ(Postmanが作っているコマンドラインツールnewmanならよりフレキシブルに使えるかもしれませんね)

「苦労しなかったのに!」という課題がBPDで解決できたのであれば、とても大きな一歩です。

日々の繰り返し作業を簡単にする「Baby」

今回、一番活躍したのが、3月から自動化チームにジョインしたVishalの作ったコマンドラインツール「Baby」です。作成の経緯や発表時の反応は、彼に説明してもらおうと思います。

Baby

f:id:daipresents2:20170406201218p:plain

動作をキャプチャした画像はこちら(2.3MB、Googleフォトに飛びます)

Idea of baby came after rethinking mobile QA process from zero-based thinking during BPD. In general, most of the companies follow two approaches for mobile QA. It is either manual or automated. There are pros and cons for both these approaches but most of us know that both are not sufficient if used alone. On BPD, I tried to think about a new approach and result was baby.

PS: If you are curious about logic behind this project name then unfortunately I will have to disappoint you as there is no login behind its name. I did not have much time to think about name and ran a random name generator program and got this and kept it.

Testing Approaches

Manual Testing

Pros

  • Easy to start, not much preparation is required. Can test anything new
  • Manual QA can also check what is not listed in test cases
  • Can also verify business specifications

Cons

  • Not scalable, Need more people as application gets bigger
  • Takes time. Can slow down new releases
  • Repetitive job can demotivate QA team
  • Slow feedback for developers

Automated Testing

Pros

  • Can cover more devices and OS in less time and in less cost. Scalable
  • Developer can get very quick feedback
  • Very good for regression tests

Cons

  • Development cost is high
  • Test maintenance is tough
  • Hard to cope up with development speed, so difficult to test new feature with automation
  • Flaky tests

If one analyze above data, it can be easily concluded that none of them is standalone solution. A hybrid approach can do much better. This is what I tried to do here.

Semi Automation Testing

If we see Manual QA side, it is very good for startups and small companies where development speed matters and there is not much resources available for automated UI Testing. Biggest problem with Manual QA is speed. So our idea here is, what if we can use our automation skills in improving QA speed instead of test automation. This is what baby is.

A command line tool which makes QA life better by automating their repetitive tasks

Terminology

  • Action

This is repetitive task which QA people have to do to again and again on mobile app such as: login, creating a new item, buying and item, reinstalling app etc

  • Scenario

This is basically sequence of actions which QA people can pipe and run all together

Baby API

  • Playground (baby playground --help)
NAME
    playground - Enjoy mercari on console

SYNOPSIS
    baby [global options] playground [command options]

COMMAND OPTIONS
    --env=dev|prod         - Target environment (default: dev)
    --platform=android|ios - Target platform (default: android)
    --region=us|uk|jp      - Target region (default: us)

This will open Ruby REPL (pry) where QA people can run various actions such as login, remove_tutorial etc

  • Scenario (baby scenario --help)
NAME
    scenarios - Scenarios testing

SYNOPSIS
    baby [global options] scenarios list
    baby [global options] scenarios run --name login|list_item

COMMANDS
    list - List all scenarios
    run  - Run a scenario

List and run all the scenario made from actions

Reactions

During BPD presentation, people seemed happy about this. Sharing one of the slack screenshot when I was presenting it showing people’s reactions

f:id:daipresents2:20170406194443p:plain:w500

おわりに

f:id:daipresents2:20170403195221p:plain:w500

今回のBPDは1月に開催できなかった分、2日の開催になりましたが、BPDは毎月開催されます。

新年度もはじまって、忙しい毎日が続きますが、こういった取り組みは続けていきたいものです。