リグレッションテストとは? コードなしのエンドツーエンドリグレッションテスト

リグレッションテストとは、アプリケーションへの変更のあとで既存のテストを再実行し、その変更によってそれまで動いていたものが壊れていないことをチェックすることです。

リグレッションテスト (回帰テスト) とは?

この言葉は「後戻り」から来ています: アプリケーションが退行し、昨日よりも今日のほうがうまく動かなくなったのです。だからこそ、リグレッションはユーザーにとって大きな不満の種になります。頼りにしていたものが、ただ動かなくなってしまうのです。

リグレッションが起きるのは、アプリケーションの各部分が、誰も意識していない形で互いに依存しているからです。共有スタイル、丸めのルール、API で名前が変わったフィールド: ある場所での小さな変更が、遠く離れた画面にまで届きます。変更した人は変更した箇所を確認しており、それは正しかったのです。破損は別の場所にあります。

リグレッションテストと再テストの違い

この 2 つはよく混同されますが、答える問いが異なります。

ユニット、統合、エンドツーエンドのリグレッションテスト

リグレッションテストはアプリケーションのあらゆるレベルに存在し、レベルごとに見える範囲が異なります。

ユニットテストと統合テストは高速かつ正確で、どのチームにも必要です。しかし、それらは開発者が考えるとおりにコードをチェックします。ユーザーは関数を呼び出したりはしません: ボタンをクリックし、合計を読み、次のページが開くことを期待します。

だからこそ、エンドツーエンドのリグレッションテストが最も重要です: エンドツーエンドテストは、ユーザーがたどるのと同じようにインターフェイスを通じてアプリケーション全体を操作し、ユーザーが見るものをチェックします。全体像はエンドツーエンドテストとは何かを参照してください。

同じチェックアウトのバグを統合テストとエンドツーエンドテストの両方から見た詳しい比較は、エンドツーエンドテストと統合テストの違いをお読みください。

機能的リグレッションテストと非機能的リグレッションテスト

機能テストは、アプリケーションが何をするかをチェックします: 注文が確定する、レポートがエクスポートされる、フィールドが空ならエラーメッセージが表示される、などです。非機能テストは、それをどのように行うかをチェックします: どれだけ速いか、どう見えるか、別のデバイスや遅いネットワークでどう振る舞うか、などです。

ほとんどのリグレッションスイートは機能的なものであり、機能的な確認が問うのは要素が存在するかどうかであって人に見えるかどうかではないので、ビジュアルやレイアウトの破損の大半はそれをすり抜けます。その理由は自動テストが見逃すビジュアルバグで説明しています。

リグレッションテストの種類と例

テスターはリグレッションテストをいくつかの種類に分けています。種類ごとに、スイートのどれだけを実行するか、そしてその理由が異なり、同じアプリケーションでも 1 週間のうちにそのすべてが必要になることがあります。

エンドツーエンドのリグレッションテストは、この一覧の中の独立した種類ではありません: テストが実行されるレベルのことです。選択型、部分、完全のどのリグレッション実行もエンドツーエンドテストで構成でき、ユーザーが見るものについては、そうすべきです。

エンドツーエンドのリグレッションスイートに入れるべきもの

すべてをカバーしようとするリグレッションスイートは、いつまでも完成せず、信頼もされません。小さく始め、壊れたら最も困るものから手を付けましょう。

1. 1

   ユーザーに欠かせないジャーニーを挙げる

   サインアップ、サインイン、検索、チェックアウト、顧客が毎週月曜日にエクスポートするレポート。5 ～ 10 件のジャーニーを、それぞれ最初のクリックからユーザーが期待する結果まで挙げます。

2. 2

   以前に壊れたものを加える

   一度でもユーザーの元に届いたバグには、気づかれないまま戻ってくることがないよう、それぞれテストを用意する価値があります。リグレッションスイートはそうやって学んでいきます。

3. 3

   画面の数ではなく、リスクで重み付けする

   すべての顧客が毎日使う画面は、10 個の設定ページより重要です。お金、データ、サインインが最優先です。

4. 4

   クリックだけでなく、結果を確かめる

   チェックアウトをクリックして進むだけで合計を確かめないテストは、ほとんど何も証明しません。各ジャーニーはユーザーが求めていたもので終わり、テストはそれを検証します: 合計、確認画面、エクスポートされたファイルです。

5. 5

   変更のたびに実行できる速さに保つ

   いくつかのジャーニーをスモークスイートとし、プルリクエストごとに数分で実行するものにします。残りは毎晩実行します。

リグレッションテストはいつ実行すべきか

リグレッションは早く見つかるほど安く済みます: 変更はまだ開発者の記憶に新しく、その上にはまだ何も積み上げられていないからです。

7 段階で進めるリグレッションテスト

最初の決定からスイートを生かし続ける習慣まで、実践のすべてを順に紹介します。各手順は意図的に短くしています: リグレッションテストはプロジェクトではなく、日常の作業です。

1. 1

   対象を決める

   リグレッションスイートが守るものを決めます: ユーザーが頼りにしている機能と、二度と戻ってきてはならないバグです。それを書き留めておけば、スイートにはそれ以外を断る理由ができます。

