「ココナラ」テスト項目1,000件から工数削減への道のり。理想のQAを目指して

— みなさんの自己紹介をお願いします。

村上さん：ココナラで開発担当の執行役員をしています。ココナラに入社して3年ほどですが、もともとはソフトウェア開発の研究をしていて、「バグの起きにくい設計」「設計の検証」や「設計から実装の半自動生成」といった品質周りに関心がありました。今回Autifyの導入を主導しております。

岡宮さん：ココナラで、CSグループのQAチームでリリース前のテストや、不具合検証、Autifyのメンテナンス、QAチーム内の業務改善等を担当しています。ココナラがローンチして1年後の2013年から、ココナラで働いています。当時はデザイナーとしてUI改善に取り組んでいましたが、2019年に発足されたQAチームにアサインされて、現在に至ります。

鈴木さん：私は2022年1月にココナラに入社して、プロダクト開発直下のQA開発チームにいます。現在、半年ほどかけてテスト開発のプロセス整備に取り組んでいます。前職では、第三者検証として、QA工程のテスト計画から実行、Seleniumをベースとしたテスト自動化の経験があります。

— QAメンバーは何名いますか？

岡宮さん：現状4人で、（2022年）10月からは5人になる予定です。

— 御社の事業についても教えてください。

村上さん：『ココナラ』というサービス（スキル）マッチングのマーケットプレイスを開発・提供しています。例えばデザイナー、プログラマー、カウンセラーなどさまざまなスキルや知識をお持ちの方が登録していて、仕事や人生の経験で培ってきたスキルを、出品者となって販売。それを別のユーザーが購入できるサービスになります。

オンラインのメリットを生かして、場所や時間にとらわれずマッチングしやすいのがポイントです。モノと同じように、スキルの世界でも「全てが揃うマーケットプレイス」が実現できるのではないかと考えています。【一人ひとりが「自分のストーリー」を生きていく世の中をつくる】をビジョンに掲げ、プラットフォームを運営しています。

— Autifyを導入する前は、どんな課題がありましたか？

村上さん：最初はQA担当者が岡宮1人しかいない状態で、その当時はQAのやり方自体も明確に定まったものがなく毎回手探りな状況でした。何度もプロジェクトを回していくうちにQAの型が決まってきたので、、メンバーを一人増やしてQAを強化してきました。その状態になるまでは、度々本番でも障害が起きていて、障害のたびに開発が一時ストップしてしまうということも発生していましたが、2人のQA体制になってかなり解消された実感がありました。

その後、さらなる品質向上を目指してテストケースを増やして運用していくことになりました。ですがノウハウもそんなにあるわけではなく、かつ工数も限られているなか、複数のプロジェクトが同時に走っていましたのでQAリソースが全然足りていませんでした。

岡宮さん：当時はプロダクトマネージャーがスプレッドシートでテスト項目を作って、100〜300件ほどを2・3日でこなしていたんですけれど。プロダクトの成長とともに仕様変更や新規機能のリリースが増えて、テスト項目も気づいたら1,000件近くまで増えていました。そしてリグレッションテストも実行することになりいよいよリソースが逼迫してきたため、当時開発部長だった村上に相談したというのがことの発端です。

Selenium IDEなども試してみましたが、部分的にしか自動化できず、メンテナンスも大変そうな印象で運用にのせるイメージができませんでした。

— テスト項目が増えた背景には、開発サイクルが早くなってきたこともありますか？

村上さん：開発サイクルもありますが、エンジニア数も増えてプロジェクトの並列度が上がったことも大きいです。またQAの知見が貯まっていって、テストケースの精度が上がったことも要因していると思います。過去に発生した障害などのノウハウを参考にして、起きうる障害を先回りしてテストケースを組むので徐々に件数が増えていったという感じです。

— 増えたテスト項目を少ない人数でこなせるようテスト自動化を検討し、その中でAutifyを見つけてくださったんですね。

村上さん：その時は、エンジニアのリソースを使うことなく、テストを自動化できないか？ と考えていました。そんなとき、社内の誰かが「Autify」というワードを出してくれて、「SeleniumのWeb版かな？」と軽く捉えていたんです。ただ触りもせず判断するのも良くないと思い、1回触ってみて結論を出そうとその日のうちにトライアルの申し込みをしました。

