アジャイルテスティングってなんだろう？

・・・そんなふうにモヤモヤしながら、仕事していたりしませんか？

先日、Agile CoEに所属している久末と山本が、Scrum Inc. のアジャイルテスティング研修に参加してきました。

なぜこの研修を受けようと思ったのかというと、日々の開発業務の中でテストに関する解像度の低さを感じることが多かったからです。チーム内でのテストに対する認識のズレや、テストプロセスの改善の必要性を感じており、アジャイルテスティングの知識を深めたいと考えていました。

この記事では、研修を通じて学んだ内容や、私たちのテストに対する考え方の変化を紹介します。少しでもアジャイルテスティングの魅力が伝われば嬉しいです。

1. アジャイルテスティングとは？

アジャイルテスティングとは、アジャイルマニフェストで示されている価値基準と原則に基づいたテストの考え方です。ウォーターフォール開発のように開発後にまとめてではなく、開発プロセス全体を通じて継続的にテストを行うのが特徴です。

その中核となるのが、以下の アジャイルテスティングマニフェストです。このマニフェストは、単なる「テストのやり方」ではなく、マインドセットの転換を促す考え方です。

（出典：https://leanpub.com/AgileTesting/read）

ここから、各項目について説明していきます。アジャイルテスティングでは、これまでのテストに対する価値観を保ちつつ、より重点的に価値を置くことを定めています。

• Testing throughout over at the end
  (最後にのみテストする よりも ずっとテストし続ける)
  • 従来のウォーターフォール開発では、テストは開発が終わってから実行するものでした。しかし、素早くリリースしてユーザーフィードバックをもらうことに価値をおくアジャイル開発では、常にテストをし続け、品質を保ちながらプロダクトを提供することが大切です。
  • ポイント：テストは「開発のあと」ではなく「開発とともに」行うものです。

• Preventing bugs over finding bugs
  (バグを発見すること よりも バグを抑止することを重視する)
  • ウォーターフォール開発では多くの場合、テストを実施するのはQAチームのテスター方々です。このとき、開発者がテスターと対立構造になってしまうことが多々あります。バグ探しをして穴を見つけるのではなく、そもそもバグが出にくいようにするという工夫が必要になります。
  • ポイント：「バグを見つける」のではなく、「バグが生まれない」仕組みづくりが鍵です。

• Testing understanding over checking functionality
  (機能性をチェックする よりも チームが理解している価値をテストする)
  • あくまで、機能は価値を生むためのものであり、機能を作り込むことを目的としてしまっては価値提供が不十分になる場合があります。テストにおいて機能が問題なく動いていることを確認することは大切ですが、それよりもシステムが提供したい価値が何か、ということを理解することが大切です。
  • ポイント：「動くかどうか」だけでなく「なぜそれが必要か」を考えてテストを行うことが大切です。

• Building the best system over breaking the system
  (システムを破壊する よりも 最高のシステムを構築する)
  • テストを考えるとき、まずはシステムにバグがないか、どんな動作をしても壊れないか、ということに重きを置くことが多いです。もちろん、システムが壊れないということも大切で、欠かせない観点です。しかしそれ以上に、そもそも価値を提供するうえで最高のシステムになっているか、ということをテストすることが大切になります。
  • ポイント：テストは「壊すため」ではなく「より良くするため」に行うものです。

• Team responsibility for quality over tester responsibility
  (テスターだけの責任 よりも 品質に対するチームの責任)
  • ウォーターフォール開発では、テストはテスターが実施し、開発者に対して問題点を突きつけ修正させる、という構図が一般的だったかと思います。しかし、それではテスターと開発者での対立構造が生まれてしまうことがほとんどです。品質や価値の実現に対して、テスターだけでなくチーム全体が責任を持って向き合う姿勢が大切です。
  • ポイント：「品質」は一人の責任ではなく、チーム全体でつくるものです。

アジャイルテストマニフェストの5つの価値基準をチーム全体が意識することで、今までのテスト観とは異なる価値基準を知ることができ、開発に対する視野が広がります。結果として、開発者とテスターの連携が深まり、円滑なコミュニケーションとともに品質と価値提供の両面で強いチームとなることが期待できます。

