こんにちは。メルカリの自動化エンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。
今年のはじめに、QAエンジニアとSET（Software Engineer in Test）で構成される「QA-SETチーム」が誕生しました。現在は、そのチームのマネージャも担当しています。今回はQA-SETチームで目指している「メルカリでのQAやテストの未来」をご紹介させていただきます。
QA-SETチーム
メルカリでは、上の図のようにプロジェクトごとに開発チームが分かれています。 それぞれの開発チームには、プロジェクトを実現するために必要な人材が集まっており、アジャイルの文脈だと職能横断型チーム(Cross-FunctionalTeam)になっています。これによって、開発に不要なセクショナリズムがなくなり、自然にプロジェクトに集中できる環境になります。
QAエンジニアもそれぞれのプロジェクトにアサインされており、プロダクトにダイレクトにかかわれます。逆に、SETは、横断的な組織なので、どのプロジェクトにも属さずプロダクト全体を見ながら仕事をしています。
QA-SETチームは、各プロジェクトで中心になって品質を守るQAエンジニアと、それらをインフラや自動化でサポートするSETで構成されたチームです。
メルカリのQAエンジニア
QAエンジニアはその名の通り、Quality Assurance（品質保証）をリードする存在です。その活動は仕様検討への参加からリリース後のチェックまで、「ファーストユーザ」として開発全体に関わっています。
仕事の流れは仕様検討への参加から、テストの設計や実行など、テストに関わる全てを担当しています。テスト以外でも品質にかかわる作業であれば、責任範囲など決めず、プロセス全体にかかわっていくのがメルカリで求められるQAエンジニアです。
現在抱えている課題としては、テストケースマネジメントがあります。スピード感ある開発を進めるために、小さなリリースではケースを洗い出しながら実行したりする探索的なテストが多くなりがちです。
これはこれで良い点もありますが、ノウハウが残らない、探せないという問題も残ります。RedmineやJIRAのチケットにメモを残し、「あとで整理しよう」と思うものほど、なかなか手をつけられなかったり。
現在は、タスク管理ツールとの親和性の高いツールをトライアルで使ってみたり、試行錯誤を続けている状態です。導入は簡単にできますが、使いこなして活用するまでもっていくのがなかなか難しい。
最近解決した課題としては、技術的な要素が多い案件のテストをどうするか？ です。たとえば、以下のようなケースの場合、QAエンジニアだけでテスト観点を整理するのは難しく感じています。
- PHPのバージョンアップしたときのテスト
- iOSやAndroidのバージョンアップしたときのテスト
- 拡張したレスポンスヘッダなど、アプリを操作するだけでは確認できない部分のテスト
- などなど
こういうケースの場合は、SETを相談窓口にして、「何を」「どう」テストするかを議論するようにしています。その結果も依頼者に伝えて「期待するテストなのか」を確認しています。
SETという「QA専属のエンジニア」がいることで、QAエンジニアの生産性も上がりますし、技術的な知識も身についていくので、QA-SETチーム全体のスキルアップにもつながっています。
メルカリのSET
SETは、QA環境から自動化までいろいろやっていますが、先に書いたように、現在の体制だと「QAエンジニア専属のエンジニア」という位置づけが強くなっています。よって、QAエンジニアとSETは運命共同体。メルカリ全体の品質・生産性の底上げを狙っています。
SETのインフラエンジニア（自動化エンジニアとの区別のためこう書かせてください）は、主に開発・QA環境の構築と運用を担当しています。開発・QA環境は、基本的に本番と同等になるため、新しく導入する技術があるなら、それに追随していく必要があります。
さらに、QA環境を利用するエンジニアからのフィードバックにも答えていく必要があります。開発で利用する環境は、表に出るものではありませんが、開発をすすめる上でとても重要で、エンジニア全員の開発効率に直結するため、その改善にも力を注ぐ必要があります。
キーワード「自動化」
QA-SETチームで主に取り組んでいるのが「自動化」です。SETの自動化エンジニアが中心になって自動化を推進しています。
当初は「テスト自動化エンジニア」と名乗っていましたが、その範囲は以下のようにテストを超えてきています。
- テストの自動化（現在、E2Eテストの自動化に注力しています）
- 各種繰り返し作業の自動化（テストデータ作成、テストにまつわる手作業など）
- QA環境構築の自動化
現在は、メンバーのほとんどが、なにかしらの自動化にかかわるようになってきました。
メルカリの自動化はまだはじまったばかりで、他社の事例に比べるとまだまだですが、先入観を持たず、Go Boldに（大胆に！）取り組んでいこうとしています。
マニュアル VS 自動
テスト自動化の文脈でよく話題になるのが「マニュアルテスト VS 自動テスト」です。
- 今目の前の仕事が忙しいから、自動化なんてやる暇がない
- それってやる意味あるんですか論（ROI）
- テストコードを作れば作るほど、メンテナンスコストも上がっていくよね
まだ経験が浅いので結論を出せていませんが、これまでにわかったこともありました。
- リスクを度外視して強引に1ヶ月進めてみたけど、思った以上に痛みがなかった（低メンテナンスコスト、効果は期待通り）
- 動いているモノを見ると、その良さや可能性がわかりやすい（特に並列実行とか実際に見ると未来を感じる！）
- マニュアルテストがなくなることはないかも。でも、自動化が進むと「やるべきこと」が変わっていくのは間違いなさそう。たとえば探索テストスキルがさらに求められたり。
などなど。あれこれ考えていたら見つからないものばかりわかってきたので、自動化やってみてよかったという印象です。
さらにこれを進化させるためには、QAエンジニア、SETだけでなく、開発に関わる人全員が、マインドセットから変わっていかなければならないでしょう。なぜなら、品質はQA−SETだけの問題ではないからです。
QA-SETチームはきっと、開発プロセス全体に関わっていく存在になっていくはずです。
おわりに
個人的な現在の関心は、以下の課題をどうするかです。
- 「システムテストってプロセスの最後だから、しわ寄せが全部集まっていつもボトルネックになってしまうよね」的な課題
- 「テスト工数が確保できないからリリースを延ばさないとね」的な課題
- つまりそれは、「どうすれば品質もスケジュールも守れるか」的な課題
テストプロセスをどこまで高速化できて、どうすれば史上最速のアジャイルテスティングになるのかが悩みのタネです。
でも、そんな理想の環境を、メルカリで実現できるといいなーと思いながら、試行錯誤の毎日を楽しく過ごしています。
PS・・・テストや自動化の話をカジュアルにできるようにFacebookグループ [Agile Testing, Automation and QAの現場](https://www.facebook.com/groups/899860193555436/) を作ってみました。もしご興味があれば、ぜひ遊びにきてください！
|
||||||||
