MagicPodの導入で、QAチーム自体の品質も向上した事例紹介

ツール導入前の課題

求人検索サービスを提供するスタンバイのQAでは、toBやtoCのサービス、加えてバックエンドやアプリの検証など、多岐にわたるテスト対象があった為、リソースの問題でQAが必要と考えるボリュームで理想的なテストが実施できていませんでした。
リグレッションテストの観点でも、リリースサイクルとテスト量のバランスが崩れており、本番不具合対応で開発チームに本来不要だったかもしれない調査や対応をお願いすることがあり、プロダクト全般の品質向上を行えていないことが大きな課題のひとつとなっていました。

1. QA完了後、想定外の箇所で安易な不具合の取りこぼしがあった。
2. QAを通さない、軽微な新リリースに起因する不具合の検出が遅れていた。
3. リグレッションテストのボリューム増加に対して、テスト内容の再構築が行えていなかった。

どのような状態を目指していたか

QAが最低限必要と考える以上にテストを回すことを目的とし、以下2点を実現することで課題解消を期待しました。

• 全QA依頼時に全般的なリグレッションテストの実施
• 本番/検証環境で、日次の定期的なテスト実施

• Autify
• mabl

Autifyは前職で軽く触ったことがあった為、MagicPodのトライアルを申し込みました。
トライアル時には、導入後に実現したいテスト内容を予め想定しておくことが肝要です。操作に慣れることももちろん必要ですが、期待する操作や動作を導入したいサービスで再現できるか否かを重視しました。

• スタンバイQAのスタッフが、ノーコードでテスト自動化できること
• 現行のテスト内容を再現する為に、必要十分な機能を備えていること

結果として、スタンバイQAが要求する機能は、両サービス共に備えていることがわかった為、機能面が導入判断の決め手とはなりませんでした。

一部エンタープライズのプランを前提としていますが、以下の事由で導入を決定しました。

• シナリオ数（エンタープライズプラン）と実行数が無制限であること
  • 制限に抑える場合、必要かもしれないテストを割愛するなど、思考・判断が必要になること
  • 制限を超えたい場合、超過分の社内稟議が煩雑になること
• 他ツールと比較し、安価であったこと
  • iOS/Androidアプリ対応のプランでも、コスト面でかなりの優位性があったこと
• QAメンバーだけで完結できること
  • 開発スタッフを関連テストから解放し、開発に集中できる環境にすること
  • 日本発のサービスであることもありサポートが手厚く、ベンダーロックされても問題がない品質と規模であったこと

改善したかった課題はどれくらい解決されたか

タイトなスケジュールの中でも自動化を進めたことにより、当初の目標としていた事項は全て解決されました。
テストシナリオの充実化などは継続的に必要となっていますが、安易な不具合を防げた場面では、不安を抱えた中でのリリースも減り、QAスタッフの心理的安全性も高まったと思います。

どのような成果が得られたか

MagicPod導入時に作成した初期のテストシナリオでも十分に活用可能ではありますが、cssセレクターやxpathの理解を深めるための勉強会を開催することで、失敗しにくく、メンテナンスしやすいテストシナリオが作成可能になりました。
必要性に追われた結果となりますが、htmlの構造の理解が各QAメンバーで深まったこともあり、導入以前と比較し、より有効なテストの策定や、導入前には見つけられなかった不具合の報告が可能になったことは望外の収穫となりました。
QAメンバーにとって新しいチャレンジになりましたし、作成した分だけ効果が実感できること、また実際に不具合を検出することで、良い循環でモチベーションを上げて作業に取り組むことができています。

誰でも使用可能で直感的に操作可能ではあるが、チェック手順や観点を分解して思考しきれないスタッフが作成したテストシナリオは、レビューと改修に時間を要する為、自動化していく以前にテスト観点・項目の作成を自己完結できるくらいのスキルは必要でした。 また、既存のテスト項目とMagicPodのテストシナリオにテスト順などの整合性を持たせる為、見直しを行う必要もありました。

本格運用後に大幅なUI刷新が発生した場合、早い段階でメンテナンスやシナリオ追加しないと不具合検出に遅れが発生してしまう為、まとまった時間の確保に苦心するタイミングがあります。

QAが繁忙で、テストシナリオ作成やメンテナンスに十分に時間を割けられない体制である場合、数ヶ月単位のアウトプットでは必要なボリュームのテスト作成は不可能だと実感しています。
プロダクトのボリュームや実現したい内容にも依りますが、導入時の数ヶ月間は1人月をかけるくらいの気持ちで臨める体制が理想です。 もちろん、1〜3時間/日を1〜2名で続けるだけでもある程度の成果は出てきますが、早期に効果を実感したい場合、QA体制の見直しから入る必要があるかもしれません。
ただし、導入時の初期目標は低めに設定することで、考え方が「プラスαで何を強化できるか」で思考するようになるので、当面のノルマはできるだけ低く見積もることをオススメします。

なお、スクリプトやプログラミングを軽く齧ったことがあるメンバーが1名でもいると、MagicPodの可能性を十分に引き出すことが可能となります。そのようなメンバーがいなくても、自動化の難易度を下げ、視覚的に実装できるようにし、テスト自動化を一般化した素晴らしいサービスとなりますので、拡張性もある自動化ツールとして十分に活用できるでしょう。
既にSETエンジニアがいるチームであっても、別の自動化へとリソースが割けますので、一度試す価値のあるサービスだと確信しています。

スタンバイのTech Blogでは、QAスタッフも投稿しています。
MagicPod関連は、まだ1記事のみとなりますが、APP版の運用方法や改善方法についても、発信していく予定となりますので、ご興味がある方は是非ご一読ください。