June 26, 2026
影響範囲が見えない変更で、テスト範囲をどう考えるか

 はじめにQEグループでモバイルチームに所属しているmです。

前職までは約7年ほどモバイルアプリの開発をメインに従事していました。

今はQAとしてプロダクト開発に関わっています。
この記事では、QAが設計や実装といった開発側との共通言語を持っておくと、テスト設計でも不具合対応でも有効である、という話を書きます。

共通言語があると問題の切り分けがしやすくなり、開発とのコミュニケーションコストも下がるため、本来集中すべき業務に工数を割きやすくなると考えています。
なお現在も対応中の取り組みなので、効果については「こう感じている」という話も含みます。
 課題：内部の変更は、影響範囲が外から見えづらいまず、この記事の出発点となる課題から整理します。
内部実装だけが変わる対応、特にユーザーから見える動作は変えないリファクタリングなどは、影響範囲が外から見えづらいという特徴があります。

例えば、Swift6対応やKMP対応、UIライブラリの移行などが該当するかと思います。

挙動レベルの影響は開発から共有されるものの、外から触っているだけではどこがどう変わったのかを把握しにくいです。
そのため、テスト設計では「影響範囲が分からないので、念のため全項目をテストしよう」となりやすく、

不具合対応では「ゼロから原因を探そう」という方向に傾きやすくなります。

ただ、実際には期日などの制約もあるため、すべてを見るわけにもいかない場合があります。
この「影響範囲が外から見えづらい」という点が、このあと述べる2つの工程（テスト設計と不具合対応）に共通する課題になります。
 前提：アプリ側の設計・実装を把握して見る課題への向き合い方として、まず普段行っている見方を記載します。
アプリは一枚岩ではなく、機能や役割ごとに分かれて作られています。

たとえば、画面の見た目を作る部分、データを加工する部分、サーバーと通信する部分、データを保存する部分、といった具合です。
何かが起きたとき、「画面上どう見えるか」だけで捉えるのではなく、

「それはどの責務の話なのか」「どことつながっているのか」を、アプリの作りの上で考えるようにしています。

これが、本記事で言う「構造から見る」という見方です。
たとえば「ログイン後の表示がたまにおかしい」という事象であれば、見た目を作る部分ではなく、

データを取得する通信や処理の部分が怪しいのではないか、と当たりをつける、といった具合です。
もちろん開発経験があるため、コードや設計資料を見れば、どの部分がどのように動き、どこにつながっているかは比較的把握しやすいほうだと思います。

ただ、この見方だけに頼るのではなく、開発側にも影響範囲の資料を展開していただいています。
そして、この見方がまず効くのが、テスト設計です。
 テスト設計：見るべき範囲を、根拠を持って絞る先ほどの「つい全項目をテストしたくなる」場面を、前項の考え方で設計します。
ここで行うのは、実装を隅々まで読むことではありません。「この変更は何をしようとしているのか」「だとすれば、何が壊れそうか」を、設計レベルで把握することです。

ここが分かると、何を見るか・どこまで見るかの手がかりになります。
具体的には、次の3つを問いとして使っています。
 ①動作は変わるのか、変えないはずなのか変えないはずの変更であれば、見るべき軸は「変更前と同じか（同等性）」になります。見た目や操作感が、変更前と変わっていないかを確認する、ということです。
 ②技術的にどこへ影響のある変更なのか並行処理なのか、UIの作りなのか、通信まわりなのか。

影響する領域が分かると、その領域で起きやすい問題が、見るべき観点になります。

たとえば並行処理が変わるのであれば、断続的に固まる・クラッシュする・反映が遅延する、といった点です。
 ③どの単位で入る変更なのか画面単位なのか、モジュール単位なのか。これが分かると、見る範囲の単位が定まります。

たとえば、今回改修した画面のみを対象にする、といった具合です。
この3つの問いで根拠を持って絞れると、見る範囲が現実的なところに収まります。

「全部やる」から「変更によって壊れそうな箇所を確かめる」へ変わる、という感覚です。

あわせて、開発との「どこまで実施するか」のすり合わせも速くなると考えます。
 後工程でも効く：不具合の起票と切り分けここまではテスト設計の話でしたが、メリットはその先の工程にも続くと考えています。
テスト設計の段階で把握した「この変更はどの実装箇所に影響があるか」という理解は、不具合の起票や切り分けの場面でも、そのまま活用できます。

一度読み込んだ作りが、ここでも改めて効いてくる、という形です。
そのため、案件にもよりますが、起票を見た時点で「このあたりが怪しいのではないか」と当たりをつけ、仮説つきで起票できます。

たとえば、表示崩れ・断続的に固まる、iOS・Android共通の不具合、といった切り口で、どの部分の話なのかを見立てられます。
重要なのは、これは「QAが原因を完璧に特定できる」という話ではない、ということです。

あくまで当たりをつけ、仮説を立てるところまでです。ただ、その仮説があるかないかで、その後の動きはかなり変わると考えています。
「画面が固まりました」とだけ書かれた起票と、

「ここは非同期処理の変更が入った画面なので、そのあたりが怪しいかもしれません」という仮説つきの起票とでは、

開発側が状況を把握する速さも、誰に依頼すべきかの的確さも変わってきます。

切り分けが、「ゼロから探す」から「仮説を検証する」へ変化し、開発とQA双方にとってメリットが生まれるかと思います。
 実装に寄りすぎないひとつ、意識していることがあります。
現在の実装に寄りすぎると、「すでに実装されているもの」をなぞるだけになり、本来あるべきなのに、実装として抜けている観点を見落とすおそれがあります。

そのため、開発から共有された「本来こう動くべき」という挙動レベルの情報と、

コードや資料から読み取った「現状こうなっている」という状態を、突き合わせるようにしています。

構造理解で当たりをつけつつ、「ユーザーから見てどうあるべきか」という挙動ベースの視点も手放さない。

このバランスが大事だと考えます。
 まとめ今回の内容を要約すると、こうなります。
構造を理解しておくと、テスト設計でも後工程でも、QAの動きが「探す」から「検証する」へ変わる。一度の歩み寄りが、複数の工程で効いてくる。
もちろん、自身の背景などから知見があったという側面はありますが、それがないと無理な話ではないと考えています。

まずはプロジェクトのアーキテクチャ図や設計資料を読んでみる、詳細設計の境界を意識してみる、変更がどの設計箇所に影響するのかを開発に聞いてみる。

そうした小さなところからでも、見立ては変わってくるかと思います。
内部実装の変更で「全部見るしかない」となりがちな場面でも、構造から攻めることで、影響範囲の見立ての精度を上げられます。

同じような場面に立っている方の参考になれば嬉しいです。