最近アジャイル開発という言葉を聞くことは多いと思います。
アジャイル開発とは、短期間のサイクル（スプリント）を何周にも渡って行う開発工程のことで、欠陥を早期に除去することができるため、品質の高い製品の作成が望めます。
従来の開発工程であるウォーターフォールモデルやV字モデルでは、長期間にわたる開発になればなるほど、開発過程の途中で振り返ることが難しいことが課題でしたが、アジャイル開発ではそれを解消することができます。
今回は、そんな「アジャイル開発」でのテスト工程についてフォーカスをあて、アジャイル開発にてテスト責任者を務めていた筆者の経験から、注意した点や苦労したポイントなどを中心にリアルな目線で記載したいと思います。
本記事のポイント
前述したように、アジャイル開発は短期間のサイクル（スプリント）を何周にも渡って行うため、開発者・ステークホルダー共に状況が見えやすく、また欠陥を早期に除去することができるため、品質の高い製品の作成が望める革新的な開発工程です。
しかし、大きな落とし穴としては、導入にあたってチーム内の協議や土壌作りに時間を割かなければならず、テスト工程において原因が曖昧な問題が多発してしまいます。
また最終ゴールが明確に定められていないため、チーム内の協議や土壌作りに左右されることが少ない従来のウォーターフォール等の開発工程に比べて劣る製品になってしまう恐れがあります。
本記事では、アジャイル開発に携わったことが少ない方に向けて、この工程における検証の重要性と効果的な導入方法についてテストを通じて詳しく解説していきます。
アジャイル開発におけるテストとは
従来の開発工程も含め開発工程におけるテストとは作成された成果物に対して評価を行う作業です。
ここでは、テスト工程がアジャイル開発においてどのような役割を果たしており、どのような特徴があるかについて簡単に解説していきます。
アジャイル開発におけるテストの特徴
アジャイル開発におけるテストと言っても、当然検証という目的は同じため従来のテストの基盤（前回のテストへのリンク）を適応することが可能です。
そこで最初に気になるのは従来の開発工程（ウォーターフォールモデルやV字モデル）との違いなのではないでしょうか。
それでは、従来のテスト工程とどのように違うのか、アジャイル開発におけるテストの代表的な特徴を５つ紹介します。
①スプリントという短いスパンでサイクルが実行されることによるステークホルダーへの迅速な価値と結果の提供
仕様・成果物・スケジュールといった部分が、従来の開発工程と比べてステークホルダーと開発間の現状の共有が頻繁に行われることによって、認識齟齬の事前防止・認識齟齬があった場合に速やかな対応が可能です。
また、ステークホルダー側から定期的に提供される結果を元に最終納品時の営業戦略を立てやすい点が利点として挙げられます。
②テストが開発活動の最後ではなく恒常的に行われるため、迅速に開発側へのフィードバックと分析結果を提供できる
クリティカルな障害が発生した際に従来の開発工程と比べてテストが定期的に動いているため作りこむ前に対応できる点と、従来の開発工程では最後に行われるテスト結果分析をサイクルの中で何度も行い、その情報を開発側にフィードバックすることで事前にクリティカルな障害の作りこみを防ぐことができます。
③リスクベースのテスト戦略を取り、分析の主導にテスト担当者がなることが多い
テスト担当者としては、テスト結果分析の回数が従来のテスト工程に比べて多いため、より精度の高いリスク分析を行うことができる点と、その分析結果を他のプロジェクトでも流用可能な点が利点として挙げられます。
④手動テストの手法が従来のテストより偏った技法を用いることが多い
テスト自動化の導入が優先されるアジャイル開発では、従来のテストで用いられる一部技法を自動化によって省略することが重要であるため、経験ベースおよび欠陥ベースの技法（ソフトウェア攻撃、探索的テスト、エラー推測等）といった自動化によって賄うことが難しい技法が偏って用いられます。
筆者がアジャイル開発に携わったときは、ホワイトボックステスト（ユニットテスト等）は従来の開発工程でも開発チーム内でレビューを行う関係上自動化されることが多いですが、アジャイル開発では負荷テストやセキュリティテストといった非機能要件と受け入れ基準の確認項目を洗い出し、そのテスト自動化の導入をしてもらったことがあります。
そして自動化した項目を除いたときに残るテストケースはユーザ受け入れテスト・シナリオテストと呼ばれる項目の割合が大多数を占めていました。
⑤ドキュメントを削減することができる
テスト工程のプロジェクト成果物の内容は従来のテストと同様ビジネス指向の成果物、開発成果物、テスト成果物の３件に分類されます。
しかし従来のテストに比べ、要件に従っていることを示す自動化の成果物と動くソフトウェアといった開発成果物に重点を置いているため、ステークホルダーに価値を提供しないドキュメントを削減することが指針となっています。
アジャイル開発におけるテスト導入の注意点
アジャイル開発のテストは利点も多い反面、リスクもそれ相応のものが挙げられます。
アジャイル開発におけるテスト担当者のスキル
ここではテスト担当者の必要スキルにフォーカスを当てた注意点を紹介します。
① 人間関係の構築スキル
従来のテスト工程に比べ、前述したリスク分析やスクラムミーティング等で各チームやステークホルダーと品質について協議する機会が多くなります。
そのため、コミュニケーション能力は勿論、事前に連携が円滑に行えるチーム作りを怠ると、チーム間において認識齟齬が発生する恐れがあります。
② テスト自動化の経験
アジャイル開発のテストは短いテスト期間のため、自動化導入の重要度が従来のテストに比べて高くなっています。
そのため、テスト担当者にテスト自動化の経験があまりない場合、テスト担当者が導入に際して導入の可否の判断といった自発的な行動を起こしづらく、開発メンバーに余計な工数（本来テスト担当者が担う工数）が発生してしまう恐れがあります。
③ テスト分析の経験
アジャイル開発のテストではテスト分析を実行する回数が多く、そのプロジェクト全体が影響範囲となっているため、従来のテストとは比べ物にならないレベルで重要度が高くなります。
そのため、テスト分析の経験が薄い場合、対外的には前述している開発工程やステークホルダーへのフィードバックが難しくなってしまう点が挙げられますが、こちらは利点が失われるのみで従来のテスト工程に劣る結果になる程のリスクとなることはあまりありません。
しかし、テストチーム内において分析が正確に行われないことは期間内に完遂できるテストケースの作成が難しくなり、必要なテストが実行できない可能性も出てくるため、プロジェクト全体の品質が大きく低下してしまう恐れがあります。
アジャイル開発におけるテスト担当者の役割
アジャイル開発におけるテスト担当者の役割は、テスト実行工程以外に「チームワーク」、「スプリントゼロ」、「統合」、「テスト計画作業」、「追跡性の保持」等が挙げられます。
ここでは特にリスクとなる３つを説明していきます。
① チームワーク
アジャイルでは、開発者、テスト担当者およびステークホルダーが一緒に作業するチーム全体でのアプローチが重要です。
テスト担当者が開発チーム、ステークホルダーと折り合いを付け、信頼関係を結ぶことが重要となるということです。
② スプリントゼロ
これはアジャイル開発におけるプロジェクトの準備活動段階にテスト担当者が行う作業のことを示しています。
主な作業は下記の通りです。
- プロジェクトの範囲の識別
- 必要なツールの計画、手配
- テストスコープ、テクニカルリスク、カバレッジの目標を考慮
- 最初のテスト戦略を作成
- 品質リスクの分析
- タスクボードの作成
- 完了の定義の明確化
この作業ではテストで何を達成しなければならないのか、それをテストでどのよう達成するかの方針決めであるため、上記一覧のどれかが不十分である場合、テスト工程において問題が多発する恐れがあります。
③ 追跡性の保持
追跡（トレーサビリティ）とは仕様書・テスト計画書・テスト設計書等の各種プロジェクト資料に変更があった場合に影響範囲を特定するため、相互に紐付けておく作業です。
この作業は、変更の入った箇所の影響範囲や合わせて変更する必要のある資料の割り出しが速やかに行えるという利点があり、アジャイル開発は前述の通りサイクルを複数回行い都度仕様や計画を協議しながら進める関係で変更の入る回数が従来のテスト工程とは比較にならない程多く、追跡の重要度が上がると言えます。
そのため、追跡性が保持されていないプロジェクトでは、各協議の結果で一部変更が入った際に影響範囲の特定ができず、都度余計な工数が発生し品質が大きく落ちてしまう恐れがあります。
組織的なリスクと独立したテストの重要性
従来のテスト工程にも同じことが言えますが、独立したテスト担当者は開発チーム内に所属する担当者に比べ欠陥を効果的に見つける能力が高いとされています。
つまり、開発担当者は独立したテスト担当者に比べて成果物への批判的な視点が欠けやすいということです。
そのため、テスト担当者やチームの選出には3つの選択肢があります。
① アジャイル開発チーム内にテスト担当者を設ける
開発チームとして簡単な選択方法ですが、前述した通り独立性と評価の客観性を失うリスクが存在します。
② 完全に独立かつ分離したテストチームを設ける
成果物への批判的な視点が欠けやすいという問題点が解消される選択肢ですが、外部である以上プロダクト内の新しい仕様の理解不足・ステークホルダーや開発者との人間関係の行き詰まりといった問題を抱えやすいリスクが存在します。
③ アジャイルチーム内に開発チームとは別の独立かつ分離したテストチームを設け、長期に渡りテストのみを担当する
独立性を維持し、プロダクトを十分に理解し、他のチームメンバーと強固な関係を築くことができるため、①②に示した問題を解消することができます。
しかしながら、テスト担当者へ求めるスキルレベルが上がる傾向にあるため、選定の段階でそれを考慮する必要があります。
上記３件であれば③が理想的ですが、それに見合うスキルを持ったテスト担当者を選出することが出来なければ運用が不可能であるため、３つの中から状況に合わせた選定をすることが不可欠であると言えます。
当社では、③のテスト担当者を選択し、アジャイル開発を進めたことがあります。
このプロジェクトでは、テスト担当者はアジャイル開発がスタートする以前にプロジェクトを把握することに多くの時間を費やしていたため、テストチーム自体が想定以上の問題を抱えることはありませんでした。
しかし、アジャイル開発スタート以前に時間が取れないテスト参画であった場合を考えると、想定できる障害やリスクの分析が筆者のスキルレベルでは十分にできず、対象の品質を大きく落としている可能性がありました。
もちろん準備に潤沢に時間が取れるプロジェクトは稀かと思います、そのため③を選択する場合は準備時間に見合ったスキルレベルのテスト担当者がいることが必須であると感じました。
アジャイル開発におけるテストの種類・手法
ここまではアジャイル開発のテスト導入に関して話してきましたが、本章では具体的にアジャイル開発のテスト工程が担う事項について述べていきます。
アジャイル開発におけるテストの種類
ここでは「アジャイルテストの四象限」と言われる４つのテストの種類を判別する定義を紹介します。これはテストを縦軸ビジネス（ユーザ）、テクノロジ（開発者）、横軸製品支援、チーム支援の面に分け、テストタイプを区別し説明する方法論です。
・第一象限（Q1）「ユニットレベルのテクノロジ指向」
開発者のサポートが目的であり、単体テストやユニットテストが含まれます。
この工程のテストは基本的には自動化され、継続的に繰り返されることが多いです。
・第二象限（Q2）「システムレベルのビジネス指向」
プロダクトの振る舞いの確認が目的であり、機能テストが含まれます。
この工程は受け入れ基準をチェックするものであり、手動・自動どちらの方法でも実行されることがあります。
・第三象限（Q3）「システムレベル・ユーザ受け入れレベルのビジネス指向」
現実的に使用されるシナリオやデータを使用してプロダクトを評価することが目的であり、探索的テスト・ユーザ受け入れテスト・シナリオテスト・αテストβテストが含まれます。
この工程のテストは基本的には手動で実行されます。
・第四象限（Q4）「システムレベル・運用受け入れレベルのテクノロジ指向」
運用された際のプロダクト自体を評価することが目的であり、負荷テストやセキュリティテスト等の非機能テストが含まれます。
この工程のテストは自動化の対象とできる事項が多いため、基本的には自動化されます。
この定義はスプリント毎にこれらのいずれか又は全てのテストが必要となり、各関係者に説明することが容易となるため、テスト担当者はこの４つを判別することが重要です。
アジャイル開発におけるテストの手法
まずテストを行うにあたって、どこへ向かうべきかという「完了」の定義を明確にする必要があります。具体的には「Webアプリケーションの検証について」3-1.に記載のある各テストレベルとその完了基準を満たしているかということです。
完了条件は従来の開発工程のテストと同じくテストケースの消化・欠陥/品質リスクの修正済みが基盤となりますが、アジャイル開発では「できる限りのテストが自動化されていること」が完了基準に含まれます。
ここで注意しなくてはならないことが、テストスコープは従来のテスト工程と異なりリスクベースであるため、「完了」の定義自体は似通っていますが、テストの基準自体が異なっていることが多いという点です。
「完了」の定義が決定した後に「テスト」を行うわけですが、ここで主に用いられる技法が「ブラックボックステスト設計」「探索的テスト」です。
・ブラックボックステスト設計
開発者のプログラミング作業と並行して、ユーザストーリーと受け入れ基準に基づいてテスト項目を作成する作業のことです。
従来型のブラックボックステスト設計技法と同じものであるため、「Webアプリケーションにおけるテストの役割とは？項目や工程まで細かくご紹介」の3-3に記載がある技法が適応できます。
・探索的テスト
探索的テストとは、テスト担当者がユーザストーリーに沿ってテスト設計と実行を同時に行う技法のことです。
この技法はテストチャータというカバーすべきテスト条件のみが提供され、テスト担当者がリスクであると考える部分のテストを手当たり次第実行する技法であり、テスト分析結果等を元に形作られる経験ベースのテスト手法により良い結果を得ることができます。
これを実施する利点としては、短時間で成果を生み出しやすいということが言えます。
ただし、テスト担当者の想像力・直感・認識力・スキルといった様々な要素に左右されるものであるため、テスト担当者のプロジェクトへの理解が不可欠であるテスト手法です。
また、探索的テストは設計と実行が同時に行う関係上、文書化が十分でないとどのように問題が発見されたかを遡って確認することが困難になるため、行ったテストについては正確に文章化することが重要です。
当社では、ここまで説明したスプリントを期間で区切る手法ではなく、「カンバン」というアイテム単位でリリースを可能とするアジャイルアプローチを実践したことがあります。
そこでは、タスク管理ツールにて対象の成果物のタスクに対してテストステータスを変更していくという形でブラックボックステストとリスクの高いと判断した箇所の探索的テストを行っていました。
このプロジェクトはチーム内のコミュニケーション量の多さからテスト指針が定まらないことや障害の作りこみというリスクの回避はできました。成果物をリリースするたびにステークホルダーや開発メンバーとのやり取り、仕様変更の中でそれに合わせたテスト工程の改善を実行し、より良い品質が実現できたと考えています。
しかし、筆者がプロジェクトに途中参画したという経緯があったため、テスト分析による工程改善やステークホルダーへの価値提供という面が活かしきれなかったことは反省点です。
反省点も時期が進むに連れて改善していきましたが、やはりアジャイル開発におけるテスト分析は積み上げていくものであるため、初期からチーム全体で意識して行っていた場合と差ができていたと思われます。
アジャイル開発のテスト導入でより質の高い製品を
ここまで、アジャイル開発におけるテストについてお話してきました。
最初に記載したように、正しい理解の元で準備を行わなければ上手くいかないリスクを多く抱えていますが、正しい理解の元準備を行うことで従来の開発工程以上の成果をもたらしてくれます。
特に今回はテストにフォーカスを当てた記事であったため、テスト担当者に求めるレベルが大きく上がっていることが理解できたと思いますが、それを満たせるテスト担当者がチーム内に在籍している場合は、より高品質の製品を作るためにアジャイル開発という選択肢があるということを理解し、検討していただけると幸いです。
