クロスブラウザテストの実装と自動化のポイント

TOP
コラム
クロスブラウザテストの実装と自動化の

概要

クロスブラウザテストは、WebサイトまたはWebアプリケーションがさまざまなブラウザでどのように機能するかを評価するテスト手法です。本記事では、クロスブラウザテストの実装と自動化のポイントについて紹介させていただきます。

実装方法

クロスブラウザテストの実装についていくつか説明させていただきます。
最初のステップは、ジョブに最適なツールを選択することです。考慮すべき有料のオープンソースクロスブラウザテストツールはいくつかあります。選定の際のポイントは以下の通りです。

一点目が主要ブラウザのサポートです。ツールでテストできる実際のブラウザの数は非常に重要です。ほぼすべての主要なブラウザ、特にトラフィックのほとんどを生成するブラウザをテストできるツールを選択することが推奨されます。
二点目がサードパーティの統合です。ツールは Jenkins、Nightwatch、およびその他の既存のシステムと統合することが必要となります。継続的インテグレーションは、テストツールからの結果と洞察を使用してWebアプリケーションに変更を加えることができるようにするために不可欠です。
三点目がテクニカルサポートです。ツールにはテクニカルサポートも付属しています。行き詰まった場合は、助けを求めることができるはずです。
四点目がレポートです。ツールは、テスト結果のわかりやすいレポートを生成する必要があります。これらは、Webアプリに必要な修正を決定するために必要になります。
五点目が並列テストです。多くの環境の組み合わせをテストするには、並列テスト機能を備えたツールを選択する必要があります。この機能は、ほとんどのクラウドベースのツールに含まれています。現在のワークフローがあるので、おそらく、テストするブラウザーの組み合わせ、オペレーティングシステム、およびデバイスを強調する戦略もあります。
手作業をクロスブラウザテストツールに置き換えれば、準備は完了です。

自動化のポイント

自動化におけるポイントについて説明させていただきます。

明確な区別

まずは、明確な区別が重要です。
すべての自動テストを毎回実行する必要はありません。たとえば、バグが修正された場合、バグが存在しないことを確認するために回帰スイート全体を実行する必要はありません。代わりに、関連する機能と、この機能に何らかの依存関係を持つ隣接モジュールを直接テストするテストを実行します。これは、自動化されたテスト内で明確に区別する必要がある場所です。通常、特にCI/CDパイプラインでは、次の3種類の自動テストを実行します。

一点目が高レベルの自動化テストです。高レベルの自動テストはコードのチェックインごとに実行され、システムの重要な機能が期待どおりに機能していることを確認します。これは、UI、API、および単体テストの混合である可能性があります。これらのテストの目的は、システムに関する迅速なフィードバックを得ることです。
二点目が毎日の回帰テストです。毎日の回帰テストにより、システムに追加された新しい機能が既存の機能を壊していないことが確認されます。これらは、システムのエンドツーエンドフローをカバーするという点で、スモークテストよりも詳細です。通常、少なくとも1日に1回実行され、リリース前に複数回実行されます。
三点目がスプリントレベルのテストを実施することです。これはスプリントの一部として新しく作成されました。スプリント中に新しいテストが完了すると、毎日の回帰テストに追加されます。
これらは通常、回帰テストフェーズで回帰テストスイートにマージされます。

チームに合ったツール選択

ツール選択も非常に重要です。
開発プロセスのさまざまな段階で自動テストを実行するために使用できるツールやフレームワークは多数あります。これは、テストがCI/CDパイプラインの一部としてトリガーされる場合に特に当てはまります。
一般的なCI/CDツールには、Travis CI、Jenkins、CircleCIなどがあります。ただし、選択するツールがチームのスキルセットに適合していることを確認することが重要です。操作が難しすぎるツールはかえってチーム全体の効率性を下げるため、自動テストの実行に使用するツールを共同で決定する必要があります。

目標を定義する

チームが自動化ツールを採用する準備ができていることを確認することも重要です。
それらは、必要なリソースの割り当て、テスト自動化ソリューションの分析、潜在的なベンダーの特定、概念実証の実施といった様々なポイントが必要です。

テストカバレッジ

テストカバレッジに関する理解も非常に重要です。
自動化されたテストは、さまざまなタイプの欠陥を定期的に検出するのに適していますが、考えられるすべてのシナリオをカバーすることはできません。探索的テスト、リスクベースのテスト、ユーザビリティテストなど、手動のテストアプローチで補完しなければならないテストが常に存在します。たとえば、ルックアンドフィールなど、アプリケーションのレンダリングの問題を検出するために自動化を使用することは理想的ではありません。
視覚的な検証を行うツールはいくつかありますが、手動と置き換えるのは困難です。自動化されたテストを実行する時期と理由、および得られるカバレッジの種類について、現実的である必要があります。