再度お伝えしますが、この5つの項目はこれまでのテストにおいて大切にしてきたことも意識しながらも、アジャイル開発をするうえでより大切にしたい価値観を表しています。これまでの価値観が全くよくないものという意味ではないことにご留意ください。

アジャイル開発では、各イテレーション（スプリント）の中で、開発と並行してテストを行います。これにより、早期にバグを発見し、修正することができます。

2. テストはプロセス全体で考える

アジャイルテスティングを理解するうえで、単にテストのタイミングを変えるだけでなく、テストに対する考え方（マインドセット）から捉え直す必要があります。

「計画から本番運用、その後の振り返りまで」を一連のループと捉え、各ステップで適切なテストを配置していく「ホリスティックテスティング（Holistic Testing）」という考え方があり、以下の図のように「∞（インフィニティ）ループ」で表現されます。

（出典：https://daipresents.com/2022/05/09/testing-from-a-holistic-point-of-view/）

開発の各フェーズ（Plan → Discover → Understand → Build → Deploy/Release → Observe → Learn）において、それぞれどんなテストや検証を行うべきかをまとめています。

詳細については、以下の記事を参照してください：
日本語訳版：https://daipresents.com/2022/05/09/testing-from-a-holistic-point-of-view/
原文：https://janetgregory.ca/testing-from-a-holistic-point-of-view/ 

アジャイルテスティングにおいて、テストは開発の最終段階で行うものではなく、開発プロセス全体を通して行うべきものであり、開発者自身もテストに積極的に関わるべきです。アジャイルテスティングを実践することで、より柔軟で迅速な開発が可能になり、高品質なソフトウェアを効率的に提供できるようになります。

3. アジャイルテスティングの重要な概念

アジャイルテスティング研修のなかで出てきた、重要な概念をいくつか紹介し、概要を説明します。ぜひ、これらのキーワードをベースに調べていただくか、実際に研修を受けて理解を深めていただければと思います。

「アジャイルテストの4象限（Agile Testing Quadrants）」

テストを4つの象限に分類し、どのテストをどの意図で使うのか、チーム内で共通認識を持つためのツールです。

この4象限を用いてチーム内でテストについて会話することで、テストの漏れを防ぎ、効率的にテストを進めることができます。各象限のテストをバランス良く実施することで、多角的な視点から品質を評価できます。

各象限についての解説はこちらの記事（https://www.scrum.org/resources/blog/how-the-four-agile-testing-quadrants-support-scrum-teams-jp）をご覧ください。

（引用：https://www.scrum.org/resources/blog/how-the-four-agile-testing-quadrants-support-scrum-teams-jp）

「探索的テスト（Exploratory Testing）」

事前にテストケースを作成しないテスト手法で、テスト担当者が自由にシステムを探索し、バグを見つけ出すことを目的とします。テスト担当者の経験や知識を活かし、臨機応変にテストを進めることができます。

「ペアテスト（Pair Testing）」

2人で協力してテストを行うことで、異なる視点からテストを行うことができ、より多くのバグを発見できます。1人がテストを実行し、もう1人が指示や記録を行うことで、効率的にテストを進めることができます。

「完成の定義（Definition of Done）」と「受け入れ基準（Acceptance Criteria）」

完成の定義はスクラムで用いられる言葉で、「完成」とは単に機能が実装されただけでなく、品質が保証された状態を指します。例えば、「ユニットテストが通っている」「CIパイプラインが成功している」「コードレビューが完了している」といった基準が完成の定義として考えられます。完成の定義を明確にすることで、チーム全体の品質意識を高め、コードの品質向上に繋がるため、チームで話し合い、合意形成することが重要です。

一方受け入れ基準とは、ストーリーや機能に関する作業が「完了」と見なされるために満たすべき具体的な条件のことです。これを明確に定義するための会話をチーム内で行うことで、プロダクトオーナー・開発者・テスターの間で期待する成果に対する共通認識が生まれます。曖昧な受け入れ基準は、手戻りや認識のズレの原因となるため、具体的かつ検証可能な形で設定することが重要です。

