はじめに
QA*1エンジニアの渡辺です。
先日、子どもの夏休みにあわせて1日中プールにいたら、熱中症になりました。
普段は冷房が効いた室内で仕事してますので、休日あまり外ではしゃぎすぎると大変ですね。。
今回は、私がQAを担当しているローンチ前サービスのプロジェクトでテストプロセスをどう定義し、
プロジェクト状況に応じてどのように改善しようとして、
結果どうだったかをアジャイルテスト4象限に照らしながら共有できればと思っています。
アジャイルテスト4象限って、実際やってみてどうなんだろう？と考えている方の参考に少しでもなれば嬉しいです！
アジャイルテスト4象限とは？
アジャイルテスト4象限は、テストのフレームワークの一つです。テスト活動を構造化し、アジャイル開発プロセスに適合するよう設計されています。
このモデルは、ビジネス寄りと技術寄りの2つの側面に加え、「支援」と「評価」の2つの目的に基づいており、
この4つの要素で、テスト活動を4つの象限に分類しています。
| 象限 | 内容 | 支援or評価 | テスト例 |
|---|---|---|---|
| 第1象限(Q1) | 技術に焦点を当てて、プロダクトが仕様や要件に適合しているかどうかの検証 | 支援 | 単体テスト、結合テスト |
| 第2象限(Q2) | ビジネスに焦点を当てて、プロダクトが仕様や要件に適合しているかどうかの検証 | 支援 | 機能テスト、ストーリーテスト |
| 第3象限(Q3) | ビジネスに焦点を当てて、プロダクトが目的に合っているかどうかの検証 | 評価 | シナリオテスト、探索的テスト |
| 第4象限(Q4) | 技術に焦点を当てて、プロダクトが目的に合っているかどうかの検証 | 評価 | 非機能テスト（パフォーマンス、負荷、セキュリティなど） |
アジャイルテスト4象限は、テストの多面性を理解し、どのテスト活動がプロジェクトにとって重要かを判断する助けになります。
このモデルを用いることで、開発チームとテストチームはより効率的に協力し、質の高い製品を迅速に市場に投入することができるとされています。
引用元URL：https://www.scrum.org/resources/blog/how-the-four-agile-testing-quadrants-support-scrum-teams-jp 参考： www.scrum.org
プロジェクトチーム構成
本プロジェクトのチーム構成ですが、4つの機能開発チームに分かれた状態でプロジェクトはスタートし、
それぞれの機能開発チームにQAエンジニア*2が1名入っておりました。
しかし、6月にチーム体制は変わり、機能開発は3チーム、QAは1つのチームとしてまとまることとなりました。
テストプロセスの変化と改善内容
フェーズ１：テスト計画時のテストプロセス
プロジェクト初期のテスト計画時は、以下のテストプロセスを定義していました。
- 機能テスト
1つのユーザーストーリー単位での開発完了毎に以下を実施
| テストプロセス | 内容 |
|---|---|
| テスト設計 | 要件/テストシナリオ整理→テストケース設計→テスト自動化範囲検討 |
| テスト実行 | 手動テスト実行、テスト自動化＋自動実行→バグ報告/連携/再テスト→テスト報告 |
なお、以下のテストも行う予定でしたが、開発完了時期に予定のため、計画時に詳細は未定義でした。
- シナリオテスト
- 負荷テスト
- 脆弱性診断テスト
上記の機能テスト時のテストプロセスに従い、機能テストから開始しましたが、
メンバの得意分野とスキルセットもそれぞれ異なるため、チーム毎にうまくフィットしない部分がありました。
フェーズ２：チーム体制変更に応じたテストプロセス改善
6月にチーム体制が変わり、今までうまくフィットしなかった部分の対策を含め、ローンチまでのテストロードマップを作成しました。
シフトレフトが実現できるよう、テスト分析と探索的テストを追加し、機能テストにおけるテスト分析、テスト設計、テスト実行、探索的テスト実行、E2Eテスト自動化を、個人のスキルセットに合うように担当を割り振りました。
(E2Eテスト自動化は、機能テストの一部でやろうとするとするには限界があったため、独立して担当を割り振り、自動化担当は自動化に専念してもらうことにしました。)
第三者検証企業より参画いただいているQAエンジニア/管理者も、課題を常時共有して対策の提案をしてくださったので、
相互に意見交換することで、今までの課題を解決できる計画への改善がしやすく、これも改善に繋げられた一因になります。
対策案を含めたテストロードマップがアジャイルテスト4象限に被るところがあり、この4象限のフレームワークを軸に考えながら改善を行いました。
※赤字：フェーズ2での改善ポイント
| テストプロセス | テスト単位 | 内容 | アジャイルテスト4象限での分類 | テストケース作成 | スピード | テスト密度 |
|---|---|---|---|---|---|---|
| 機能テスト分析 | 機能要件 | 要件における品質リスクの確認、ストーリー毎のテスト観点の洗い出し | Q2：機能テスト | 有 | 遅い | 高い |
| 機能テスト設計 | 機能設計 | バリデーションの検討、テスト仕様作成→テストケース設計 | Q2：機能テスト | 有 | 遅い | 高い |
| 機能テスト実行 | 機能設計 | テスト実行→バグ報告/連携/再テスト→テスト報告 | Q2：機能テスト | 有 | 遅い | 高い |
| 探索的テスト実行 | バックログのタスク単位 | 要件に対する基本的な動的動作を確認するストーリテストと、探索的テストを混ぜる | Q2：ストーリーテスト、Q3：探索的テスト | 無 | 早い | 中 |
| E2Eテスト自動化 | 機能設計 | ストーリーテスト、機能テストの一部を自動化 | Q2：ストーリーテスト、機能テスト | 無 | 早い | 中 |
| シナリオテスト | 全体 | プロダクトが完成後、実際の運用のシナリオを想定してテスト | Q3：シナリオテスト | 有 | 中 | 中 |
元々、フェーズ1では単純なテスト設計→テスト実行をベースとしていましたが、フェーズ2でアジャイルテスト4象限のフレームワークを当てはめることで、
プロダクトの本質として必要なテストを網羅的に、俯瞰して考えることができた感があります。
ただ、開発の状況から、1つの開発タスクをテストするために必要な前提のUIが完成していないなど
バックログのタスク単位 (=JIRAの1エピック) で実行を予定していた探索的テストが開発完了後すぐに実行できないことが多く、
実行できたとしても、想定外の動作によるバグ検出はまだこの時点ではPMが求めていなかったなどの問題も出てきました。
フェーズ３：開発状況に応じたテストプロセス改善
バックログのタスク単位のテストは、ストーリーテストのみとして、探索的テストはプロダクト全体が完成に近づいてから行うこととしました。
※赤字：フェーズ3での改善ポイント
| テストプロセス | テスト単位 | 内容 | アジャイルテスト4象限での分類 | テストケース作成 | スピード | テスト密度 |
|---|---|---|---|---|---|---|
| 機能テスト分析 | 機能要件 | 要件における品質リスクの確認、ストーリー毎のテスト観点の洗い出し | Q2：機能テスト | 有 | 遅い | 高い |
| 機能テスト設計 | 機能設計 | バリデーションの検討、テスト仕様作成→テストケース設計 | Q2：機能テスト | 有 | 遅い | 高い |
| 機能テスト実行 | 機能設計 | テスト実行→バグ報告/連携/再テスト→テスト報告 | Q2：機能テスト | 有 | 遅い | 高い |
| ストーリーテスト実行 | バックログのタスク単位 | 要件やユーザーストーリーに対する基本的な動的動作を確認するテスト | Q2：ストーリーテスト | 無 | 早い | 中 |
| 探索的テスト実行 | 全体 | 探索的テスト | Q3：探索的テスト | 無 | 早い | 中 |
| E2Eテスト自動化 | 機能設計 | ストーリーテスト、機能テストの一部を自動化 | Q2：ストーリーテスト、機能テスト | 無 | 早い | 中 |
| シナリオテスト | 全体 | プロダクトが完成後、実際の運用のシナリオを想定してテスト | Q3：シナリオテスト | 有 | 中 | 中 |
フェーズ3の改善により、だいぶ現在のプロジェクト状況に適した形になってきた感があります。 ただ、課題はまだ挙がることがあるので、今後も状況に応じた改善は必要と考えています。
アジャイルテスト４象限に照らしてどうだったか？
アジャイルテスト4象限の効果（メリット）
アジャイルテスト4象限を軸にしてテストを考えることは、プロダクトに必要な品質を検証する目的でメリット感があると感じました。 具体的にメリット感を感じたポイントは以下となります。
- V&V検証*3と比較してプロセスフローが固定化されておらず、前工程の完了が次工程の開始条件になるわけでもないので、状況の変化に応じてカスタマイズしやすく、変化に強い。
- エンジニアは第1象限主体、QAは、第2象限と第3象限を主体としてバランス良く組み合わせることで、各役割とスキルに適したテストを効率的に実施できる。
- プロダクトに本当に必要な品質を改めて考えさせてくれる。
アジャイルテスト4象限を軸にしてテストアプローチを検討する際の留意点
メリット感がある一方で、アジャイルテスト4象限はテスト分類のフレームワークであり、具体的なプロセスがあるわけではなく自由度が高いので、
気をつけて活用しないと品質と開発スピードのどちらも確保できない可能性もあると思いました。
具体的な留意点としては以下があるように感じました。
- テストの単位とタイミングを状況に応じてカスタマイズする必要がある。
- 開発やプロダクトの状況は日々変化していくので、変化に追従して日々小さな改善の積み重ねもしていく必要がある。
- ストーリーテスト、探索的テストなど、テストのタイプはいくらでも追加できる反面、追加しすぎるとテスト管理が難しくなり、テスト進捗がリリース遅れの原因になりかねないので、プロダクトとして重視すべきテストの検討をしたり、自動化率を高めることが必要。
まとめ
アジャイルテスト4象限を軸にしてテストを考えた時、このフレームワークは品質と開発スピードを両立するために必要な要素がシンプルに設計されていると感じました。
品質管理や品質保証における手法やアプローチは様々なものがあります。
計画時からある手法に当てはめるパターンと、実践/改善中に偶然にもある手法に近づいていき、
その手法に照らして考えていくパターンがあるとすると、今回は後者でした。
いずれにせよ、どのような手法でも、状況に応じたカスタマイズ（テーラリング）は重要だと感じました。
今後
Q4の非機能系のテスト（パフォーマンス/負荷に対するテストやセキュリティテスト）については、今回テストタイミングが後半になってしまいましたが、
開発初期からシフトレフトで組み込めればより良くなると感じました。
これを実現するためには、ツールの活用や、エンジニアやSREチームと一体になって対策を検討していくことが重要と考えています。
ローンチ後は、よりアジャイル開発に適したアプローチとなるよう、
- 第3象限（Q3）：利用時の品質を確認する探索的テストの割合を増やす、ビジネスサイドにも動作してもらう
- 第2象限（Q2）：自動テストの割合を増やす（自動化率の向上）
にシフトしていけたら良いなと考えています。
最後に
アソビューでは、「生きるに遊びを」をより実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを募集しています。
カジュアル面談もしておりますので、お気軽にエントリーください！ お待ちしております。
