スプリントごとのテストの優先順位の考え方 | ユーザーストーリー起点で進める、アジャイル開発の品質保証

アジャイル開発に取り組むなか、短期間のスプリント内で必要なテストを実施しきれないことに悩む企業は少なくありません。

限られた期間内に重要なテストを抜け漏れなく実施するためには、「そのスプリントで何を目指しているか」について関係者間で共通認識を形成し、それに基づいて品質要件の優先順位を明確化する必要があります。スプリントごとの品質目標を定める際にカギとなるのが「誰が、何のために、何をするか」を描く、ユーザーストーリーです。

本記事では、ユーザーストーリーを起点にスプリントごとの品質保証を進める考え方を解説します。

スプリントごとの品質保証が機能しない理由

スプリントごとの品質保証がうまく機能しない現場では、アジャイル開発の導入が形だけになっているケースが多く見られます。開発手法の表面だけをなぞり、実態としては従来型のウォーターフォール開発と変わらない進め方になってしまっている現場は決して少なくありません。

例えば、スプリントが単なる小規模な開発区分となり、細かい設計やドキュメント作成に多くの時間を費やしていては、「素早く動く成果物を提供する」というアジャイル本来の目的から外れてしまいます。

では、アジャイル開発において品質保証を機能させるには、どうすればよいのでしょうか。その出発点は、スプリントの初期段階で「ユーザーにどんな価値を提供するのか」を明確に定義し、その価値に基づいてテストや実装の方針を関係者間で共有することにあります。

テスト計画はユーザーストーリーを起点に考える

スプリントごとのテスト計画を立てるうえで軸となるのが、そのスプリントで実現したいユーザーストーリーです。

ユーザーストーリーとは、「誰が、何のために、何をするか」という形式で、機能の価値をユーザー視点で表現したものです。

具体例として、動画配信アプリで字幕機能を追加する場合のユーザーストーリーを考えてみましょう。

よくない例
「字幕が見られる」

よい例
「海外ドラマ好きの視聴者が、タップで手軽に字幕を切り替えながら多言語視聴ができる」

前者の表現では、字幕がどのように見られればいいのか、利用シーンや目的が明確ではありません。一方で、後者のように、ターゲットユーザー像に基づいて機能の目的を言語化すれば、関係者が品質の目標を共通認識として持つことができます。

優先すべきテスト観点の見つけ方

ユーザーストーリーを言語化した後は、それをもとにスプリント内で優先的にテストすべき内容を洗い出していきます。

新しい機能を実装した際に優先してテストすべき観点は、大きく3つに整理できます。

①新機能が正しく動作するか

②新機能に関連する機能が正しく動作するか

③共通機能の挙動が崩れていないか

このうち③は回帰テストで確認することが基本となるため（後述）、スプリント別のテスト計画では特に①と②の具体化が重要です。

例として、上述の例にある動画配信アプリの字幕機能について、具体的なテスト項目を考えてみましょう。

ユーザーストーリー

「海外ドラマ好きの視聴者として、再生中にタップ一つで字幕言語を切り替えたい。それは、自分の語学レベルやシーンに合わせて、視聴を止めることなく内容を理解するためだ」

優先すべきテスト観点

• 新機能
  • 選択した言語の字幕が正しく表示されるか
  • タップで言語切り替えができるか
• 関連機能
  • 言語切り替え時に画面の乱れが出ないか
  • 2倍速再生と字幕切り替えを併用しても問題なく動作するか
  • 一時停止や再開時に字幕の同期がずれないか
    

進捗やリソース状況によっては、フォントサイズ調整のように優先度が低い要素を次のスプリントに回す判断を下します。

もう1つの例として、ECサイトのカート機能を実装する場合のユーザーストーリーと優先すべきテスト観点を考えてみましょう。

ユーザーストーリー

「購入者として、決済手続きに進む前にカート内の最終的な合計金額を確認したい。それは、予算内に収まっているか判断し、安心して購入を確定させるためだ」

優先すべきテスト観点

• 新機能
  • 「カートに入れる」ボタンを押した際、商品が正しくリストに追加されるか
  • カート内の商品の合計金額に計算ミスが起きないか
  • 数量変更や削除がスムーズに行えるUIになっているか
• 関連機能
  • 在庫管理システムと正しく連携しているか（在庫切れの商品は追加できない、など）
  • 配送料の計算ロジックが、カート内の合計金額や重量に応じて正しく連動するか

この場合も、「カートに追加した商品に沿って、他商品の適切なサジェストが表示されるか」などのユーザーストーリーを実現するうえで必須ではないテスト観点は、リソース次第で次のスプリントに回すことを検討します。

このように、「そのスプリント内でどんな価値をユーザーに提供するのか」を起点にテスト観点を設定することで、重要なテストを抜け漏れなく実施しやすくなります。

限られた期間で必要なテストを終えるための工夫

数週間という短いスプリントのなかで品質要件を充足するためには、自動化による工数削減やテストの取捨選択がカギとなります。

ここでは、必要なテストを現実的な工数で進めるための工夫について解説します。

共通機能の動作確認は自動化する

ログイン機能や画面遷移など、アプリケーション全体で共通して使用される基本機能は、システム全体に影響を及ぼす要素であり、新機能の追加によって思わぬ不具合が発生する可能性があります。

