テスト関連イベントの追跡方法

たとえばエンドツーエンドテストが遅いと報告があった場合、すぐに原因特定できるような準備はしていますか？問題はブラウザのせいかもしれませんし、使用しているフレームワークのバージョンにパフォーマンスの問題があるかもしれません。さらに扱うサービスが数百種類に及ぶ場合、どうすればテスト範囲を簡単に追跡できるでしょうか？

このブログ記事では、New Relic自社製品と実際のデータをもとに、テストデータを収集・活用するための手順を一部ご紹介します。この記事ご紹介するテクニックと情報は、どのテストツールを使用する場合でも役立ちます。

どんなデータが必要なのか、データで何ができるのか紹介するのでご確認ください。この記事が読者やそのチームによる取り組みのきっかけになれば幸いです。

New Relicにカスタムイベントを送信する

イベントAPI を介して、さまざまな種類のカスタムイベントをNew Relicに送信できます。テスト関連のイベントにもこのAPIを利用します。APIを使うと、New Relicデータベースにデータが保存されます。New Relic Query Language (NRQL) を使えば、データを詳細に分析できるので、テストのカバレッジや実行に関する質問に答えられるようになります。

APIを使用してデータの生成を開始する3つのステップを確認しましょう。

1. データをレポートしたいアカウント用に新しいライセンスキーを生成します。
2. アプリケーションのテストランナー、APIまたはその他のメソッドがインストゥルメントされたため、イベント用のJSON を生成する。
3. 圧縮されたJSONペイロードをPOSTリクエストでHTTPSエンドポイントに送信します。

こちらはJSON ペイロードの例です。

[
  {
   "eventType": "Coverage",
   "releaseTag": "release-308",
   "repository": "your-awesome-project-repo",
   "teamId": "101",
   "Coverage": 98.77
   "Covered": 325659
   "Missed": 4055
 }
]

releaseTagやrepositoryなど属性情報のラベルはあらかじめ決まっているものではなく、必須項目のeventTypeさえあれば、送信できます。どんなデータを送れば良いかということについては、企業やプロジェクトの状況によって異なります。次のセクションでは、New Relicが自社製品に対して作成しているテストイベントを紹介するので、皆様が作成する際のヒントとして確認してください。

コードカバレッジのインサイト

New Relicでは、バックエンドとフロントエンドの両方のコードリポジトリのコードカバレッジ情報を収集しています。テスト時のカバレッジを収集できるツールに加え、New Relic CLIを使い、コードカバレッジデータをNew Relicに自動的にレポートしています。この情報は、プルリクエストをメインブランチにマージした後に送信されます。

最新の報告されたイベントを表示するには、チームは次のNRQLクエリを使用できます。

SELECT * FROM Coverage SINCE 1 month ago

コードカバレッジメトリクスを理解する

バックエンドコードカバレッジイベントで追跡する有用なデータをいくつか以下にご紹介します。

• Coverage: テストが行われたコードの割合を定量化します。コードベースのテストの完全性を示す重要な指標となります。
• Covered: テストが正常に実行されたコードの具体的なセクションをカウントします。
• Missed: テストされていない部分を指摘します。リスクが潜んでいる部分を知ることができます。
• Release tag: リリースタグを指定します。各バージョンのカバレッジを追跡しやすくなります。
• Repository: イベントを生成したコードリポジトリ名を保存します。
• Owning team: コードリポジトリを所有するチーム名を保存します。

UI体験については、次の2つの追加メトリクスを生成します。

• Unit test coverage: ユニットテストが行われたコードの割合を定量化します。
• End-to-end coverage: エンドツーエンドテストが行われたコードの割合を定量化します。

プロジェクトの目標に沿っており、テスト戦略に関する有意義なインサイトが得られるカバレッジメトリクス (命令や行など) を選択することが重要です。

Playwrightエンドツーエンドテスト: 重要メトリクス

当社では、Playwrightを標準のWebエンドツーエンドテストフレームワークとして使用しており、New Relicにテスト実行のイベントを保存しています。ここではさらに興味深いイベントを追跡できます。

エンドツーエンドの各イベントで追跡する有用なデータをいくつか以下にご紹介します。これらすべての情報を駆使することで、ダッシュボードの改良やフィルタリング、他のテーブルとのデータ統合などが可能です。

• Annotation: テスト注釈。これは、フィルタリングや遅いテストの検出などに役立ちます。 
• Base URL: テストを開始するために使用されたURL。
• Browser name: テストを実行したブラウザ名。
• Build number: テストが実行されたアプリケーションのビルド番号。
• Duration: テストケースの期間。
• Environment: 実行環境 (開発、ステージングなど)。
• Error message: エラー (またはそのサブクラス) がスローされたときに設定されます。
• Error stack: エラー (またはそのサブクラス) がスローされたときに設定されます。
• Error value: スローされた値。エラー (またはそのサブクラス) 以外の何かがスローされたときに設定されます。
• Outcome: テストケースの結果。
• Playwright version: テストの実行に使用されたPlaywrightのバージョン。

各データの活用方法

