テスト自動化のプロが集まるmablでは、mablを使ったSaaSアプリケーションテストについての質問が多く寄せられます。

  • テスト自動化に対するmablのアプローチとは?
  • mablチームのテスト戦略とは?
  • エンジニアリングチームがコードを本番環境に継続的にリリースするためにE2Eテストの自動化が果たす役割とは?

そこで、私たちは、皆さんをmablテストの舞台裏にご招待することにしました。私たちがmablをどのように使い、mablアプリケーションをどのようにテストするのか? 詳しくお見せします。皆さんのチームがE2Eテストを最大活用するためのヒントが隠れているはずです。では、はじめましょう!

mablのテスト戦略

mablでは品質保証に包括的アプローチをとっています。つまり、製品チームに関わる全てのメンバーがテストに携わる形です。これは、単体テストから探索的テストに至るまで、典型的なテストピラミッドのあらゆるレベルに当てはまります。

また、mablではなるべく自社製品を使うことにしており、自社のウェブアプリからwebサイトまで、統合やE2Eテストのために、mablの自動化をフル活用しています。

bl_behindscenes1_pyramid

mablをテストピラミッドに適用

ここでは、mablが定義するさまざまな種類のテストを紹介します。

単体テスト

単体テストの主な役割は、コードブランチ(IF ELSE文など)や関数などのコードの各ユニットが意図した通りに機能するのを検証することです。コードでコードをテストできるため、単体テストはソフトウェア開発における最も効率良い方法です。

したがって、コードベース全体において数千もの単体テストを実施し、最低でもカバレッジ90%という、やや挑戦的な目標を設けている場合もあります。単体テストに使用するツールには、React Testing Library、Jest、JUnit、Mockito、chai、mocha、sinonなどがあります。

統合テスト

統合テストは、いくつかのコード(関数、コンポーネントなど)が意図しない結果を生じず、連携して機能を満たしているかを確認するために使います。これらのテストは、Chrome拡張のmablトレーナーなど、当社がE2Eテストカバレッジを確保しづらい部分で使うことができます。

あいにく、ブラウザのセキュリティにより、拡張機能の相互アクセスができないため、mablトレーナーを使用してそれ自体に対するテストを作成できません。そのため、mabl Trainer拡張機能の統合テストを作成し実行するためにCodeceptJSを使用しています。

mabl Webアプリの場合、mablのみをテストに使います。 mabl APIの統合テストではJavaを使用していますが、mabはAPIテスト機能を開発している段階なので、リリース後に移行を開始し、いずれmablのみで完結するようになるはずです。

E2Eテスト

E2Eテストは、ユーザーの体験を一番よく反映しており、機能や外観、パフォーマンスなどの全てが意図した通りであるかどうか検証できるため、当社製品の中で最も価値のあるテストです。

単体テストがコードレベルのテストとして最も効率的であると考えられている一方で、E2Eテストはアプリケーションやサービスのユーザー体験を、包括的に検証するのに重要なテストだと考えられています。

そして、mablが本領発揮するのがE2Eテストなのです。mablを使えば、アプリのためにE2Eテストを簡単に自動化できます。mablがあれば、コードの作成、そのメンテナンス、そして手動テストの必要がありません。

トレーナーのテストにCodeceptJSが必要だった頃と違い、開発者からQA、プロダクトマネージャーに至るまで、当社メンバーの誰もが信頼性の高いテストを作り実行できます。現在mablでは、本番環境を含むCI/CDパイプライン環境の全体にわたりE2Eテストを実行するよう設定しているところです。

探索的テスト

mablでも手動テストを実行しています。多くの場合、自動化ができない探索的テストという形をとっています。通常mbalでは、チームごとにチームセッションの場を設けてアプリケーションの異なる領域を探索する形をとっています。これは、自動テストで見過ごされた問題を特定することが目的です。

結果は全てSlackの共有チャンネルによってシェアされ、セッション主催者が確認します。対応が必要な問題はJiraに記録されます。また、将来的な回帰を防ぐため、これらテストセッションで得た洞察(insight)を活用し、より優れたE2Eテストカバレッジに必要な領域を割り出します。

統合(インテグレーション)

(当たり前だと思うかも知れませんが)mablはテスト自動化の強力な提唱者です。ソフトウェア開発やリリースワークフローにより良く適用できるテスト方法を常に求めています。当社が現在提供している魅力的な統合テストを下記に紹介します。

  • GitHub Actionsによって、全てのデプロイメントにおけるテスト実行が可能になり、GitHubプルリクエストのコンテキストとしてテスト結果が表示されます。
  • Slack は該当デプロイメントのエラーをチームに通知します。また、自己修復やビジュアル変更など、mablインサイトにさらなる可視化性を追加します。
  • Jiraは、問題追跡に利用します。mablテストで問題が発見されると、mablのテスト結果ページから直接Jiraに問題を記録することができます。
  • PagerDutyは、本番環境を監視するmablテストにエラーがあった場合、オンコールエンジニアに自動通知するのに使われます。
  • Segmentは、アプリケーション全体のテスト活動に対する実用データをマッピングし、mablのテストカバレッジのギャップを割り出すのに使われます。
  • BigQueryは、より詳しいレポートと分析のために、DataStudioと重なった包括的なアプリかつユーザーデータを保存します。
  • 登録したチームメンバーに定期的に届けられるmablワークスペースレポートの送付など、追加的な通知手段としてEメールも使用します。

継続的なテストワークフロー

通常、mabl のコア機能は、Chrome 拡張機能/CLI、React ウェブアプリ、Google クラウド サービスという3つの主要部分で編成されています。アプリケーション全体をテストしますが、このセクションではWeb アプリに重点を置いて説明します。