アカウントを発行してもらって実際に触ってみると第一印象として「これは行けるぞ」と感じました。その後、岡宮ら他のメンバーにも見てもらったところ結構反応が良かったので、具体的に導入を検討することにしました。

岡宮さん：Autifyを知って、ブラウザに記録したものが動く様子を初めて見たときに、とても感動して「これだったら自分でも使えそう」と思いました。実は最初、Autifyは海外のサービスだと思っていたんですよ。日本語に対応しているのかな？と気になって会社概要を見てみたら日本の会社で、しかもCEOが（以前ココナラの開発にも携わっていた）近澤さんだったので驚きました（笑）。手伝っていただいていた頃から7年、巡り巡ってこんな形で助けにきてくれた「救世主」のように思えて嬉しかったです。Autifyを使ったテスト自動化に希望が持てた、そういう記憶があります。

— ありがとうございます。感慨深いです。

Autify導入の決め手になったポイントは何かありますか？

村上さん：決め手は、トライアルを経てテストケースの実現がクリアできたことでした。現在活用できているのはリグレッションテストの部分です。会員登録やログインして検索、閲覧など、どの機能でも共通した動作確認が担保できています。最近だと、計画的にフレームワークのバージョンアップ対応に力を入れていて、リリース時に毎回テストをする必要があります。そこでリグレッションテストの重要性がさらに増しているため、有効に活用できていると感じます。

— 導入の際、手動の部分をどう置き換えるか、その判断と実装を具体的にどのように進めましたか？

村上さん：テストケースを今まで通り作った上で、手動で行う部分とAutifyに置き換える部分を整理して行きました。

岡宮さん：大まかに「ユーザーがログインして閲覧する」、「出品者が出品する」、「購入者が購入する」の3つに分けて、項目を書き出していきました。そのリストの中には自動化できるもの／できないものがあります。どうしても自動化できないものは、例えば「キャリア決済」や「電話相談」、「ビデオチャット」など。マッチング経路は、購入者が買って、出品者とのトークルームが開いて、その中でやり取りする部分は自動化できるとわかりました。

鈴木さん：もともとテストケースはQAチームが作るのではなくて、対象とする機能を企画した人が作成していました。Autifyでどのようなテストケースが実行できるのかを理解していなかったため「置き換え」に少し手間取ったと思います。その後、QAチームがAutifyでテストすることを前提としたテストケースを作成し、スムーズに実行できるようになりました。

— テスト自動化を進めていく上で工夫したことがあれば教えてください。

岡宮さん：CSのQAチームでAutifyのシナリオを作成する際、「JSステップ」と「ロケータ設定」がうまくいかないことがありました。これらはコードを書いてカスタマイズできる機能なのでAutifyのサポートに何度も問い合わせて、助けていただきました。そうして得たノウハウをリストアップしておき、他のメンバーとシェアしながら作っていったところがまずシナリオ作成で工夫した点です。

運用面での工夫は、テストプランと実行頻度です。テストプランは大きく2つに分けています。1つは「基本シナリオ」で、主に閲覧、会員登録、購入／出品など、1つのアカウントで完結するシナリオを23件まとめて1つのプランにしています。これをリグレッションテストとして毎日実行しています。

もう1つのテストプランは、「ユーザー間取引のシナリオ」です。出品者と購入者のアカウントで「購入→トークルームを開く→メッセージを送る→お互い評価する」といったやりとりが3往復ぐらいあります。そのシナリオを1つのテストプランにまとめて、だいたい週1回ぐらいの頻度で実行しています。

また、実行する時間帯は朝6〜8時に設定し、出社した頃にはテストの結果がSlackで通知されるようにしています。テストが失敗していたら調査するルーティンを作るために、時間帯を工夫しました。

村上さん：Autifyの習熟度を上げるためにトライしたのが、ランダムなメールアドレスを使ったログインです。弊社サービスでは、同じメールアドレスを使った会員登録はできないため、この機能を使うことで会員登録のテストが毎回実行できるようになりました。

もう1つ、入力データとしてCSVデータの導入も行いました。CSVデータを使うことで、同じテストケースであっても異なる入力値を使った複数パターンのテストを試せるというのが便利でした。また、「ステップグループ」でテストケースの一部を共通化できる機能もレコーディングの手間が省けて便利でした。これは、もともとAutifyの機能上の制約でシナリオの先頭部分にしか入れられなかったのですが、迅速なアップデートのおかげで、シナリオ途中に入れられるようになったのでとても使いやすくなりました。

