はじめに
アソビューAdvent Calendar 2025の3日目（裏面）です。
こんにちは。アソビューでQAエンジニアをしている丸山です。
アソビューでは品質プロセスのシフトレフトが一つ大きな目標になっています。私の場合、インプロセスQAの推進役としてテスト設計等を行いながらシフトレフトの取り組みも行っています。そんな中でこれからQAのシフトレフトに取り組もうという方にも取り入れやすそうな活動があったので今回ご紹介します。
開発とテストの分断がもたらす課題
QAとして働いている中で「品質活動のシフトレフト」という言葉を聞くようになって久しいです。開発のより早期の段階から品質に関する活動を取り入れ、不具合の作り込みを未然に防止しようというアプローチということはわかるのですが、この理想と現実の間にギャップがある開発現場も多いのではないでしょうか。
私自身の経験を振り返っても、アサインされた時点ですでにある程度実装が進んでおり、そこから慌ててテスト設計・テスト実装を始める、という場合が少なくありませんでした。工程の初期段階から品質に関わること自体ができない状況です。
こうした開発とテストが工程上で分断されている状況では、開発者とQA担当者間のコミュニケーションが希薄になり、テスト実行開始後に「実装漏れ」「クリティカルなバグの発生」「認識相違によるテスト項目の作り直し」といった、品質やスケジュールに対する大きな問題が発生しやすくなります。これにより、スケジュールが圧迫されるだけでなく、最終的にリリースされるプロダクトの品質もあまり高くないという結果になることが多いように思います。
QAのシフトレフトというけれど、何から行えば良いのか
テストに関する工程の着手が遅くなる、テスト開始時の大きなトラブルで品質が低い状態になってしまうという状況の原因としては、要件定義や機能設計・実装の各段階で品質に関する活動が行えていない、つまり品質に関する活動のシフトレフトができていないと言えます。
QA活動は要件定義や機能設計のタイミングなど、比較的開発工程の早い段階で戦略・方針を決めて取り組むことができます。早めに取り組むことでテスト設計やテスト実装も先行できますし、開発工程の中で開発者とQAエンジニアとの間のコミュニケーションも増えます。
以前、弊社のブログではプロセスの改善活動の事例として受入基準の導入についての記事がありました。受入基準も、こうした品質の方針を確認し、開発チーム内で品質に関するコミュニケーションを生み出すきっかけとして利用できる一つの手段です。
しかし、品質についての活動に関してチーム内でも方針がまとまっていない場合には、受入基準の作成のような新しいプロセスの導入はハードルが高いと敬遠される場合もあります。 そこで、これまでの私の経験からなるべく作業内容を変えることなくシフトレフトに貢献できる第一歩として、まずは「機能設計段階でのテスト観点の共有」から始めてみるのはどうかという提案をさせていただきます。
テスト観点とは何か
まずは「テスト観点」という言葉に馴染みのない方もいるかもしれませんので、簡単に説明します。
テスト設計を行う際、QAエンジニアは必ず「テスト観点」を考えます。
（特に観点なんか書き出さずにテストケース書いていくという人や体制もあるかもしれませんが、頭の中で観点の割り出しは行っていると思います。）
テスト観点は、開発物が要件を満たしていることをどのように確認するかというアプローチの視点を指します。テストケース（具体的な手順）を作成する前の段階の「何を・どのようにテストするか」を示すものです。
テスト観点のリストはテスト要素とテストの方針をまとめたものですので、テストケース全体と比較してボリュームが少なく、共有しやすいというメリットがあります。
テスト観点の大まかな例として以下のようなものがあります。
- 正常系観点：正常な入出力や操作で、期待通りに機能するか
- 異常系観点：不正な入力やエラー条件で、適切にエラー処理が行われるか
- 状態遷移：システムの状態が変化する際の動作が正しいか
- 境界値：入力値の最大値や最小値、期間の切れ目など、境界での動作が正しいか
- 非機能テスト：パフォーマンス、セキュリティ、アクセシビリティなど
※実際には開発する機能に合わせてより細かな観点に切り分けます。具体例は後述します。
このテスト観点を早めに作成し、できれば機能設計の段階で共有するという作業順の調整をすることで、開発の早めの段階からコミュニケーション参加し不具合の未然防止に貢献できることがあります。
具体例
私が関わった案件のうち、ごく簡単なものを例に挙げます。 弊社のシステムを介して販売する電子チケットに関して、画像の登録操作を販売元の施設様側でも行えるようにする機能改修に関わった際のことです。
元々、電子チケットデータについては、施設様からの依頼を受けて社内のスタッフが全てのデータ登録を行っており、画像も社内スタッフが登録していました。その際に使用されるのは社内向けの管理ページでした。この管理ページの機能を施設様側に提供している情報確認用のページにも実装するという開発案件です。機能設計の段階で私が作成したテスト観点の一つに以下がありました。
- 対応・非対応のファイル形式（拡張子）別に、画像の登録時の挙動を確認する（正常系、異常系の観点の一つ）
元々要件としては「社内向け管理ページに機能を合わせる」という大方針であったのですが、テスト観点について開発者と相談をした際に社内向けの管理ページでは特にファイル形式によるアップロードに制限はなく、対応していないファイルの場合はアップロード完了後に登録がされないという実装になっていることがわかりました。（チケット制作部門では施設様から画像をいただく際にJPEGかPNGで提供いただいており、この2つの形式であれば特に問題は起きなかったようです。）
開発者からは「無制限のままにして、意図しない不具合が発生する恐れがあるのは困るよね。」といった話が出たり、私からは「アップロードできたのに画像が反映されないという挙動は、使う人の側から見て不満につながりそう」という話をしました。結果としてこの画像登録の機能については、JPEGかPNGのファイルのみアップロード可能、それ以外は受付けないという方針が決まり、機能設計・実装、テスト段階や本番公開後も問題はありませんでした。
「対応するファイル形式」についての観点は、通常であれば開発者の設計などでもあたり前に検討する要素です。ですが、過去に私が経験した他社開発現場では、こうした機能の移植のような開発案件においてチーム内の限られたメンバーで仕様検討が完結してしまい、「既存の機能に合っていれば良い」という理由づけで利用者に対する考慮については話題にあがらず、そのまま実装されることもありました。そして大概、テスト時に不具合が発生して修正されることになりますし、修正がさらに何かしらの問題を起こす場合もあります。
事前に会話さえできていれば、こうしたリスクの発生や修正による工数増加は防げたのです。
品質に関する活動のシフトレフトというのは、要件定義や設計など早い段階で作り手側以外の視点も含めて多角的に検討するということが重要だと思います。この具体例ではテスト観点について会話することで、移植元の仕様のリスクの把握やユーザーのユースケースを考慮しての仕様を考える会話にQAエンジニアも自然と参加できる流れがあった例だと思います。
テスト観点を早期に共有することで得られる効果
設計段階で開発チーム内にテスト観点を共有する利点は以下があります。
1. 知識の偏りを減らし、開発・テスト双方の抜け漏れを防止する
テスト観点を作成する際の目線は、より利用するユーザーや利用状況・環境に寄ったものです。テスト観点を共有することで、開発者とは異なるユーザー視点での情報が提供されます。
【テスト設計者からの情報提供】
開発者が把握していなかった仕様情報や、過去に発生した類似機能の不具合の再発防止観点などを共有できます。
【開発者からのフィードバック】
テスト設計担当者が把握していない実装上の制約や、特定の環境に関する情報を開発者から提供してもらうきっかけにもなり、知識の偏り（サイロ化）を解消できます。
2. 実装時の考慮漏れを減らし、手戻りを削減する
事前にテストの要点を確認できるため、開発者は実装時にあらかじめ考慮しておく必要がある要素を把握できます。
テスト観点に記載している要素について、実装段階で先に対応できる要素は対応しておくことで不具合の「未然防止」につながりますし、「テスト実行 → バグ報告 → 修正 → 修正の確認」という一連の大きな工数を、一定減らすことが可能になります。
（先ほど提示した具体例はこちらの効果があった例になります。）
3. テストカバレッジと工数を最適化する
テスト観点で割り出した要素について、単体テスト、結合テスト、システムテストのどの段階でテストを実施するかという取り決めを、早期に行うことができます。
これにより、前工程のテスト（単体・結合）で保証が取れている要素は後工程のテストで確認不要とするなどの判断ができ、テストの重複を減らすことができます。
現在私が関わっている開発チームではこのような効果を見込んで、要件の共有があった直後からテスト設計を開始し、機能設計のレビューの前後で読み合わせするなどして、認識合わせをしています。こうした事前共有を行った上でテスト実施した開発案件では、システムテスト実施段階で不具合が出ることはほとんどありませんでした。その結果、より利用者目線の調整の議論や、探索的テストを行う時間にあてられるようになっています。
テスト観点は設計が決まっていなくても作れるのか
ここまでの説明で「具体的な設計が終わっていなくてもテスト観点が作れるのか？」と疑問に思う方もいらっしゃるかもしれません。詳細な設計情報がなくても、テスト観点の割り出しを行うことは可能です。
要件定義の段階で、
「どのような状況で動かす機能なのか」
「どのような入力があり、どのような期待動作となるか」
がある程度決まっていれば、ある程度のテスト観点の割り出しは可能です。
もちろん、具体的なUIや内部仕様が決まっていく中で新たに追加すべき観点が出てくることもありますが、上で提示したメリットを考えると、先行してテスト観点を作成し、細かい部分は設計・実装を行う中でコミュニケーションをとって更新していくというアプローチの方が品質は高くなると感じます。
テスト観点の作成
テスト観点を作成する際には、「どういった使い方ができるのか」という視点や「本番環境でどういったことが起こりうるか」という視点で開発対象を見ることが重要です。開発者の視点だけでは考慮していなかった利用ケースなどが、テストを考える際の視点によって見つかることもあります。
ほんの少しですが観点の例をあげるとすると、以下のようなものが考えられます。
【文字を入力して表示させる機能の場合】
文字数の上限/下限の場合の制御
未入力で次に進もうとした場合の挙動
文字種（全角/半角、記号、絵文字、英語以外の文字セット、マルチバイト文字など）への対応
コードや特殊な文字列を制限しているか
【期間の設定がある機能の場合】
期間前・期間中・期間終了後の同値分割や境界値でのテスト
境界となる日時を跨いだ場合の挙動
【大人数が同時に使用する場合】
負荷によるサービス全体の品質への影響
ユーザー同士の操作が重なった場合の挙動
タイムアウト時の挙動の考慮
上の例の中には「要件の中には特に決まりがないけれど、考えておかないと問題が起こる可能性があるもの」が結構あったりします。
経験豊富なQAエンジニアはこうした観点を知識として持っており、要件の内容から要点を割り出してテスト観点を作成していきます。開発対象の機能も様々ですし、テスト観点も対象によって様々変化します。経験の浅いQAエンジニアやテストに関わってこなかった人が観点をリスト化するとなった場合は、何を割り出せば良いかわからなくなってしまうこともあり得ますので、事前に他のQAエンジニアや開発エンジニアと話し合いながら特定の機能にとらわれずに様々な観点を一覧にしたリストを用意して、開発する機能に適用できる観点をピックアップしていくような体制を作ると良いかもしれません。
また、最近ではAIに開発ドキュメントや既存コードの一部を渡し、開発対象機能に対するテスト観点について補足してもらうことも可能です。ただし、AIは一般的なテスト観点を網羅的に提供できますが、部分的に間違った内容が入れ込まれることもありますし、ドメイン特有の機微な仕様や、組織特有のリスク判断はできませんので、出力されたテスト観点については人間による精査が必要です。AIから出力された内容を吟味した上で、知見をもつメンバーからレビューしてもらうといった手順を踏むのが良いでしょう。
早期共有に最適なタイミング
テスト観点は要件が共有された時点でまず作成しておくのが理想ですが、共有のタイミングについては少し注意が必要だと思います。個人的には開発者が機能設計の方針を決め、実装の詳細に入る前の段階が好ましいです。
遅すぎて実装に入ってしまうと、観点共有による仕様変更や設計変更が手戻りになってしまいますし、早すぎてしまうと観点を意識しすぎて、設計が過剰になったり、かえって柔軟性を損なうなど、設計に悪影響がある場合もあります。
基本的な設計の方針が決まった段階で、「この設計でテスト観点は満たせそうか？」というレビューのインプットとして活用することが重要です。
テスト観点の作成や事前共有をする際の注意点
ここまでいろいろと説明をしてきましたが、シフトレフトの視点でテスト観点を前倒しで共有していく場合の注意点について、作成する側・共有される側それぞれあげておきます。
【テスト観点を作成する側】
1. ドメイン知識の習得
テスト観点は、言い変えると開発時の注意点でもあるので、開発担当者も設計・実装の際にいろいろと考える要素です。この為、テスト観点を作成・共有する側も、開発者同様に一定のドメイン知識やプロダクト知識が必要です。ドメイン知識が乏しいと、単に情報をもらうだけの活動になってしまい、開発者・テスト設計者の間での補完関係が生まれません。テスト項目の漏れが発生しないようにするという点では意味がありますが、品質を早めに作り込むという意味では不十分になってしまいます。日頃からプロダクトの仕様やビジネス要件を深く理解しておくことが求められます。
2. リスクベースでの重み付け（リスクベースドテスト）
割り出した観点は全てを等しく扱うのではなく、重要度やリスクベースでの重み付け（リスクベースドテストの考え方）が必要です。
各観点で問題が起きた場合に、どのような影響があるかを考えることで、注意して作業すべき部分の把握や、テスト工数の適正化につながります。
意図した通りの動作とならない場合でも、その結果が軽微な問題にしか繋がらないようなケースに対して、複雑な条件を考慮した実装や細分化したテストを行うことは無駄が多くなります。リスクの低い部分には、コストをかけすぎない判断が必要です。
【テスト観点の共有を受ける側】
1. 未然防止のための活動と捉える
テスト観点の早期共有は、単なる「テストのための準備作業」ではありません。前述の通り、機能設計や実装の段階で考慮漏れを減らし、不具合の作り込みを未然に防止するための取り組みです。
共有を受けた開発者も、テストのためではなく、「テスト観点が想定する状況について実装する際にどう対応するか」を考えながら確認することで、この活動の価値が最大化されます。
2. テストを前倒しするわけではない
テスト観点を早い段階で共有することは、必ずしもテストの実施を前倒しするものではありません。
各観点について単体テスト、結合テスト、システムテストのどのレベルで、誰が確認するかは、開発機能の内容やチーム状況に合わせて調整すべきです。最も効率よく品質を保証できる工程で実施することが重要です。
知見の違いを生かして協力する
今回ご紹介したテスト観点を設計段階で取り入れる、考えてみるというお話は、開発エンジニアも考えながら開発はしていると思います。ただ、開発エンジニアが持つ知見とQAエンジニアが持つ知見には違いがあります。ドメイン知識について、開発エンジニアは作り手として一つ一つの機能に対してピンポイントに深く、QAエンジニアは使う側の視点に寄りつつ、関係する広い範囲をカバーしようとする傾向にあると思います。開発チーム全体が広く深く知識を持つことが理想ではありますが、その第一歩としてQAエンジニアがシフトレフトに貢献するとすれば、視点や範囲の異なる知見を早い段階から共有し、協力してプロセスで品質をあげる体験ができると良いと思います。
さいごに
現在アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！
ご興味がありましたら、ぜひお気軽にご応募ください！
https://www.asoview.com/brand/engineer-career/
