🚀 Registered Agile Testing 研修レポ：高速なリリースサイクルと確かな品質を両立するために

こんにちは、SETエンジニアをやっています。
先日、「Registered Agile Testing 研修」に参加してきました。全2日間の濃密なセッションを通じて、アジャイル開発におけるテストの在り方を学んだので、その概要と学びの備忘録です！

📝 研修概要

• 日程：2025年2月6日～7日
• 場所：虎の門ツインビル
• 時間：9:30〜17:00
• 参加者：DEV、QA、マネジメント、顧客サポート、etc

2日間みっちり座学と演習があり、「アジャイル開発とテストをいかに両立させるか」 というテーマを、マインドセットから具体的なプラクティスまで学ぶ場となりました。
講師の方や他社参加者との意見交換が多く、さまざまな業種・規模の現場事例を知れたのも大きな収穫でした。

💡 参加動機

• 自分の役割であるSETエンジニアとして、自社の開発プロセスにどのように寄与できるか明確化したい
• 意味のあるテストや自動テストを増やすためのネタ探し

参加者の中には自動テスト導入の成功事例や、テスト手法を体系的に学びたい方が多かった印象です。
自分は業務において自動テストを拡充中ですが、品質を維持しながら、リリース速度を上げるための効果的なアプローチを知りたいと思って参加しました。

⭐ 研修を受けた感想

• アジャイル開発時代の「テスト＝工程ではなく、テスト＝活動」という考え方が腑に落ちた
• “ユーザー視点の品質” をいかに確保するかを中心に、具体的なプラクティスを学べた
• E2EテストやGherkinといった自動化技術のポイントをあらためて整理できた

特に、関係者(顧客、コンサル、QA)との対話を通してワンチームで外部品質を意識する重要性について深く再確認できたと思っています。

🤔 そもそもアジャイルテストとは？

ウォーターフォール型開発では、開発が完了した成果物を別部門がテスト、バグ報告、修正…という流れでした。
しかしアジャイル開発では、不明な点は多い前提で、早いフィードバックと小刻みなリリースを繰り返すため、テスト工程も同時並行で走らせる必要があります。

• テスト＝開発の最終工程ではなく、開発プロセスと一体となった継続的な活動
• 目的に応じて、探索的テスト・ペアテスト・自動テスト・BDD/TDD/ATDDなどを使い分ける

🔽 実務への落とし込みポイント

1. 🏳️‍🌈 アジャイルテストマニフェストを掲げる

• 「テストは品質を検証する工程ではなく、継続的に価値を高める活動である」
• 組織全体のマインドセットを変える第一歩として、マニフェストを常に意識・共有することが大事

2. 🐞 バグを出さないではなく、価値を高めるテストへ

• 従来の「バグを減らすこと」だけを目的にしたテストから卒業
• チーム全員が「なぜこの機能を作るのか」を理解し、品質を作り込む視点を持つ
• アジャイルテストの4象限などを活用し、テストの目的をはっきりさせる

3. ⚙️ 開発者をサポートしやすい自動化の仕組み

• テストの自動化はアジャイルには必須。短いスプリントで何度もテストが回るので、再現性と速度が重要
• QAやQEとしては、GherkinやBDDを活用し、仕様をコードとして自動化しやすい体制を整える
• 分担しすぎず、DEV/QE/QAがワンチームで取り組む

具体的な例

• Gherkinでのシナリオ記述 → Codecept.jsなどのテストフレームワーク → CI/CDパイプラインで自動実行
• 「Gitプルリク作成時に自動テストが走る」フローを標準化し、コードレビューと合わせて品質を高める

4. 🔄 QA2AQ（Quality Assurance → Agile Quality）への移行パターン

• すでに大規模な組織を運営している場合、一気にアジャイルへ移行するのは難しい
• テスト工程をシフトレフトさせ、早い段階で品質確認を行うことで、バグや仕様漏れを最小化
• 理想と現実の差分を埋めるには、小さく実験して効果検証しながら進めるのがおすすめ

📊 アジャイルテストに適した指標は？

• ウォーターフォール開発のように、バグ件数やテストケース数だけを見るとアジャイルの価値を見失いやすい
• 代わりに、「市場に出すまでのリードタイム」「DORAメトリックス(速度×安定性)」「プロダクト価値の向上度合い」 などを使うと、真のアジリティを測定しやすい
• テスター個人の評価よりも、チームとしての品質目標を持つ方が、モチベーションやイノベーションが生まれやすい

💪 研修での主なエクササイズ

1. アジャイルテストマニフェストを考える

   • 自社の仕事にはどの項目でどのような具体例が当てはまるのかディスカッション
   • 例：ドキュメントよりも対話を重視するための仕組みづくり、リリース後のフィードバックの活かし方

2. アジャイルテストの4象限を整理

   • それぞれの象限がカバーするテストの目的や手法をグループで洗い出し
   • 組織やプロダクトによって、象限ごとのテスト種別は細かく異なる

3. 探索的テストとペアテストの体験

   • サンプルのWEBアプリを使って、15分間で何個のバグ,改善点を発見できるか挑戦
   • 短時間でも「ユーザーの視点」に立つ重要性を体感

4. QA2AQの有効パターンを検討

   • 組織をアジャイル化する際、どの導入パターンが最適か事例と照らし合わせ
   • 大規模組織は段階的にテスト工程をシフトレフトし、CI/CDパイプラインを徐々に拡張しているケースが多い

5. Gherkinでのユーザーストーリー具体化

   • 実際にGiven-When-Thenを書き、AIでステップを自動生成する演習
   • 「仕様が曖昧だとGherkinが書けない」ことを実感し、要件定義の精度を高めるモチベーションになった

🏁 まとめ & 今後のアクション

今回の研修を通じて得た大きな学びは、テストは工程ではなく活動であるという一言に集約されます。開発チーム全員が品質向上の当事者であり、テストはプロセス全体に溶け込むべきもの。自動化や探索的テスト、BDD/TDDといったプラクティスを取り入れて、高速なリリースサイクルでも確かな品質を目指すことがアジャイルテストの真髄だと感じました。

🔥 今後のアクション

• 自動テストのシフトレフト
  • 品質をQA部門の自動テスト、受け入れテストに頼らず、開発の早い段階で実行する自動テストの量を増やす
• Gherkinのシナリオ記述ルールをチームで定義
  • E2E、ユニットテストを中心に外部仕様のカバレッジを向上させ、テスト自動化と管理を強化

今回、集中して体系的にアジャイルテストを学べたことは知識の整理のためにとても良かったです。
これからも学んだことを活かし、具体的なテスト戦略や負債化しないようなテスト作りを計画しながら、自社の開発環境や組織文化に合った形でアジャイルテストを進化させていきたいです✨