一部のチームは他のチームよりも大きく、一部のアプリケーションはより複雑になる可能性があり、組織の規模は大企業から新興企業までさまざまです。ただし、何があってもプロセスは同じです。チームは、CI/CDパイプラインの一部として自動テストを編成および実行するために、共同作業を行い、一連のリズムを把握する必要があります。
これらの自動化されたテストをいつ、どのように実行するかを知ることで、チームを成功に導くことができます。

スモールスタート

各テストは小さく、1つの特定の機能をテストするという目的を持つ必要があります。
相互に依存するテストを作成しないようにする必要があります。さらにこれにより、アプリケーションコードを調べなくても、テストが失敗した理由を正確に知ることができます。目標は、テストの任意のグループを選択して、任意の順序で実行できるようにすることです。これが不可能な場合は、テストの分割を検討する必要があります。

定期的な実行

テストを作成したら、定期的に (できれば毎日、または少なくとも毎週) 実行する必要があります。
さらに新しいコードがブランチにチェックインされると、テストが自動的にトリガーされるように準備する必要があります。同じテストを複数回実行すると、それに関する多くの情報が得られます。テストの開始から終了までの平均実行時間、テストに合格した回数、テストの実際の機能、テストの方法と方法などです。テストがトリガーされたとき、およびその他の有用な情報を取得することは何よりも重要と言えるでしょう。

不安定なテスト

テストを実行する回数に基づいて、特定のテストが不安定かどうかを判断し始めます。
具体的には、ページの読み込み時間、アサーション、不良データ、環境の問題、同期の問題など、さまざまな理由で失敗する可能性があります。同じテストが断続的に成功したり失敗したりする理由を分析します。テストを特定の方法で動作させるフードの下で何が起こっているのかという点について判断する必要があり、さらにどのような種類の障害が繰り返し発生しているかというパターンを見極める必要があります。これは、エラーログをチェックして、失敗を理解することと同じくらい重要です。さらに不安定なテストを分離することも大切です。
失敗したテストの分析が完了したら、不安定なテストを安定したテストスイートから分離します。テストが断続的に失敗するからといって、他のすべての安定したテストが実行されるべきではない、または一連のテストを実行するたびに失敗したテストレポートが表示されるという意味ではないため、注意が必要です。自動化テストの結果を真剣に受け止め、自動化が付加価値をもたらしていることを信頼できるように、テストを可能な限り正しく分析する必要があります。したがって、断続的な障害に気付き始めたらすぐに、不安定なテストを残りのテストから分離する必要があります。その後修正を実行します。

ソフトウェアテストエンジニアが犯すよくある間違いの1つは、多くの不安定なテストを取り出して一度に修正と実行をし、効率を上げようとすることです。障害の根本原因を突き止めて恒久的な修正を作成するのが難しいため、これには実際にはより多くの時間がかかります。一度に1つずつ不安定なテストに取り組み、さらにテストに他のテストへの依存関係があるかどうかを確認します。一部のコードにコメントを付け、必要に応じてprintおよびwaitステートメントを追加し、ブレークポイントを追加し、ログを常に監視することにより、問題の根本原因をデバッグします。

安定したテストスイートに戻す

不安定なテストを修正したら、複数回実行して合格することを確認します。
一貫して正常に実行されたら、修正されたテストを安定したテストスイートに戻します。 安定したテストスイートを複数回再実行して、予期しない結果が発生しないことを確認します。これらのアプローチに従うと、安定性を確保しながら自動化されたテストスイートをスケーリングするのに役立ちます。
いうまでもなくテストの自動化は、継続的なテスト、DevOps、およびCI/CDパイプラインにとって重要です。チームは、テストが自動的にトリガーされるように設定し、開発プロセスの早い段階で欠陥を発見するのに役立ちます。

組織は、長期的には時間、コスト、および労力を節約することを期待して、自動化に多額の投資を行います。残念なことに、自動化されたテストの開発中にチームが興奮することがよくありますが、スイートが大きくなるにつれて、不安定なテストの問題に気づき始め、それらの維持にかなりの時間を費やさなければならなくなります。その結果、自動化は優先度の低い作業になり、誰も不安定なテストに対処したくないため、テストは再び完全に手動に戻ります。これはほとんどの企業の現実ですが、考え方や取り組み方次第で改善の余地は十分にあると言えるでしょう。

改善について

