開発チームも巻き込んだテスト自動化のサイクルを実現。
MagicPodはチームの生産性向上にもつながった。
株式会社メドレー
ユーザーインタビュー第２回目は、MagicPod代表伊藤とともにメドレー様にお邪魔しました。
MagicPodの検討段階のお話から、現在の運用方法、これからテストの自動化に取り組まれる方へのアドバイスなど、たくさん伺いました。
株式会社メドレー 会社概要
2009年創業のメドレーは「医療ヘルスケアの未来をつくる」というミッションのもと、テクノロジーを活用した事業やプロジェクトを通じて「納得できる医療」の実現を目指す会社です。求人サイト「ジョブメドレー」を運営する人材プラットフォーム事業、オンライン診療システム「CLINICSオンライン診療」や患者のための医療情報サービス「MEDLEY」などを運営する医療プラットフォーム事業を展開しています。
POINT
- 相談すると即レスしてくれるサポート力の強さ
- MagicPodを使える社内メンバーが多い理由
- 課題と解決が見えているなら、まずやってみる
株式会社メドレー 医療プラットフォーム本部 プロダクト開発室 第一開発グループ
QAエンジニア 米山 允章（ヨネヤマ ヨシアキ）さん
高品質なプロダクトを安定して提供する
私は2020年に入社して、新規機能開発におけるQAやリグレッションテストのメンテナンスなどQAプロセス全般を担当しています。QAエンジニアはもう一人いるのですが、その方も私の少し前に入社しました。それまでQA専門のメンバーはおらず、プロダクトに関わってる開発メンバー全員でリグレッションテストも兼ねてのシナリオテストを手動で回していました。
この体制でも大きな問題が起きていたというわけではないのですが、弊社では医療というセンシティブな分野のプロダクトを開発しているので、今後も品質の高いプロダクトを安定して顧客に提供していくためには、網羅的にQAが見られる体制が必要ということでQAチームが組織化されました。
テスト自動化については、前職でも自動テストの恩恵を受けていましたので、入社直後からプロダクトの品質向上の施策として考えていました。
相談すると即レスしてくれるサポート力の強さ
自動化を考えた際はMagicPodを含むいくつかのツールを検討しました。社内で「QAプロセス全般的にいろいろやっていかないといけない中で、まず自動化でいいのか？」といった議論はありましたし、自前で作ることも選択肢の一つでした。
ただ、iOS/Android/Webと3つのプラットフォームがある中で、自前だとどうしても工数がかかりますし、将来的に属人化しそうな部分も懸念材料でした。
仮にその工数を減らせれば他のプロセスを並行して進めることができます。コスト面でも外注でテストをお願いしたり、自動化専門のエンジニアを採用したりを考えると、自動テストツールを入れたほうがコストパフォーマンスが良いという結論に至りました。
その上でMagicPodは以前から利用している知人からも話を聞いていて、伊藤さんともイベントでご挨拶させていただいたことがありました。トライアル期間があるので、「まずは試してみたい」ということで社内決定しました。使ってみてわからないことがあり尋ねると、即レスポンスしてくださって、すごく助けられたのを覚えています。サポート力と技術力の高さを感じました。
Webとアプリが同じUIで使用できるのは、QAエンジニア以外のメンバーが触る際にオンボーディングコスト(サービスについて理解し、操作に慣れて使いこなせるように導くためのコスト)が少なくて良いと思いましたし、Webでクライアント証明書や二段階認証など自動テストのブロッカーになっていた仕様に対して解決の目処も立ちました。
もっとも弊社の場合はモバイルアプリから自動化に着手したため、検討時点でモバイルアプリにも強いSaaSのテストツールはほぼMagicPod一択ではありました。
左：MagicPod代表 伊藤 右：株式会社メドレー 米山さん
MagicPodを使える社内スタッフが多い理由
導入の最初は毎週手動でテストしていたシナリオをベースに自動化していきました。現在はiOSとAndroidのネイティブアプリ、Webブラウザのリグレッションテストの中で自動化できる部分をE2Eテストとして実装し、デイリーまたはリリース前のQAのタイミングに実行しています。
デイリーで実行することでデグレを早い段階で検知することができますし、「直近の修正じゃないけどいつからだろう？」とさかのぼるときは過去の実行結果を確認できるのでトラブルシューティングが比較的容易です。もちろん自動化できた分、手動実行の工数を削減することもできています。
※Webテストの結果
※お薬手帳機能のテスト結果(モバイル)
基本的に失敗があった際は私の方で問題を切り分けた上で、プロダクト側の問題の場合は開発メンバーに伝えています。
ツールの導入時から実行結果はSlackに通知してほしいというリクエストが開発メンバーからもあり、テスト結果はSlackにてチームのチャンネルへ通知しています。
UIテストはコードベースのテストより落ちやすいですが、失敗に慣れてしまうのは良くないので、成功率を少しでも上げていきたいと日々メンテしています。時にはテストが失敗していた際に開発メンバーが先にチェックして調査や修正を行なってくれていた時もあって、こういうのは一つの理想形だなと感じました。
実装やメンテはできるだけ属人化しないようにはしていて、MagicPodはほぼ環境構築は不要且つ基本ノーコードでメンテナンスできるので、QAがいないチームでも、企画の方や開発のエンジニアが担当しているので、社内にMagicPodを使えるメンバーは多くいると思います。もちろん多少のオンボーディングはしますが、誰でも運用できるという観点で、MagicPodは良い選択でした。
参考：「UIテストの自動化にMagic Podを導入した話」（Medley Developer Blog）
課題と解決が見えているなら、まずやってみる
弊社でもありましたが「自動化の前にまず○○を」のような議論はよく聞く話で、自動化で解決できる問題を放置することにもつながりかねません。現状課題があって、自動化することで改善できそうだと感じているならまずはやってみて、どれくらいのテストが自動化できるのか、実装/メンテナンスコストはどれくらいかかるのか確認した後に改めて判断してもいいと思います。
もちろん全てのテストを自動化するのは難しく、手動で確認した方が良いテストもあります。AIの判定にすべてを委ねることもできませんので、確認するべきことはしっかりと考慮してテストケースを作成する必要があります。実現したいテストに対して、困ったことがあれば伊藤さんはじめMagicPodには頼れる方々がたくさんいますので、どんどん相談するのがいいと思います。
テストツールも最大限に生かして品質はもちろん、チームの生産性を上げる試みは会社によっていろいろ違うと思います。他社の事例にもとても興味があるので、今後は各社で事例を共有し合えたら嬉しいですね。
お知らせ
QAエンジニア、募集中です。
・エンジニア採用ページ
・テックブログページ
編集部からのひとこと
東京タワーの見える、白を基調としたクールなオフィスにお邪魔しインタビューをさせていただきました。
ブログなどの発信やインタビューでも、常にロジカルに考えわかりやすく説明される米山さん。
QAエンジニアとしては社内に２人という体制に関わらず、スムーズにMagicPodを検討・導入し、すでに自動化も軌道に乗らせたうえに社内にMagicPodを使うことのできるメンバーが多くいるというのはさすがの一言でした！！