QAがPull Requestから影響範囲を調べてリグレッションテストを実施している話

QA

はじめに

初めまして。QAチームの三木と申します。

commmuneモバイルアプリのQAを担当しており、入社して7ヶ月が経ちました。

モバイルアプリチームでは、新機能開発だけでなく既存機能の改修や不具合修正を日々並行して進めています。
特に、「既存機能の改修や不具合修正」は小さい単位で行われるため、その変更起因で意図しない箇所に新しい不具合が発生する可能性があり、リグレッションテストでの確認が必要です。
現状、モバイルアプリのテストはほとんどが手動テストのため、リグレッションテストも手動で実施しています。

今回は、「意図しない不具合」をなるべく減らすために、影響範囲をどのように調べているかについて書きます。

リグレッションテストの定義

まず、リグレッションテストの一般的な意味や目的を定義します。

システムに対する修正や変更によって、意図せずに振る舞いに影響を与えることがある。
そういった意図しない副作用を検出することを目的としたテスト。

変更箇所以外で意図しない影響が発生していないか、確認するテストです。

影響範囲の調べ方

変更ごとに、以下の流れで影響範囲を調べてテストを実施します。

  1. 機能改修や不具合修正を実装後、mainブランチにマージ
  2. テストを実施するタイミングでmainブランチからビルドを作成
  3. JIRAチケットとGithubのPull Requestを参照
  4. 主目的である変更内容のテストを実施
  5. 影響範囲を調べて、リグレッションテストを実施

5.では影響範囲を推測するための情報を探します。
この時、Pull Requestの情報から意図しない箇所への変更や考慮漏れに気づく場合があります。
実際の例で、いくつか紹介しようと思います。

①ソースコードの差分から影響範囲に気づく

具体的には以下のようなケースで影響範囲に気づくことがあります。

  • 要件には記載のない箇所に修正が入った場合
    • 処理を共通化する、などリファクタリングが行われていて他の画面にも修正が入っていた
  • 過去に実装した処理に変更を加える場合
    • 分岐を増やす
    • 特定の条件では処理を無効化する

後者について、具体例で詳細を説明します。

まず、エラーハンドリングが原因で発生する不具合がありました。
そのため、不具合が起きる条件ではエラーハンドリングしない方針で修正を行いました。

  • 修正前
    • 「条件A」の場合にエラーハンドリングをする
  • 修正後
    • 「条件A、かつ、条件B」の場合にエラーハンドリングをする
      • ＝条件Aだが条件Bではない（不具合が起きる）条件ではエラーハンドリングしない

これにより、不具合の解消を確認できました。

しかし、修正後だと「条件Aだが条件Bではない」場合にエラーハンドリングしなくなるため、その場合でも修正前のコードの目的を達成できるか、修正前の挙動に対する懸念が残ります。
この確認のために「修正前のコードの実装背景」と「エラーハンドリングを再現する手順」を把握し、目的を満たすことを実際にテストして確認する必要があります。
これらはソースコードからでは読み取れなかったため、GithubのBlame機能 *1 を使い、なぜこのコードがコミットされたかを調べました。

Blame機能によってコミットからPull Requestを辿り、Pull Requestに紐づくJIRAチケット *2 から開発の概要及び手順を把握できました。

②コメントのやり取りから考慮漏れに気づく

  • 前提
    • リッチテキストエディタの入力フォームからHTMLタグAという入力が選択可能
    • HTMLタグBとCは選択肢にないため選択できない

この機能と関連する箇所の改修の際に、「画面からはAしか選択できないので、BとCを入力するケースは考慮不要」という会話がされていました。

しかし、リッチテキストエディタの入力フォームから入力できないHTMLタグでも、コピーアンドペーストでHTMLタグB、Cを入力できると知っていたので、対応漏れに気づくことができました。

Pull Requestの情報を参照して影響範囲を調べるメリット

今回は影響範囲について、実際にあった例で3つ紹介しました。
それぞれを要約すると以下になります。

  • ①
    • A：要件から直接連想が難しい箇所に影響が出るケース
    • B：修正箇所は特定できるが、その影響を把握するためには過去の実装まで遡る必要があるケース
  • ②
    • C：要件には書き切れなかった細かい部分の挙動が意図通りにならないケース

このように、Pull Requestの情報を参照することで、要件だけを見ていると気づけない考慮漏れに気づく可能性が増えます。
また、Blame機能を使うことで、修正方針の妥当性を検証することができ、リスクを把握した上で意思決定をすることができます。

今後

このように、手動テストで意図しない不具合を検出できるようにテストプロセスを改善しています。
一方で、より効率良く検出するために改善が必要だと感じています。

例えばAの場合、実装後のテストで意図しない変更や考慮漏れを検出できたのは良いことですが、一方でそういった不具合の中には、実装後のQAのテストよりも単体テストの方が低コストで見つけやすい不具合もあるはずです。

また、BとCの場合、指摘のタイミングについて改善の余地があると考えています。
具体的には、テスト後ではなく実装方針を決めるタイミングで指摘ができれば、考慮漏れによる手戻りを防ぐことができると思います。

今後はより効率良く不具合を検出できるように、エンジニアの方と協力しながらこれらの取り組みを発展させたり、自動化や仕組み化を進めていくつもりです。

さいごに

コミューン株式会社ではQAエンジニアを絶賛募集中です！
カジュアル面談もできますので、記事を読んで弊社に興味を持ってくれた方は是非気軽に応募してみて下さい。 commmune-careers.studio.site

*1:GithubのBlame機能 docs.github.com

*2:GithubとJIRAを連携する設定にしています support.atlassian.com