これらの共通機能を毎回手動で検証するのは非効率であるため、繰り返し実施される回帰テストは自動化するのが効果的です。

CI/CDパイプラインに回帰テストを組み込む代表的な手法では、開発のたびに自動的にテストが実行されるため、共通機能の安定性を継続的に担保できます。これにより、テスターは新規機能や複雑な操作に対する手動テストに集中でき、リソースの最適化につながります。

異常系の検証は探索的テストで効率化する

正常系のテストはパターンが限られる一方で、異常系は想定外の操作や入力が無数に存在するため、全パターンを網羅するのは現実的ではありません。そのため、スプリント内で実施する異常系テストの優先順位付けと効率化が重要になります。

そこで活用したいのが「探索的テスト」です。この手法では、プロダクトに触れながら仕様理解とテストの設計・実行を同時に行い、テスターの知見を活かしてリスクが高そうな箇所を重点的に検証します。事前のテストケース作成の時間がかからないため、短期間のスプリントにも適しています。

非機能テストはタイミングを決めて実施する

セキュリティテストや負荷テストなどの非機能テストは、実施に1ヶ月以上かかることも珍しくありません。すべての非機能テストをスプリントごとに実施するのは現実的ではないため、プロジェクト全体のスケジュールのなかでタイミングを決めて実施します。

具体的なタイミングについては、アーキテクチャの大きな変更時、重要な機能のリリース前など、影響範囲が大きくなるポイントに絞って実施するのが効果的です。こうすることで、スプリント内での機能開発やテストの流れを妨げずに、多角的な品質保証を実現できます。

組織として品質保証体制を強化するために

アジャイル開発のスピード感を損なわずに品質の高いプロダクトを実現するためには、テスターやテストエンジニアだけでなく全員で品質保証を進めるための情報共有や連携が重要となります。

最後に、品質保証に優れたチームを形成するための主なポイントを解説します。

テストマップでの計画の可視化

プロジェクトの初期段階で「テストマップ」を作成することで、長期的に見たテストの優先順位を可視化できます。

テストマップとは、プロダクト全体のテスト戦略を可視化したドキュメントです。一般的に「機能」と「テスト観点」をマトリクス形式でマッピングし、機能ごとにテストすべき観点やテストの優先順位などを一覧で示します。

テストマップは一度作成して終わりではなく、機能追加やスケジュール変更などに応じて、継続的に修正しながら運用していきます。特にアジャイル開発ではビジネスサイドやクライアントの提示する要件に応じて計画を柔軟に変更するため、テストマップも都度更新して最新の状態に保つことが求められます。

レトロスペクティブの実施

アジャイル開発の主流であるスクラム開発では、スプリント終了時に実施する「レトロスペクティブ」（振り返り）が不可欠ですが、実際には形式的な実施にとどまっている現場も少なくありません。

レトロスペクティブでは、「Keep（継続すべきこと）」「Problem（問題点）」「Try（次回試したいこと）」「Action（具体的なアクション）」を設定するKPTAのフレームワークなどを用いながら振り返りを行うことで、うまくいった点や次回のスプリントで改善すべき点を明確にします。

計画通りいかなかった点については、「見積もりが甘くなかったか？」「テスト項目の設定に問題がなかったか？」といった観点から原因を洗い出し、次のスプリントに活かせるよう記録します。こうした継続的なフィードバックループが、品質保証の精度向上につながります。

開発チームとのテスト観点の共有

品質保証をチーム全体で担うためには、スプリントの開始時点で開発チームとテスト観点を共有することが重要です。ユーザーストーリーを起点に、どのような価値を実現するか、どこに品質リスクが潜んでいるかをあらかじめ擦り合わせることで、後工程での手戻りを減らせます。

例えば上述の動画アプリの字幕機能を実装するスプリントであれば、「言語切り替え時に画面の乱れが出ないか」や「2倍速再生と字幕切り替えを併用しても問題なく動作するか」といった重要な観点を事前に共有しておくことで、開発段階からそれらを考慮した設計・実装が可能になります。

ユーザーストーリー起点のテスト計画で、「動く」プロダクトを実現する

アジャイル開発での品質保証の失敗の多くは、アジャイル体制の導入が表面的なものにとどまっていることに起因します。単に開発期間を短く区切るだけではなく、「その期間でどのユーザーストーリーを実現するのか」を明確にし、それに基づいて必要なテストを見極めることが、本来あるべきアジャイル品質保証の姿です。

ユーザーストーリーに応じた抜け漏れのないテスト設計には、品質保証に関する一定の知識や経験が求められます。特に、開発専門のメンバーがテストも兼任する現場では、どのような観点からテストを実施するべきか、判断軸が定まらないことも多いでしょう。

品質保証について社内のナレッジが不足している場合は、外部のテスト支援会社と協業するのも一つの選択肢です。専門的な知見を持つ第三者から客観的なフィードバックを受けることで、自社だけでは気づきにくい観点の抜け漏れを防ぎ、網羅性の高いテスト設計につながります。

AGESTのソフトウェアテストサービスでは、アジャイル開発を含めた幅広い開発体制での品質保証プロセスの改善を支援しています。自社の品質保証体制に課題を感じる方は、ぜひ一度ご相談ください。

ソフトウェアテストサービス