MagicPodの導入効果をレビューでご紹介（株式会社Skillnote）

ツール導入前の課題

MagicPodを導入する前は、リグレッションテストの自動化のためにSelenideを使ってテストコードを書いていました。

当時は、下記のような課題がありました。

• 自動テストのメンテナンスが出来るメンバーが限られていたり、メンテナンスに時間がかかる。
• その結果、新規機能開発に自動テスト作成が追いつかない。既存機能も、部分的に自動テストが無い状態。
• 開発者のローカル環境で自動テストを動かす状態だったため、「日次で実行」「デプロイごとに実行」という自動テストの習慣化ができていない。

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

• メンバーのスキルに依存せず、誰でも自動テストのメンテナンスができるようになること。
• 既存機能の自動テストが充実すること。新規機能開発に自動テスト作成が追いつくこと。
• 自動テストの習慣化が定着すること。

• Autify
• T-DASH
• mabl

• 料金
• ツールの学習コスト、使いやすさ

• 料金
  • 作成するテストケース数を限定した場合、料金が比較的安い。
  • 固定料金で実行回数が無制限なので、トライアンドエラーがしやすい。
• ツールの学習コスト、使いやすさ
  • MagicPodのマニュアルを見ながら操作すると30分程度で学習できるような、学習コストの低さ。

メンバーのスキルに依存せず、誰でも自動テストのメンテナンスができるようになった

MagicPod導入前は、自動テストのメンテナンスは限られたメンバーで行っている状態でした。

導入直後は、広めにメンバーを募り、SelenideからMagicPodへの移行を行いました。このときに関わったメンバーは、コードを書くことが少ないQAエンジニアやインフラエンジニアの方も含まれています。

その後、定期的に開発チーム全体に呼びかけて自動化できていなかったケースの拡充に取り組んだり、新入社員のオンボーディングでもMagicPodを触ってもらっています。

自動テストが習慣化した

MagicPod導入前は、自動テストはリリース前に実行するだけのことが多く、自動化しているメリットを活かせていない状態でした。

導入後は、ステージング環境で毎営業日実行しており、意図しないデグレードを早期に検出できています。

自動テストの拡充には課題あり

MagicPodを導入することで、既存機能の自動テストを充実させたり、新規機能開発に自動テスト作成が追いつくことを目指していましたが、この点にはまだ課題があります。

ツールではなく開発プロセスの課題として、開発速度を落とさず、かつテスト自動化が漏れないよう、どのように開発プロセスに取り入れるかを検討しています。

メンバーのスキルに依存せず自動テストを導入したく、ノーコードツールにフォーカスして検討していました。その点でMagicPodは使いやすく、すぐに「なんとなく使える」というレベルには達することができます。

一方で、良い自動テストを作るためには基本的な設計力やコーディング力は必要です。導入直後は、多少エンジニアリソースをかけてコアな設計やサンプルとなるテストケースを用意した上で、チームへ展開していくのがスムーズかと思います。