mabl のエンジニアリング開発サイクルは、堅牢なテスト戦略に大きく依存しています。mablの開発チームは、常に既存の機能を強化しながら新しい機能を開発しており、場合によっては、アプリに100件もの変更が適用される場合もあります。

高い信頼性の完全なテストがなければ、優れた品質を維持しつつ、現在の速度でサービスを提供することは不可能です。開発チームは、E2Eテストを早い段階で実行し、できるだけ早期に問題を発見し修正するよう努めています。

bl_behindscenes2_devops

テストは開発プロセスのあらゆる段階で重要である

作成、または改善する機能を決めると、mablのエンジニアはプロジェクトのコードブランチを作成し開発を始めます。この段階でのテストは、主に単体テストと mablテストから成り立っています。

Web アプリは Reactを基盤としているため、単体テストの作成にはReact テストライブラリを使用します。エンジニアは、新しいコンポーネントと機能ごとに単体テストカバレッジを追加する必要があります。さらに、エンジニアは CLI を使用して、この機能に関連する mabl 回帰テストを実行し、共通ユーザーワークフローの問題を特定・修正します。

プロからのヒント

特定領域に絞ったテストを簡単に実行するには、特定の機能に対して mabl テストのラベルを付け、そのラベルだけでテストを実行します。

エンジニアは、機能をプロダクトにマージする前に、プルリクエストを作成します。プルリクエストでは、新機能を備えたフル機能のプレビュー環境が作られます。

これは、他のチームメンバーがフィードバックを返し、探索的テストを実行するのに最適な段階です。単体テスト全てとmabl 回帰テストの完全なセットが実行されるのもこの段階です。新しい mablテストが必要な場合は、ここで回帰のプランに追加されます。

bl_behindscenes3_screenプレビュー環境と mabl テストを使用したプルリクエストの例

フィードバック後、エンジニアは変更をメインブランチにマージします。これで、機能がmabl 開発環境の一部となりました。このマージによってデプロイメントが始まり、完全な回帰テストとスモークテストのセットなど完全なテストセットがアプリに対して実行されます。この機能が開発環境で期待どおりに動作すると、本番環境にプッシュされます。

bl_behindscenes4_pr本番環境におけるシンセティックモニタリング

本番環境でのテストをよく思わない声もありますが、当社ではエンジニアリング開発サイクルを続ける上で大切な作業だと考えています。

mabl などの現代のクラウドベースアプリケーションは、第三者サービスを利用していることが多く、本番のための機能にタグ付けする際に、当社のインフラや第三者サービスが中断しないように回帰テストとスモークテストの完全セットを実行することが重要です。更に、これら一連のテストは4時間ごとに実行され、どのような場合においても、お客さまへ迷惑がかからないよう問題を早く見つけて修正できる体制をとっています。

本番環境を監視するテストが失敗すると、昼夜を問わずオンコールエンジニアに問題発生が伝えられます。mabl の本番環境で問題が発生した時のこれらテストの効率性を確実にするために、実際に開発アプリを使い本番アプリをテストします。

これにより、二つの環境が独立して機能することが可能となり、その一方でmablチームによって本番アプリの健康状態を確認できる状況が作られます。

bl_behindscenes5_screen第三者サービスとインフラにおける問題を本番アプリで監視

またRollebarと Googleクラウドオペレーション (以前のStackdriver)を使用して、本番環境でのエラーを監視し、ログ記録します。

フィードバックが支えるフライホイール

当社チームは、テスト戦略を改善する方法を常に探しており、そのためにお客さまを中心としたアプローチをとっています。新機能を検証するテストだけでなく、お客さまから報告された問題に対応するテストも追加し、同じような問題が発生することを防ぐ努力を続けています。

フィードバックは当社の企業文化の核であり、お客さまの意見を何よりも尊重しています。製品に関する情報をお伝えし、あらゆる製品・サービスの質を向上するために、当社メンバー全員、お客さまとの絆を築くことを目標としています。

テスト改善の可能性を見つけるための別の方法にはカバレッジ機能の利用があります。この mabl 機能によって、リンククローラーとセグメント統合に基づくアプリケーションページが表示されます。顧客への最大効果を提供するためにテストカバレッジを調整できるので、当社では、最多テスト数のページに対する最多訪問数のページを特定するのにこの機能を使用します。

お客さまに役立つ主なポイント

本記事では、mablにおけるテストのあり方についてたくさんお話しさせていただきました。また、mabl を使ったmabl のテスト方法についても詳しく説明させていただきました。最後に皆さんのお役に立ちそうな重要なポイントを以下にまとめておきます。

  • テストはチームスポーツであり、あらゆる状況に万能アプローチは存在しません。
  • mablによって、高信頼性のE2Eテストを開発プロセスのあらゆる段階で実行し、問題を早期に発見し解決することが可能です。
  • mabl をワークフローツールと統合し、チーム全体に連絡が行き届くようにしたり、コラボレーションを促したり、生産性を向上させたりすることが可能です。
  • デプロイメントフェーズのテストは重要ですが、残念ながら見過ごされることが多いのが現実です。CI/CD ツールを使うことで、そのフェーズにおけるmabl テストの構築・実行が簡単になります。
  • E2Eテストのインサイトおよびカバレッジレポートによって、重要な品質ギャップ分析が提供されます。
  • シンセティックなテストを本番環境に適用することで、自分たちでコントロールできない第三者サービスを含めた回帰テストを、早期に特定することができます。

さらに詳しくはExperience 2020からの最新セッションをご覧ください。


mabl体験は初めてですか?自動テストを開発ライフサイクルに組み込んでみませんか?今すぐ無料トライアルにお申込みを!