2. 2

   ジャーニーを選ぶ

   最初のクリックからユーザーが期待する結果までのジャーニーを 5 ～ 10 件選びます: サインイン、検索、チェックアウト、毎週月曜日にエクスポートされるレポートなどです。どのジャーニーも、その結果のアサーションで終わります。

3. 3

   ビルドのたびにスイートを実行する

   重要なジャーニーをプルリクエストまたはビルドのたびに実行し、スイート全体を毎晩とリリース前に実行するようにします。その日のうちに見つかったリグレッションが、最も安く済みます。

4. 4

   失敗を切り分ける

   何よりも先に、テストが失敗した理由を読みます: 本当のリグレッションか、意図した変更か、ノイズかです。レポートには期待結果と検出結果が並べて表示されるべきで、そうすればこれは数分で済みます。

5. 5

   修正するか、採用する

   リグレッションは、失敗したステップとその画像を添えて開発者に戻します。意図した変更は新しい期待結果として採用し、次の実行ではそれに照らしてチェックします。

6. 6

   スイートを小さく保つ

   正当な理由で失敗したことが一度もないテストは削除し、同じものをチェックするテストはまとめます。数分で終わるスイートは実行され、何時間もかかるスイートは省かれます。

7. 7

   四半期ごとに見直す

   数か月ごとに、スイートを現在のアプリケーションと比べます: 新しく加わったジャーニー、なくなった画面、ユーザーの元に届いてテストに値するバグです。

自動化したリグレッションスイートが放棄される理由

リグレッションテストは自動化すべきだという点で、ほとんどのチームの意見は一致しています。多くのチームが試み、そして多くの自動化スイートが結局オフにされるか無視されています。その理由はほぼ決まっています。

コードなしでエンドツーエンドのリグレッションテストを自動化する

GUI Test Studio は、Web アプリ、Windows デスクトップアプリ、スマートフォン、ゲームのエンドツーエンドのリグレッションテストを、インターフェイスを通じて、テストコードの作成や保守なしで行うために作られています。

各ジャーニーを一度記録する

GUI Test Runner-Recorder で「記録」をクリックし、実際のアプリケーションでユーザーと同じようにジャーニーをたどります。クリック、入力、表示された内容のアサーションがテストになります。AI アシスタントにジャーニーをプロンプトで説明して、テストを作ってもらうこともできます。

動画のように編集する

どのテストも GUI Test Studio のタイムライン上で開きます: ステップはブロックとして、アサーションはその横に、記録はその上に並びます。アサーションの変更、待機の追加、ジャーニーのステップのグループ化: コードは不要で、チームの誰でも行えます。タイムラインを参照してください。

ビルドのたびに実行する

gtr-cli は Windows のビルドマシンでスイートを実行し、パイプラインが期待する形で応答します: 失敗したテストはビルドを失敗させ、JUnit ファイルがテストタブを埋め、失敗した箇所のすべての画像が保存されます。

gtr-cli run tests\regression --countdown 0 --junit results\junit.xml --artifacts results\artifacts

TeamCity、Jenkins、GitHub Actions、GitLab、Azure DevOps で動作します。パイプラインでテストを実行するを参照してください。

本当のリグレッションか、無害なノイズか?

どの実行も信頼度レポートで終わります。アサーションごとに、要素が見つかったか、記録時と同じ見た目かが示され、期待画像と検出画像が並び、差異が枠で囲まれます。

意図した変更はワンクリックで採用

すべての差異がリグレッションとは限りません: 新しい画面のほうが正しいこともあります。信頼度レポートで、実行が検出したものを新しい期待画像として採用すれば、次回の実行はそれと比較します。ダークモードや別の言語など、意図的に異なる画面については、ベースラインが環境ごとに 1 つのバージョンを保持します。

いつ始まったかを知る

すべての実行はテストの履歴に保存されます。ジャーニーが失敗し始めたとき、履歴には最後に合格した実行と最初に不合格になった実行が表示され、2 つの実行をアサーションごとに比較できます。

すべてのブラウザーとデバイス、そしてトラッカーへのバグ登録

一度記録した Web テストは、Chrome、Edge、Firefox で、スマートフォンとタブレットで、他の言語と画面サイズで実行できます: クロスブラウザーテストを参照してください。また、失敗した実行は再現手順と画像付きの Jira の課題に自動でなります: 失敗したテストを Jira のバグにを参照してください。

要点

• 1リグレッションテストは、変更によって動いていたものが壊れていないことをチェックします。同じテストを、変更のたびにもう一度実行します。
• 2再テストは修正を証明し、リグレッションテストはその修正が他の何も犠牲にしていないことを証明します。
• 3エンドツーエンドのリグレッションテストは、ユーザーが実際に感じるものを捉えます: ユニットテストが決して見ない合計、ボタン、ページ、メッセージです。
• 4小さく始めましょう: ビルドごとに 5 ～ 10 件の重要なジャーニー、毎晩スイート全体、リリース前にすべてのブラウザーとデバイスです。
• 5スイートはリグレッションとノイズを見分けられなければならず、維持コストも低くなければ、放棄されてしまいます。

質問

OpenAI、Anthropic、Jira、TeamCity、Jenkins、GitHub、GitLab、Azure DevOps、Chrome、Edge、Firefox は、それぞれの所有者の商標です。