岡宮さん：ステップグループ、すごく使いやすくなりましたよね。弊社では重複するシナリオが結構あるので、「評価する」、「メッセージを送る」、マッチング経路などでも使うシナリオをグループ化しています。テストプランの中でも、「シナリオを順番に指定できる」機能が加わりすごく便利になりましたね。以前は「購入者」で1時間回したあとに、「出品者」で回すという流れでした。5時間ぐらい掛かっていたのが、今は20分ぐらいで収まるので大幅な時間短縮になりました。Autifyの機能がどんどんバージョンアップして、さらに便利になってきたと感じます。

鈴木さん：僕がチームに入ったときには、もう運用していましたけど、すごくいいなと思ったのは、営業日の夜に必ずAutifyでテストを実行していたこと。そして、その結果を見てメンテする時間を設けていたこと。これはうまく続いている秘訣なんじゃないかなと思っています。自動テストを作ったのはいいけれど、メンテナンスをせずにいざ使いたいときに動かないと、モチベーションが大きく下がりますよね。それを自然と回避できているのは良いと思いました。

村上さん：実はそれは今でこそやれているけども、最初は自然にやれていたわけではなかったんです（苦笑）。テストを作るまではやるものの、時間がなくあまり回せなかったり、テストの整備ができずにいた時期がありました。放置しているとどんどんメンテナンス工数が増えるから、定期的に少しずつ時間を確保することにしました。

岡宮さん：QAメンバーが2人しかいなかったので、Autifyで実行していたものの、施策のリリースのほうの手動テストが忙しくなると放置してしまった時期がありました。失敗していると分かっていながら後回しにする時期が続いて、そうなると、せっかく導入した意味がないので「1日30分だけでもチェックしよう」と話し合って決めました。その後、鈴木さんがチームに入って、失敗していたのを一気に直してくれた。そのおかげで今はうまく運用できているので感謝しています。

村上さん：その時、新しい転換期でもあったのでテストケースの取捨選択をしました。end-to-end向きのテストと向かないテストを精査して、工数を見直しました。今はうまく行かない時期を乗り越えて、いい方向に向かっていると思います。

— Autifyを導入してしばらく運用されていますが、導入前の課題に対してどんな変化があったか教えてください。

村上さん：まだまだこれからではありますが、社内でもAutifyに関心を持っている人が増えて、プロダクト側とインフラ側の両方から「このプロジェクトでAutifyを使わせてもらえませんか？」という相談が来るようになりました。さまざまなプロジェクトでリグレッションテストの需要が上がっていることが背景にあります。社内でもQAの存在感が大きくなっていて、いい意味で頼られているのは、チームが頑張った積み重ねの結果だと思います。

岡宮さん：Autifyで何ができるか認知してもらうために、社内で勉強会も開きましたね。

— 現在リグレッションテストは、Autifyでどれくらい自動化できているのでしょう？

鈴木さん：だいたい自動化率は50％です。Autifyのシナリオを全部流せば、全機能の50％が疎通できる状況になっています。新規機能に対してテストケースが作れていないところがあるので、今後カバレッジを上げていけたらと思います。

— 今後の展望をお聞かせください。

村上さん：テスト自動化は引き続き進めていきますが、そもそも私達はテストの自動化は通過点だと思っていて、「QAの時点でバグが起きている状況自体がイケていない」と感じています。ソフトウェア開発は、後工程になればなるほど手戻りが大きい世界なので、事前に気付いて即座に解消できる状態が理想です。そのためにQAにできることとしては、これまでのQA履歴や本番障害などのノウハウを貯めて、それを企画・デザイン、設計および実装など特に上流の開発プロセスにフィードバックし早期不具合解消を推進していくことだと思います。もしそのようなフィードバックサイクルが回るようになってくると、QAでは「テストでバグがないことを確認して終わりでテストやり直しは一切不要」という理想的な状況になっていると思います。このような状態に一歩でも近づいていければと考えています。

