Mercari Engineering Blog

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

メルカリのQAエンジニアがテスト自動化に挑んだ話

はじめまして!QAエンジニアのkinoshです。

みなさんは「自動化」と聞いて、どんな期待をしますか?
生産性アップ?高い品質?スピード?いろいろな期待があると思います。
現在メルカリQAでは、繰り返し行われる部分や、機械のほうが得意な部分をどんどん自動化して、節約できた時間を、人間しか見つけられない作業(不具合を探索したり、仕様からリスクを洗い出したり)に使っていこうと日々奮闘中です。
この記事では、最近私が主導で進めたテスト自動化について、自身が学んだ知見などを共有いたします。

進んでいた自動化

メルカリにはQA-SETチームというものがあり、QAエンジニアとSET(Software Engineer in Test)が同じチームで品質を支えています。それぞれの役割については以下の記事をご確認ください。

tech.mercari.com

リグレッションテストに関しては、全体の件数の約3/4が自動化され、簡単に実行できるようになっています。これについては以下の記事でも詳しく解説されています。

tech.mercari.com

この成果をQAエンジニア視点から振り返ると、大幅にリリース前の工数を削減することができています。自動化できる項目を増やしていく作業はなかなか大変だったようですが、月に2〜3回クライアントリリースを行なっているメルカリでは、非常に効果の高いものでした。

進まなかった自動化

一方で、クライアントリリースよりもリリース機会の多いAPIに注目し、APIの自動テストを行おうとしていました。しかし、こちらは思うように進んでいない状況でした。進めるにあたり、APIエンジニアと「どこをテストすると品質向上に繋がるのか?」なども議論しました。そこで出てきた課題としては、単体テストはAPIエンジニアが担当していますが、それぞれのAPIを組み合わせて呼び出す部分のテストが弱いということがわかりました。

しかし、APIの組み合わせといっても膨大であり、さらにそれらを全網羅するとなると、どこから手をつけていいのか、影響範囲が増えすぎてしまう、など課題は山積みでした。また結局のところアプリを介して実行するため、実行するのに時間がかかってしまい、スピード勝負なところもあるAPIのリリース前に利用されないかも?既に自動化されていたリグレッションテストでカバーできている範囲もあるのではないか?となかなか進まず、悩んでいました。

ちょっとした「めんどくさい」を自動化

APIの自動化について考える日々が続きましたが、なかなか進まなかったので思い切って別のアイデアを試すことにしました。
それは、メルカリボックスの自動化です!
メルカリボックスはまだ新しい機能で、メルカリでわからないことをみんなで相談できる公式Q&Aです。

スマホアプリからWebViewで呼び出しており、ブラウザ上でも動作するので、WebDriverといったよく使われている技術をテストに使えます。

ただ自動化の進め方を考えたときに、既にたくさんの機能追加などが平行して走っていて余裕がなかったため、しっかりとした項目書を考えて、それを自動化していく・・・というリグレッションテストで経験した進め方は、ちょっと億劫でした。 そこで簡単な最低限のテストに絞り、しっかりとした項目書は作らず、自動化して欲しい機能一覧を洗い出しました。

以下のように本当にざっくりとした機能一覧を洗い出し・・・

  • 質問できる
  • 回答できる
  • スッキリ / ベストスッキリが押せる

細かい手順などはSETに伝えずに、実際に使ってもらいながら、シナリオ化していく形をとりました。 いつもテストで確認している箇所を伝えただけでとてもローコストでした(笑)。なのでこの自動化に失敗しても諦められると考えました。

結果的にケース的には少なく、実行も数分で終わるレベルですが、

  1. 基本機能として毎回やっていたテストは自動化された
  2. 追加機能などで、新しくやる必要があるテストに集中できる

状態となり、私個人としては、毎回のテストがかなり効率的に進められたように感じています。

f:id:kinosh:20171110153952p:plain

さらに深く考えると、

  • リリースしたばかりの新機能のため、細かい不具合改修や機能追加などがたくさんある時期だった
  • 徐々にQAエンジニアのテスト待ちが増えてきてしまった
  • 「基本機能の確認」は、どのテストでも実行する必要があった

と、自動化するにはぴったりな状況だったのかもしれません。

まとめ

今回の経験を通して、QAエンジニアとして学んだことをまとめてみます。

まず、自動化を進める前に、「何が面倒なのか」を考えました。私にとって面倒だと感じることは何か?どの部分が面倒なのか?それはなぜか?自分なりに考えをまとめたおかげで、少なくとも「私だけは楽になるだろう」と自信が持てました(笑)。

次に、「誰のための自動化なのか」です。いまのところ利用者は私だけかもしれませんが、今後のことを考えると誰でもできるようにしておきたいです。そうすると、「簡単に実行できるか」も大切な要件です。いまは、JenkinsのJobを「ポチッ!」っとしていて、それだけでも充分楽ですが、今後はSlackからBotを介して実行できるようになるそうなのでとても期待しています!

今回紹介したものは、繰り返し行うテストの自動化でしたが、人間がテストするには大変で手がつけられていないテストの自動化も進めていき、メルカリ全体の品質の向上に繋げてられたらいいなと思います。

f:id:kinosh:20171110152357p:plain

ちなみにこのブログでも何度か登場しているメルカリQA/SETチームのロゴですが、実はBugを2つ隠しているのです! ぜひBugを探してみてください!!

正解がわかった方はこちらまで。

正解は次回(未定)のブログで発表しますのでお楽しみに!