先日、「人類よ！これがアジャイルテスティングだ！QAテックリードが語るアジャイルQAの実践とは何か？ - connpass」というイベントに登壇させていただきました。
インタビュー形式だったので講演資料などは特に残ってないのですが、内容の記録のため公開に差し障りのない問答についてまとめたいと思います。念の為、一般的な定義というより、あくまで自分なりの考えになります。
Q. アジャイル開発におけるQAエンジニアの役割と責任は?
QAエンジニアの定義に幅があるので難しい問いですが、今回はプロダクトの品質を保証する役割の人を、QAエンジニアという前提で話します。
まずアジャイル・ウォーターフォールなどプロセスを問わない役割として、QAエンジニアは、様々な品質を保証する手段を直接担当したり、支援したりして、総体として品質を保証する仕組みを構築する役割だと考えています。
直接担当の役割としてはQAテスト、ドキュメントレビューなど、支援担当としては開発者テスト支援、プロセス運用支援、スプリントレビュー支援などが該当します。
次にアジャイル特有のQAエンジニアに求められる役割として、次の3点が大きくあると思います。
- 1つめは、ユーザ観点での妥当な継続的フィードバックの実現です。
動くプロダクトを作ってフィードバックを得て、より妥当なプロダクトを実現するサイクルを継続的な回せるのがアジャイルの強みです。それを支えていく役割です。
具体的には、ユーザテストなどユーザからのフィードバックの機会を確保する、POと連携する、QAエンジニア自身がビジネスやプロダクトに詳しくなるといったアプローチで、ユーザ観点で妥当なフィードバックを継続的にチームに返せるようにするのが重要になります。 - 2つめは、迅速なフィードバックの実現です。
アジャイルの短期のイテレーションや高頻度な変更に対応するため、品質保証のスピードをアジャイルに合わせる必要があります。その迅速化を実現する役割です。
その手段としては、自動化を始めとした品質保証の高速化技術を実践する、探索的アプローチで人間の能力主体でアジリティを確保する、といったものがあります。 - 3つめは、Whole Team（チーム全体、Oneチーム化）として品質を保証する仕組みの実現です。
ウォーターフォール的に、最終関門として最後に詳細なテストを最後にやるアプローチでは、変更に弱く、アジリティが低すぎて、アジャイルを阻害します。
その解決として、開発者テスト、QAテスト、自動テスト、レビューなど、様々な品質保証の手段を連携させて、Whole Teamで品質保証していく仕組みづくりが、重要な役割だと考えます。
Q. アジャイルテスティングとは何か？
一般的には、大きく2つの定義があります。
- 1つ目はジャネットグレゴリーの実践アジャイルテストなどが提唱する、テストそのものがアジャイルの原則に則っているアプローチ。
- 2つ目は、ISTQBなどが提唱する、アジャイル開発をうまく支えるためのテストのアプローチが、アジャイルテストであると言う定義。TDDや継続的テスティングなどがこれに該当します。
今回は後者の定義で話を進めます。
基本的な方向性は、前述のQAエンジニアの役割を、テストで推進する形になります。様々ある中での一部ですが、具体的には次のような特徴を備えます
- ユーザ観点の継続的なフィードバックをテストで実現します。
ユーザテストを導入する、イテレーション内でシステムテストまで一通り行って、テストレベル横断のフィードバックを実現する、ビジネスやユーザに精通してそれらの観点に基づいたテストを実施する、といった特徴があります。 - 変化を受け入れます。例えば柔軟に変更に対応するため、テストは自動化しますし、テストの保守性やテスタビリティの向上で、変更コストを削減していくアプローチが取られます。
注意として、アジャイルテストはプロセスや方法論と言うより、テストエンジニアのマインドセットやチーム文化、本質的な原則論です。
何かしらの手順通りにやればOKというものではなく、例えば開発者やPOとうまくコミュニケーションをとって、的確なテストを見出そう、みたいな姿勢の話になります。
Q. アジャイルテスティングをどうはじめればよいのか？
繰り返しですが、アジャイルテストはマインドセットやチーム文化、原則論の話になります。そのためその導入は人作り、チーム作りが主なアプローチになります。
その前提の話ですが、最初の方向性として次があると思います。
- 妥当なフィードバックの実現を目指す。ユーザやPOと連携したり、テストチーム自身もプロダクトやビジネスについて精通したりして、ユーザ観点で妥当なテストを行えるようにチームを鍛えるのが最初の方向性だと思います。
- アジャイルに合わせたアジリティの実現を目指す。最初は、手動テストから自動テストへの注力の転換、スクリプトテストから探索的テストへのアプローチの転換が取り組みやすいと思います。そこでは自動テストでリグレッションテストを実施しつつ、探索的テストで追加変更分をテストするスタイルを目指します。
上記の本質的な実現には、プロセスや手順の強化ではなくて、チームと人の強化に注力する必要があります。
Q. アジャイルテスト実現のためにテストのアジリティを高めるために何が必要か？
一言でいうと、人と開発技術とテスト設計の3つを鍛えていく必要があると思います。
人の強化
スピード重視のテストでは、探索的テストのアプローチが重要になります。一般的にも、アジャイルテストは探索的アプローチを取り入れたユーザストーリテストが定番の手段になります。
もちろんスクリプトテストが不可欠であるのは変わりないですが、伝統的なスクリプトテストは遅く、変化への妨げになります。スクリプトテスト、探索的テスト両方を組み合わせつつ、後者の比重を高めていきます。
この探索的なアプローチで有効なテストを行えるようにするためには、テストエンジニアを育てて、その能力を発揮させる必要があります。すなわちテストのアジリティを上げたいなら、テストエンジニアを精鋭化する必要があります。
開発技術の強化
アジリティのあるテストには様々な開発スキルが必要です。具体的には次が求められます：
テスト設計力の強化
アジリティあるテストを実現するためには、少ない手間で、十分なテストを実施する必要があります。
そこでは本質的な仕様やリスクを読み取って、ピンポイントでそれに対応する的確なテストを用意する必要があります。そのためには、チームのテスト分析やテスト設計のスキルを高めておく必要があります。
Q. テスタビリティの必要性とは？
テスタビリティの確保は、手動テスト、自動テスト、あるいはユニットストからEnd to Endテストまで問わず、アジャイルテストでとても重要です。
テスタビリティの確保は、アジャイルテストの要のテスト自動化のやりやすさにつながります。例えばテスト自動化を不能にする要因の影響範囲を小さくして、テスト自動化を実現できる範囲を広げたりするといったアプローチが可能になります。
またテスタビリティ確保は、変化に強いテストを実現するためにも必要です。例えばテストの変更性を高めて、アジャイルで継続的に変更する状況下で、テストが頻繁に壊れる問題(Fragile Test)を軽減する、といったことが可能になります。
テスタビリティの詳細や、具体的な実現アプローチについては以下を参照ください。
アジャイルテストで大規模テストに対応するにはどうするのか？
次の３方向の対応が有効だと考えます。
- 1点目は、当たり前だと思いますが、チームの基礎的なテスト力を高めて、テストのスピードや妥当性を上げていくことが重要です。
- 2点目は、テストアーキテクチャの組み立ての工夫が重要になります。プロジェクトを通して、大規模なテストアーキテクチャを育てていき、それに沿ってイテレーションごとのアジャイルテストを導いていくアプローチが重要です。日々の継続的なテストを、乱雑に積み上げるのではなく、全体整合が取りやすいように蓄積するアプローチです。
- 3点目は、フロントローディングです。大規模テストの負荷・リスク対応・不具合検出を、日々のイテレーション内のテストで継続的に前倒し対応して、大規模なシステムテストの負荷を分散するアプローチが重要になります。