鈴木さん：今後取り組みたいことは3つあります。1つ目は、テスト結果を開発側にフィードバックしていくこと。2つ目は、テストケースの最適化です。本番障害率は限りなく0％に近づけながら、テストケースを減らしていくことを目指したいです。

3つ目は、テスト実行の生産性向上です。AutifyがSeleniumと圧倒的に違う部分はスピード感だと思うんです。例えばステップグループをうまく活用してパズルのように組めば、素早くテストケースが作れます。リグレッションテスト以外でも、新機能向けのテストにも既存のステップグループを用いて短期でテストを作成できるようにするなど、汎用性を考えられたらいいなと思っています。

— 確かに、それによってコンスタントにリグレッションテストのケースが増えていって、よりカバー率が上がって、安心度も増していく。

村上さん：そうですね。ただ、変更が度々行われるような機能についてはリグレッションテストに向かないこともあると思いますので、うまく選別した上でできるといいですね。

先ほどのフィードバックサイクルに関してですが、過去事例を踏まえて事前に不具合を解消できれば、QAの強みになると思います。そこで、AutifyがQAのナレッジベースになってくれると、そういった分析がやりやすくなるので今後のアップデートに期待しています。

— 失敗していたテストケースが、Autifyで分析できる状態になっていれば「ここの仕様はカバーしておこう」といった議論が効率的にできる。

村上さん：そうですね。現状は、バグが起きたときにどの工程で起きたバグなのか要因を分類分けしてスプレッドシートで管理しています。一覧で可視化できれば、バグが起きやすいケースが分析できて、どうすれば防げるかを議論できます。そういったところも含めてツール側でできると、もっと便利になると思います。

鈴木さん：その機能があるといいですね。今、全てのテスト実行結果を岡宮らが転記して、テストがfailした原因区分を決めて、データを収集しています。半年ぐらいデータが貯まってきています。

— なるほど。今まさにテスト結果の改善を進めていまして、検索やフィルタリングができるようにしていく予定なんです。とても参考になりました。ありがとうございます。

先ほど、より早くテストしていくという話もありましたが、最近公開した『Autify Connect』は、ローカル環境でもAutifyのテストが回せるようになりましたので、ぜひご活用を検討いただけたらと思います。

— これからテスト自動化に取り組む方々へメッセージをお願いします。

村上さん：デジタルネイティブな時代において、優れたユーザー体験を安定して提供していくことはWANTではなくMUSTになっていると感じています。実際、障害が多く安定しないサービスだと、ユーザーが離脱してしまうことは想像に難くないと思います。しかし一方で、機能開発にはある程度、リソースは割けるけど、上記のような安定したサービスに向けての品質担保の対応にはなかなかリソースを割きにくいケースも多いのではないでしょうか。

こうした多くの企業が抱える共通の課題解決のためにも、なるべく工数を掛けずに安定的に品質を担保する仕組みにしていくことが必要です。Autifyを活用することで、これらの対応を自動化・効率化することができるため、弊社ではととても助かっています。、今後は、サービスのさらなる機能拡充に期待しつつ、利用企業同業者間で情報交換しながら、ベストプラクティスを見つけていけられたら良いなと思います。

岡宮さん：手動テストに限界を迎えている方がいたら、自動でできる部分はツールを試してみることをおすすめします。特にAutifyは、本当に直感的で分かりやすいUI/UXになっているので、私みたいにエンジニアではない方でも始めやすいと思います。

鈴木さん：テスト実行は、目的ではなくて手段なので、何を実現したくてテスト自動化をするのかが大事だと思います。弊社では、機能開発が進んで仕様が変わっていっても、既存テストのユーザーストーリーを記録して担保してくれる部分をテストが担っています。目的を明確にして取り組むと良いのではないでしょうか。

— 最後に御社からお知らせがあればどうぞ。

村上さん：ココナラは2022年8月の時点で314万人の方に使っていただいているサービスです。2021年には東証マザーズ（現グロース市場）に上場し、投資家さんからも注目されています。いろんな方が見てくださっているからこそ、より一層、高い品質であることが求められています。QA体制強化やテスト自動化も含めて、仕組みや体制が整ってきているので、これからのサービス発展に向けてQAや開発にご興味がある方にぜひ来ていただけたらと思います。

株式会社ココナラ 採用ページ

— ありがとうございました！

（聞き手：オーティファイ株式会社 CEO 近澤 良）