開発はアジャイルだけどテストがウォーターフォール問題

僕はアジャイルにはちょっと詳しいけど、QAにはぜんぜん詳しくないです。ただ、アジャイルコーチとして活動していると「QAをアジャイルにしたい」という相談をよく受けます。そして、いろいろ試行錯誤しながら改善をすすめるのですが、結果的に「開発はアジャイルになったけどテストがウォーターフォール」という状況にいきつくなぁと感じています。

アジャイルQA

QAをアジャイルにしたいお客さまはとても多いです。最近僕はこれを「アジャイルQA」と呼んでいます。アジャイルQAはプロセスであり、プラクティスであり、人でもあります。

もちろんQAもプロセスであり、プラクティスであり、人でもあります。だからすごくややこしい。誤解を招かないように言葉に気をつけているつもりですが、間違いがあったら教えて下さい。

アジャイルコーチの仕事をざっくりいうと、チームの活動に参加しながら、スクラムマスター中心にコミュニケーションを取り、スクラムマスターを育成しながら、アジャイルなチーム、組織、開発を目指していきます。

技術的プラクティスを駆使できるようになると、開発は徐々にアジャイルになっていきます。しかし、QAがボトルネックという問題が浮かび上がってきます。

QAがボトルネック

QAと呼ばれる活動は現場によってそれぞれでしょうが、主に「テストをする活動」が多いように思います。

10人ぐらいの開発規模であれば、テストを担当するQAエンジニアの選択と集中でQAがボトルネックになるのを回避できるようですが、開発がスケールすると、比例してテストの数も増えていきます。また、機能が増えるのでリグレッションテストの数も増えます。

これらが積み重なってどんどん負担になり、QAがボトルネックとなるケースが多くなります。

ウォーターフォールのQAフェーズ

詳しい解説はしませんが、従来型のプロセスであるウォーターフォールでは、フェーズごとに責任を分担していきます。フェーズの中に「QAフェーズ」があるなら、その中ですべてのテストを終わらせ、問題をあぶり出そうとします。

ウォーターフォールにも得意なことはありますが（ここでは割愛）、ウォーターフォールは「間違うこと」がとても苦手です。フェーズのひとつひとつで、それぞれのゴールを満たしながら進んでいくので、後半のフェーズになればなるほど、間違っていた場合の手戻りコストが大きくなってしまうからです。

そのため、QAフェーズでも、間違いがないように、できるだけ網羅性の高いテストを作成・実行します。このテストは何回も繰り返すものでもないので、自動化せず、マンパワーで解決するケースが多いのではないのでしょうか。

アジャイルQAとウォーターフォールQA

ウォーターフォール型のQAをウォーターフォールQAと呼ぶとすると、冒頭にも書いたとおり、ウォーターフォールQAをアジャイル開発に適用している現場が多い気がします。

たとえば、「スプリントの最後にQAフェーズを設け、そこで網羅的なテストを手動で行う」とかです。

はじめはこれでもなんとかなりますが、開発がスケールするにつれてこの方法が通用しなくなってきます。もうちょっと正確に書くと、お金を出してマンパワーで解決できますが、予算や人が潤沢にある現場はなかなかないので（人も金もいつも足りないものだ）、解決策として取り入れるにはハードルが高いはずです。

たとえば、アジャイルQAとウォーターフォールQAでは、テスト方法もちょっと異なってきます。

ウォーターフォールQAでは、網羅的な手動テストと、必要であれば網羅的な手動リグレッションテストが主流です。「必要であれば」と書いたのは、QAフェーズで用意したテストを一通り流すので、わざわざリグレッションテストを作成するより、QAフェーズのテストをもう一度一通り流し、リグレッションテストのように使う場合もあるからです。

繰り返しリリースしないプロセスなので、リグレッションテストの必要性は低いと言えます。自動化のメリットも低いです。

アジャイルQAでは、スプリントという短い期間で品質を高める必要があるので、網羅的なテストなんてやっている時間がありません。よって、必然的に、スコープを小さくし効率性を高めるための探索テストと、繰り返し高速実行できる自動テスト（UTからE2Eまで広義の自動テスト）が必要になります。

探索テストではすべての問題が見つからない可能性があるため、自動テストを併用してカバレッジを高める必要があります。つまり、自動テストなしで探索テストをしてもアジャイルQAにはなれないと言うことです。