テスト関連データを揃えることは手順の一部にすぎず、重要なことは、私たちのチームがそれをどのように活用するかということです！これらの情報はすべて、New Relicのダッシュボードに集約され、みんなで共有しています。参考になりそうなユースケースをいくつかご紹介します。

データによるFlaky testの軽減

Flaky testとは、非決定論的な動作を示すテストとして定義されます。つまり、テスト対象のコードやテストコードを変更していないのに、複数回実行すると合格または不合格になるようなものを指しています。

Flaky testは、開発者の貴重な時間やテストを行うための計算資源に大きな影響を与え、テストの信頼性を損ないます。

そこで私たちは、Playwriteのテストケースの結果をトラッキングしています。Playwrightのテストケースの結果には次の値があります：

testCase.outcome(): "skipped"|"expected"|"unexpected"|"flaky";

2回目の再試行で合格したテストは「Flaky」であるとみなされます。この結果を追跡すれば、どのテストがFlaky testなのかをすぐに特定できます。このデータを取得するのが、テストを制御するための第一歩となります。たとえば、次のクエリを使えば、Flaky testがブラウザの種類によって発生しているものかどうかを確認できます。

SELECT percentage(count(*), WHERE (outcome = 'flaky')) FROM E2ECoverageReport LIMIT MAX FACET browserName

クエリを次のように変更すると、Flaky testの発生が一時的なものなのか時系列のトレンドがあるのかを確認することもできます。

SELECT percentage(count(*), WHERE outcome = 'flaky') FROM E2ECoverageReport FACET browserName TIMESERIES SINCE 1 year ago LIMIT MAX

当時、Flaky testを減らすためにアクションを行ったのですが、Flaky testが期待通りに減ったのかを視覚的にも確認ができました。

E2Eテストパフォーマンスの向上

E2Eテストを可能な限り高速に実行し続けること、つまり継続的なインテグレーション、継続的なデプロイメント (CI/CD) パイプラインを維持することが重要です。CICDパイプライン維持のためにできるアクションは、テストの最適化やテスト実行の並列化など複数あります。改善の結果を測定/検証するには、実行時間を追跡することが必須です。

実際のデータを確認してみましょう。次のクエリようなクエリで E2Eテストの実行時間を確認できます。durationはミリ秒単位の合計実行時間を指します。

値を計算するための平均、中央値、パーセンタイルなど集計関数を利用します。

FROM E2EStats SELECT average(duration / 1000) as 'avg test time (secs)', median(duration / 1000) as 'median test time (secs)', percentile(duration / 1000, 95) as 'percentile test time (secs)' WHERE repoName \= 'ono-sendai-test' FACET browserName SINCE 1 month ago

私たちの組織における成果の例:

テストインフラストラクチャをAmazon EC2 C5からC7iにアップグレードしたところ、Playwrightテストスイートの実行時間が大幅に改善しました。この変更により、同様のコストを維持しながら30%の速度向上が実現しました。テスト中のデータにアクセスできるため、問題を特定し、改善を測定することが容易になりました。

リーダーシップのためのデータドリブンガバナンス

複数のチームを抱えている場合でも、データがあればテスト品質を容易に確認できるようになります。サービスが小さいうちは問題ないかもしれませんが、組織化していくと、データを一元的に視覚化できるだけでも非常に役立ちます。コードカバレッジをチームごとに比較したり、品質を上げるチームの優先順位をつけるなど、テストへの投資を増やすかどうかについて情報に基づいた決定を下すことができます。結果として、インシデントの減少、リスクの軽減、リードタイムの短縮、変更失敗率の低減が期待できます。

カスタムダッシュボードでチームを強化

複数のチームを管理するプラットフォームチームとしては、複数のチームが利用できるようにデータとダッシュボードを準備することが必要です。データを1か所にまとめて素早く参照できるようにしておけば、権限委譲やコラボレーションがスムーズになります。たとえば、テンプレート変数を使用して、チーム、リポジトリ、サービス別にフィルタリングできるダッシュボードを作ることができます。また、ダッシュボードそのものをテンプレート化しておけば、チームが独自のニーズに合わせて、より具体的なダッシュボードを構築することも可能です。

構築に関するベストプラクティスや一般的な落とし穴については、このブログ記事では取り上げません。この詳細については、ダッシュボードのドキュメントを参照してください。

テスト、オブザーバビリティ、DevOps の相乗効果

ソフトウエアライフサイクルの全ての段階でオブザーバビリティを実践していくことは可能です。テストも例外ではありません。カバレッジ、Flaky test、パフォーマンスを追跡することで、データドリブンでテストを改善していくことができるようになるでしょう。 実際、テスト、オブザーバビリティ、DevOpsには強い相関関係があります。この概念はTOADという頭字語で知られています。TOADの詳細については、Chris McMahonが執筆した一連のブログ記事を参照してください。

テストでオブザーバビリティを実践できれば、大きなメリットがあるでしょう。シンプルなデータではあるもののコードの品質や堅牢性の強化に役立てるはずです。まだ始めていないのなら、今からでも始め手みませんか？このブログ記事の内容が、皆さんやそのチームがこの取り組みを開始したり、改善を続けたりするきっかけになれば幸いです。