Requestから影響範囲を調べてリグレッションテストを実施している話QAはじめに初めまして。QAチームの三木と申します。commmuneモバイルアプリのQAを担当しており、入社して7ヶ月が経ちました。モバイルアプリチームでは、新機能開発だけでなく既存機能の改修や不具合修正を日々並行して進めています。「既存機能の改修や不具合修正」は小さい単位で行われるため、その変更起因で意図しない箇所に新しい不具合が発生する可能性があり、リグレッションテストでの確認が必要です。現状、モバイルアプリのテストはほとんどが手動テストのため、リグレッションテストも手動で実施しています。今回は、「意図しない不具合」をなるべく減らすために、影響範囲をどのように調べているかについて書きます。リグレッションテストの定義まず、リグレッションテストの一般的な意味や目的を定義します。システムに対する修正や変更によって、意図せずに振る舞いに影響を与えることがある。いった意図しない副作用を検出することを目的としたテスト。変更箇所以外で意図しない影響が発生していないか、確認するテストです。変更ごとに、以下の流れで影響範囲を調べてテストを実施します。影響範囲を調べて、リグレッションテストを実施5.では影響範囲を推測するための情報を探します。Requestの情報から意図しない箇所への変更や考慮漏れに気づく場合があります。実際の例で、いくつか紹介しようと思います。1ソースコードの差分から影響範囲に気づく具体的には以下のようなケースで影響範囲に気づくことがあります。分岐を増やす特定の条件では処理を無効化する後者について、具体例で詳細を説明します。エラーハンドリングが原因で発生する不具合がありました。そのため、不具合が起きる条件ではエラーハンドリングしない方針で修正を行いました。「条件A、かつ、条件B」の場合にエラーハンドリングをする=条件Aだが条件Bではない(不具合が起きる)条件ではエラーハンドリングしないこれにより、不具合の解消を確認できました。修正後だと「条件Aだが条件Bではない」場合にエラーハンドリングしなくなるため、その場合でも修正前のコードの目的を達成できるか、修正前の挙動に対する懸念が残ります。この確認のために「修正前のコードの実装背景」と「エラーハンドリングを再現する手順」を把握し、目的を満たすことを実際にテストして確認する必要があります。使い、なぜこのコードがコミットされたかを調べました。開発の概要及び手順を把握できました。2コメントのやり取りから考慮漏れに気づく前提リッチテキストエディタの入力フォームからHTMLタグAという入力が選択可能HTMLタグBとCは選択肢にないため選択できないこの機能と関連する箇所の改修の際に、「画面からはAしか選択できないので、BとCを入力するケースは考慮不要」という会話がされていました。リッチテキストエディタの入力フォームから入力できないHTMLタグでも、コピーアンドペーストでHTMLタグB、Cを入力できると知っていたので、対応漏れに気づくことができました。Requestの情報を参照して影響範囲を調べるメリット今回は影響範囲について、実際にあった例で3つ紹介しました。それぞれを要約すると以下になります。Requestの情報を参照することで、要件だけを見ていると気づけない考慮漏れに気づく可能性が増えます。Blame機能を使うことで、修正方針の妥当性を検証することができ、リスクを把握した上で意思決定をすることができます。今後このように、手動テストで意図しない不具合を検出できるようにテストプロセスを改善しています。一方で、より効率良く検出するために改善が必要だと感じています。Aの場合、実装後のテストで意図しない変更や考慮漏れを検出できたのは良いことですが、一方でそういった不具合の中には、実装後のQAのテストよりも単体テストの方が低コストで見つけやすい不具合もあるはずです。BとCの場合、指摘のタイミングについて改善の余地があると考えています。具体的には、テスト後ではなく実装方針を決めるタイミングで指摘ができれば、考慮漏れによる手戻りを防ぐことができると思います。今後はより効率良く不具合を検出できるように、エンジニアの方と協力しながらこれらの取り組みを発展させたり、自動化や仕組み化を進めていくつもりです。さいごにコミューン株式会社ではQAエンジニアを絶賛募集中です!カジュアル面談もできますので、記事を読んで弊社に興味を持ってくれた方は是非気軽に応募してみて下さい。APIを活用してi18nの不整合をチェックするこんにちは。(1)引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。