6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MagicPodのトライアル期間を終えて

Last updated at Posted at 2023-11-02

自己紹介

  • QAエンジニアとして10年以上
  • SIer>第3者検証>SaasシステムのQA色々>CAPSでQA といった感じの経歴です。
  • mablは使用経験あり(導入時期には関わっていません)、Autifyは未経験です。

どんな人に読んでもらいたいか

  • MagicPodに限らず、テスト自動化ツールの導入を検討している方

  • テスト自動化ツールの導入前の準備やトライアル期間にどんな作業が必要かを悩んだり、不安に思っている方

    • テスト自動化ツールってたくさんあるけど、どんな基準で何を使えばいいんだろう・・・
    • トライアルに向けてどんな準備が必要で、何をすれば良いんだろう
    • 今一歩、テスト自動化ツールの導入に向けた足取りが重たい方
    • 社内にQAエンジニアが1名しかいないのに自動化推進を迫られている方

概要

  • 結論から言うと、弊社では「MagicPod」を導入しています。
    勿論、さまざまな参考文献やセミナーでも見たり聞いたりする、
    • AIによる自動修復
    • 直感的でシンプルなUI操作
    • クラウド・ローカル共にテスト可能
    • 機能の豊富さ

なども魅力的でしたが、個人的には、

  • ネット検索での情報の豊富さ
  • ユーザーコミュニティへの参加
  • 何より、サポート体制の充実さ(参加したセミナーでもよく耳にした)
    が導入の1番の決め手でした!

本文では、「MagicPodの導入前」や「トライアル期間中」に取り組んだことをまとめています。
個人的に、「トライアル開始前」や「トライアル期間中」にフォーカスされた参考文献を見る機会が少なかったこともあり、需要を見込みつつ書いてます。同じような境遇の方の参考になれば幸いです。

背景

  • テスト自動化ツールの導入に向けた背景としては、どの会社でもよく聞くような「品質とテストに対する課題」がきっかけとしてありました。

課題

  • これまで十分なテストができていなかったこと
  • そもそもテストする文化がなかった
  • デグレが起きやすい
  • 既存バグ、潜在バグが多い

対策

  • QAとして、「品質の現状」と「QA1名というリソース」からどのようにして品質と向き合うべきかを考えたとき、QAの作業方針のようなものを立てました。(QA1名体制のため自分に言い聞かせましたwww)
    • QCDのバランス(ベストは目指さず、過剰品質の回避)
    • システム全体の最適化
      この作業方針に対して、現時点では「テスト自動化」を活用して、リリース前後や定期的なテスト自動化実行により最低限の疎通レベルが通る品質保証を目指すことに決めました。

MagicPodのトライアル前の1ヶ月間に取り組んだこと

  • 事前に、自動化ツールの候補は「MagicPod/Autify/mabl」の3つに絞り込む
  • 最初に実践したことは、社内に有識者が不在だったため、テスト自動化ツールに関連するセミナーに参加しまくりました。(情報収集)
    • 製品紹介・ツール比較、ツール導入事例、失敗しないための自動化のコツ など
  • 次に課題管理作成
    • トライアル期間中に課題解決に向けて動いてもらえる開発エンジニア(FE)2名のリソース確保(関係者への根回し)
    • 課題は主に実装面(ソースコード)と環境面から考えて、MagicPodの実装でつまずきそうな箇所を事前にリスト化
      • 実装面
        • 異なるドメイン間や外部機能の連携箇所に注視
            • reCaptchaなど
        • レガシーで単調な作り(登録・予約機能周り)
          • 認証
          • カレンダー選択(画面上にカレンダーを表で生成・画面ごとに異なる作り方)
          • 表(文字数が増えると裏側で崩れる)
        • ロケーター など
      • 環境面
        • 弊社は開発・QA共用環境オンリーで、一般的に言うところのテスト環境が存在しなかったため、従来のリリースまでのサイクルに影響が出ないことも考慮していました。
    • テストデータの作成と命名規則やENGさんへの割り当て
  • あとは、シナリオテスト(リグレッションレベル)のテスト設計
    • テストマップのようなものを作成して、主要な画面・機能を俯瞰・可視化
    • 共通部品化できるところの目星をつける(部品化はトライアル後に取り組む)
    • それらをもとにテスト設計を進める

トライアル期間中に取り組んだこと

  • 開発エンジニアの方達には課題管理表に記載した課題の解決に専念してもらうよう努めてもらう
  • QAは上記で作成したテスト設計をもとにMagicPodでドンドン、テスト実装(課題部分はskip)を進める
  • 定期MTGの開催・slackでの情報連携は随時
  • MagicPod社のサポート窓口への問い合わせ
    • 技術面や操作面での問題解決、契約面などで大変お世話になりました
    • 自動化知識に明るくなく、QA数名体制のような企業では最適解を得るまでのスピードが圧倒的に速いと思います
    • めちゃくちゃ問い合わせしました。サポートの皆さんには、真摯に・ご丁寧に・的確にご対応いただき感謝しかありません!
  • 本契約を進める上で、プランについて質問事項をまとめてご回答いただきました

トライアル後に取り組んでいること

  • トライアル期間中は「優先度:高」の課題に対して開発エンジニアの方々に支援いただいたので、
  • そのほかの課題に対しては、自動テストの実装と並行して、課題解決に取り組んでいます。

トライアル期間中に発生した問題

  • MagicPodと社内環境のVPN接続問題が発生しましたが、弊社内の都合により問題解決まで1週間ほどトライアルを中断させていただきました。
    このようなイレギュラーな対応にも柔軟に対応をしてくださり、トライアル期間を有効活用でき、契約を決める上で社内的にも印象が良かったと思います。

    ざっと、トライアル終了まではこんな感じで進めていました。

総括

トライアル開始前からトライアル期間中、多くの人に支えられて(多分これからも支えられることは間違いない)MagicPodの導入を無事迎えることできました。
トライアルを振り返ってみて、ツールの評価をするべきなのに、結局のところ、MagicPod社の「人」が決め手となりましたが、そんなものなのかもしれません!

個人の見解としては、
どのツールを選ぶかより、どうやるかが重要で(MagicPodさんに失礼かも・・)
何をするかより、誰とやるかが大事だと思っているので!

どこの会社さんのテスト自動化ツールを使用しても手順は違えど、
「実現できるテスト内容」は近似しているのかなぁ?と思いました。
自分は「自動化ツール」や「コスト」だけではなく、MagicPod社の「サービス」が好みに合ったんだと思います。

もし、テスト自動化ツールの導入を検討されている方がいらっしゃるようでしたら、MagicPodのトライアルを試していただくことを強くお勧めします。

また、MagicPodにおける「ユーザーからの要望」を追加・改善予定の機能として、リスト化されているのも拝見しました。
こういった仕組みが可視化されている辺りも魅力の1つに感じました。
今後、弊社システムの品質改善を推進していく上で、MagicPodの自動化ツールが更なる成長・進化を遂げることも期待しています。

6
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?