「実例による仕様（Specification by Example）」

具体的な例を用いて仕様を記述することで、関係者間の認識のズレを減らし、テストの精度を高めることができます。仕様を具体的な例で示すことで、開発者やテスト担当者は、より正確に要件を理解し、テストケースを作成できます。

「Gherkin」

Gherkinとは、「Given・When・Then」 といったキーワードを使って、ソフトウェアの振る舞いや仕様を自然言語で表現する記法の1つです。ソフトウェア開発の専門家ではないビジネス担当のメンバーでも理解・記述しやすいのが大きな特徴です。そのため、開発チームとステークホルダーの間で認識を合わせ、共通理解を築くための有効な手段として活用できます。

---

これらの概念について理解を深めることで、アジャイルテスティングマニフェストに準じたテストの実現に近づけることができます。

4. 研修で得た学びと気づき

研修を通して、アジャイルテスティングという概念への解像度がかなり高まったと感じました

まず強く感じたのは、テスターのみならず開発者もテストの専門性を持つことが非常に重要だということです。これまで多く行われてきたウォーターフォール開発に慣れている人にとって、テストは「開発の最後に行うもの」「品質保証部門の専門家が担当するもの」と認識されているケースが多くあります。しかし、アジャイルテスティングでは、テストは単なる確認作業ではなく、品質を保証するための重要なプロセスであり、開発者自身もテストに対する専門性を持つことが求められます。

特に、開発者が意識的に行うポイントの1つがテストの自動化です。アジャイル開発では、リリースを頻繁に行うため、手動テストだけでは対応が追いつかなくなります。テスト自動化を導入することで、テスト効率を大きく向上させることが可能になります。確かに初期コストはかかりますが、長期的に見れば、手戻りの削減や開発スピードの向上といった大きなメリットが期待できます。

次に、受け入れ基準の明確さが極めて重要であるという学びもありました。過去の経験をふりかえってみても、受け入れ基準が曖昧なまま開発を進めてしまい、後工程で多くの問題が発生することがありました。受け入れ基準が不明確だと、テストケースの作成が難しくなり、網羅性が不十分になります。また、開発者とテスト担当者との間で認識のずれが起こり、結果として手戻りが増える原因にもなります。

このような課題を防ぐためには、ステークホルダーとの密なコミュニケーションが不可欠です。要件を具体的な例で示しながら、受け入れ基準を明確に定義することで、認識のずれを減らし、テストの精度を高められると学びました。

今回の研修では、具体的な事例や議論を通じてテストという活動に対するマインドセットの大切さを改めて痛感しました。中でも印象的だったのは、「テストはチーム全員で一緒に品質を作り込むためのものである」という考え方です。これまで「バグを見つけること」がテストの目的と捉えられがちでしたが、アジャイルテスティングでは、開発プロセス全体を通じて品質を向上させるための活動としてテストが位置づけられています。早期からテストについてチームで会話し、その結果を素早く開発にフィードバックすることで、エンドユーザーにとって価値が高いソフトウェアを生み出せるのです。

アジャイル開発に慣れていない顧客と共にプロジェクトを進める際には、初期段階からテストを意識し、前提条件を揃えていくことが非常に重要です。これにより、手戻りが減り効率的な開発につながることを実感しました。こうした考え方を顧客にも伝えていくことが、価値のあるプロダクトを創るうえでの鍵になると感じました。

5. まとめ

今回の研修を通じて、アジャイルテスティングの重要性を強く実感するとともに、テストに対する解像度がより高まったと感じています。今後は、研修で得た知識や気づきをチーム内で積極的に共有し、テストプロセスの改善に取り組んでいきたいと考えています。

中でも特に重要だと感じたのは、以下の3点です：

1. 開発者自身がテストに関する専門性を持つこと
2. 受け入れ基準を明確に定義すること
3. テストに対するマインドセットを変えていくこと

アジャイルテスティングでは、品質は特定の担当者に任せるのではなく、チーム全体でつくり上げていくものだという意識が求められます。今回の学びを活かしながら、より良い開発の実現に貢献していきたいと思います。

※この記事は@k-yamamotoとの共同執筆です