自動化における改善について理解することも非常に重要です。ポイントをいくつかにわけて紹介させていただきます。
一点目が孤立せずに協力することです。開発者が何らかのレベルの単体テストを行っている場合は、コードを書いている人とコードを実行している人の間で会話が必要です。テスト環境に到達すると、新しい環境での同じ単体テストの健全性チェックにより、動作の最初のレベルの確認が得られる可能性があります。失敗した場合は、失敗したコードを取得して修正します。その後、再度テストします。次に、コードを実行する人々は、動作のより深いレベルの評価を行うことができます。
リンク、ドロップダウンリスト、他のモジュールとの通信、応答コード、ログ内のメッセージ (アプリケーション、DB、システムなど)、および通常のテストの内容を確認します。さらに受け入れ基準と要件を確認し、それらが適切に処理されていることを確認する必要があります。また、呼び出されなかった可能性が高い例外を確認し、「要件」と「受け入れポイント」についても理解が必要です。

二点目が機能と流れに注目することです。少なくとも多くの人が実行するレベルまで、ソフトウェアが意図された変更に対応していることを合理的に確認する必要があります。また、ソフトウェアの使用目的を確認することも重要です。
多くの場合、要件や受入基準に含まれておりません。可能であれば、ソフトウェアがどのように使用されるか正しく把握するために、関係者とコミュニケーションを取る必要があります。
さらに、内容を実行するためのシナリオを作成し、それを一緒に確認します。どのようなニーズに対応しているのかを確実に理解できるように、ソフトウェアが何をするかを明確にする必要があります。
これらのスクリプトを作成して結果を確認したシナリオには、重要な目的が1つあります。
それらは、テストすることになっているソフトウェアを通過する主要なビジネス「フロー」を定義することです。これが完了すると、実際の顧客にとって意味のある一連のテストシナリオが作成されます。

三点目が適切なテストを自動化することです。意味のあるテストシナリオができたので、これらのスクリプトを自動化します。
多くの手動介入 (カードのスワイプなど) を必要とするシナリオを自動化する場合は注意が必要です。画像ベースのReCaptchaなど、自動化に抵抗する機能のテストの自動化は避ける必要があります。機能が比較的安定し、合格/不合格の基準が明確になるまで、テストの自動化を待ちます。

指標

自動化において重要な点が指標です。
つまり、どういった点を指標に設定し、自動化の成功を測定するかというポイントとなります。具体的な指標に落とし込むことで、経営陣やビジネス部門のチームメンバーとより戦略的なテストを実行することが可能となります。いくつかの指標について解説をさせていただきます。

テスト数

指標の一つが完了したテスト数です。
これは単純ですが最も重要な指標です。 完了したテストの総数とその結果 ( 合格、不合格、不確定など)の基本的な集計は常に測定し、保持する価値があります。これらは、自動化されたテストと自動化されていないテストの両方、およびユーザーインターフェイス (UI) とアプリケーションプログラミングインターフェイス (API) の両方の要件を合計することが重要です。たとえば、自動化プロジェクトによって1日または1週間に完了したテストの総数が減少した場合、何かしらの理由があることは理解できるでしょう。このような数値を管理することで自動化の改善を行っていく必要があります。
また、節約された時間や検出された欠陥の割合など、一部の指標は簡単にスコア付けすることが可能です。これは、組織が指標の一つとして採用しやすいものです。完了したテストカウントカテゴリのタイムチャートは、この種の成績とは別に考える必要があります。完了したテストの数は、フォローアップの質問につながる範囲で価値があります。
手動テストで、数字が変化しているにも関わらず突然欠陥が見つからなかったのは、一定の傾向がありますし、これらには時間がかかります。一方で、自動化テストにおいては根本原因を共有する欠陥の報告を管理するための優れた指標として機能します。

テスト時間

テスト時間をどれくらい削減することができたかという点も指標の一つです。
自動テストを構築する主な理由の1つは、貴重な手動テストの労力を節約することです。自動化されたテストは平凡なテストタスクを繰り返しますが、テスト担当者は、より重要で優先度の高いタスクに集中し、アプリケーションの調査に時間を費やし、自動化が難しく広範な批判的思考を必要とするモジュールをテストできます。節約されたテスト時間は、チームに提供される価値を評価するための優れた指標です。これらの削減されたテスト時間を追跡し、伝達することで客観的な数字の把握が可能となります。

軽減されたリスクの数

テストは、リスクに基づいて優先順位を付ける必要があります。
これらは、ビジネスに影響を与える予期しないイベント、アプリケーションの欠陥が発生しやすい領域、またはプロジェクトに影響を与える可能性のある過去または将来のイベントである可能性があります。 リスクに関連して自動化の成功を測定するための適切なアプローチは、優先度の高いものから低いものへとリスクをランク付けすることです。

次に、リスクの優先度に基づいてテストケースを自動化し、自動化されたテストによって軽減されたリスクの数を追跡します。リスクベースのテストの考え方は非常に重要です。これは、リスクを軽減し、それに応じてテスト作業に優先順位を付けることに重点を置いたタイプのテストアプローチです。これには、ソフトウェアの複雑さ、顧客への影響、および生産上の問題の履歴に基づいてリスクを評価することが含まれます。

最後に、各モジュールに必要なテスト作業のレベルを決定するリスクスコアに到達します。
たとえば、2つの要件をテストしているとします。要件Aは、顧客がWebページ経由で支払いを行えるように支払い機能を構築すること、要件Bは、Webページ全体のフォントサイズを14から16に変更することです。
要件Aが正しく実装されていないとサービスの支払いがまったく行われない可能性があるため、ビジネスと顧客に大きな影響を与えます。これは、莫大な経済的損失と悪い顧客体験につながる可能性があります。しかし、仮に、要件Bが期待どおりに機能しない場合、それは問題ですが、顧客またはビジネスは経済的な影響を受けず、顧客に気付かれないことさえあります。

したがって、上記の要件をテストするのに3日間ある場合は、要件Aのテストに大部分の時間を割り当て、残りの時間を要件Bのテストに割り当てる方が理にかなっています。このようにして、テスト作業に優先順位を付けることができます。
これはわかりやすい例ですが、実際のサービスにおいてはさらに複雑な例が頻発します。
リスク分析の実施は以下のように実行します。
テストするさまざまなモジュールをターゲットにする、各モジュールに関連するさまざまなリスクの特定を行う、本番環境の問題の影響、複雑さ、および履歴に関連するスコアの収集を行う、という方法です。さらに、リスクスコアの計算も重要です。その後実行するさまざまな種類のテストと、リスクスコアに基づいて、各モジュールにどれだけの労力を費やすべきかを特定することが大切です。

リスク分析

リスク分析を行うと、次のようなことが特定される可能性があります。
一点目がリスクの詳細です。リスクの潜在的な問題とその影響についての直接的で簡潔な内容を理解できます。二点目が影響評価です。
ビジネス担当者による、顧客への潜在的な影響の重大度評価であり、一般的に5段階で評価できます。
三点目が技術的評価です。モジュールで問題が発生する可能性について、実装の複雑さ、チャーン、依存関係、またはその他の技術的側面に基づいたソリューションアーキテクトまたは技術リーダーによる段階的評価を実施します。

EMTE

EMTE (Equivalent Manual Test Effort) は、ソフトウェアの品質保証 (QA) における「古典的な」概念であり、今でも広く議論されています。
EMTEは主に、「この自動化プロジェクトの後の方が、開始前よりもうまくいっているか?」などの質問に答えるのに役立ちます。これは、自動化の利点について非常に簡潔に理解できます。コストあるいはその他の論点を明確にすることは重要で、管理者は人々が自動化に時間を費やしていることを認識しています。しかし、この自動化の利点を関係者にとって可視化しなければ、最終的に自動化を選択しないなど、チームにとって最適でない結論となるケースさえあります。

カバレッジ

カバレッジも重要な指標です。
カバレッジは「多いほど良い」という単純な解釈を認めているように聞こえますが、この測定値の価値の多くは、時間をかけて注意深く観察することにあります。ソース行と要件数の観点からカバレッジを区別します。自動テストと手動テストが独自に処理するカバレッジのレベルに関係なく、それらを合わせて100%のカバレッジを包括的に保証する必要があります。要件のカバー率のスコアは、ユーザーストーリーに直接関係しています。これらのユーザーストーリーの観点から、カバレッジ結果をビジネスチームメイトに強調します。

テストケース数

テストケース数も一つの指標です。
ただし、一定数の自動化されたテストがあれば、自動化の取り組み全体が成功する訳ではありませんので注意が必要です。自動化されたテストケースの数は、得られる価値よりも費やされた労力について正しく理解する必要があります。また、重要な点は品質の違いを正しく理解し、それらを数字化し、指標として判断する必要がある点です。

欠陥数

見つかった欠陥の数も重要な指標です。
自動化されたスクリプトによって検出された欠陥の数を成功の尺度として使用することも、慎重に解釈する必要があります。
たとえば、自動化スクリプトが10個の欠陥を検出した場合、開発者が正しく仕事をしなかったことを意味している可能性があります。欠陥が見つからない場合は、自動化スクリプトが効果的ではなかった可能性があります。これらの結果を解釈するには、複数の方法があります。検出された欠陥の数と自動化されたテストケースは、さまざまな解釈が可能です。注意深く分析しなければ、チームの考え方を、自動化されたテストによって提供される真の価値から、誤解を招くような目標やベンチマークへと簡単に変えてしまう可能性があります。

まとめ

いかがでしたでしょうか？
クロスブラウザテストの実装と自動化のポイントについて詳しく解説させていただきましたので、参考にしていただけましたら幸いです。