【第3回】アジャイルQAプラクティス

現在は「VUCAの時代」と言います。VUCAとはVolatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとったビジネスシーンで使われる言葉です。これら4つの言葉が表すとおり、「未来の予測が難しい状況」を表しています。

過去を振り返ると、使い古された言葉になりますが、高度経済成長時代に象徴されるように「作れば売れる」時代でした。しかし、VUCAという言葉が登場したように、現在は、「何が売れるかわかりにくい」状況に陥っています。ソフトウェア開発においても「何を作ればいいかわからない」時代になっています。

この連載では、現在やこれからの時代で求められるであろうソフトウェア開発における「品質」を再定義し、あるべき姿への道筋を示し、代表的なプラクティスなどを紹介しながら、アジャイルQA（アジャイルな品質保証、もしくは品質合意）活動や、具体的な手段としてアジャイルテスティングのあり方を議論していきます。

3回目のテーマは、アジャイルQAを実現するための具体的な方法を考えていきます。

アジャイルテスティング
プラクティス：広義の自動化を行う
プラクティス：探索テストを実施する
まとめ

アジャイルテスティング

ソフトウェア開発において、「QA（品質保証）」という言葉は広く知られています。よって筆者は、「アジャイル開発における品質改善活動」を「アジャイルQA」と呼び、QAと使い分けて使っています。

アジャイルQAに似た意味を持つ言葉として、「アジャイルテスティング」があります。アジャイルテスティングにはいろいろな流派があるようなので（参考：アジャイルテスティング問答 – 千里霧中）、ここでは「アジャイル開発をうまく支えるためのテストや品質保証のアプローチ」としています。

参考記事にもあるように、アジャイルテスティングはプロセスや方法論ではなく、テストや品質に関わるエンジニアのマインドセットやチーム文化、本質的な価値や原則と言えます。

よって、具体的なプラクティスが定義されているわけではないので、関連する書籍や文献を読むだけではマインドセットや精神論で思考停止してしまう可能性があります。

アジャイルテスティングが価値や原則であるならば、それらを実現するためのプラクティスが必要になります。「アジャイルQAはこうはじめればいい」や「これをやればアジャイルテスティング」といったものを定義するのは難しいですが、いくつかの現場でアジャイルQAを目指していく上で、共通解のようなものが見えてきたので、それらをまとめてみようと思います。

プラクティス：広義の自動化を行う

スピードと品質を両立するためには、自動化が必須です。たとえば、前回紹介した継続的デリバリーの成熟モデルには、以下のような自動化が記載されています。

ビルドの自動化（CI）
環境構築の自動化
デプロイ・リリースの自動化（CD)
テストの自動化

開発には流れがあります。流れのスピードを落とさず、無理なくすすめるためには、全体の最適化が必要になってきます。なぜなら、どこか一部分だけ速くなっても、他の部分がボトルネックとなり、全体としてのスピードが落ちてしまうからです。

スピードが遅くなるよくある原因をいくつか紹介します。

ビルドに時間がかかる問題

システムが巨大であり、かつモノリシックなケースだと、ビルドに時間がかかりすぎてしまいます。さらに影響範囲が広くなりがちな複雑なシステムだと、プルリクエストやコミットが巨大になりがちです。

これらを解決するためには、マイクロサービス化などによって、小さい単位でデプロイ可能なアーキテクチャが必要になってきます。

テストする環境がひとつしかない問題

最後にまとめてテストするプロセスだと、テスト環境、QA環境、STG環境といった環境自体がボトルネックになりがちです。

テストデータが分離できておらず、ユーザ同士で共有してしまうと、依存関係によってテスト結果に影響が出てしまいます。少人数で洗えば「みんなで気をつける」ルールでまかなえますが、この方法はすけーるしません。いずれは、「ひとり1環境」という理想の状態を目指していく必要があります。もちろん、環境構築も自動化すべきです。

リリースが遅い問題

開発がいくら速くても、リリースに時間がかかってしまうのはもったいないことです。複雑なシステム間の依存関係により、リリースの難易度が上がってしまいます。

作ることよりも、価値提供に主眼を置くアジャイル開発では、リリースまでスピーディーにやりぬける仕組みが必要になります。

マニュアルテストだけでなんとかしている問題

もし、あなたの現場が大人数のテスターをアサインできるのであれば、アジャイルな開発に対してアジャイルなテストが実現できるかもしれません。

もしそれが難しいのであれば、限られたリソースでどのように品質を改善していくか考え直さなければなりません。そうしなければ、テストを行う行為がどんどんボトルネックになっていきます。

テスト自動化については、別の記事で、ベストプラクティスを紹介する予定です。

プラクティス：探索テストを実施する

探索テストとは、従来型のテストケースを作ってそれを消化していく形ではなく、特定の観点や時間配分などを制約にして柔軟にテストを行っていく手法です。

詳しくはここでは解説しませんが、アジャイル・DevOps時代では、探索テストが注目されてきています。

従来型のように網羅的なテストを作成し、それを粛々と消化する方法は、イテレーション・スプリント型の開発では大きなコストになってしまいます。もちろん、テストのスコープ調整等で量をコントロールできますが、「バグがゼロであること」が当たり前という価値観を持った顧客の場合、スコープ調整は難しくなるでしょう（そこで自動テストが役立ったりもしますが）。

また、テストを減らすのに抵抗を感じる場合もあるでしょう。「どうせやれるならやりたい」、「やらないのは不安」とメンバーが心理的に考えてしまう傾向があるからです。これは間違いではなく、当然の心理だと思います。

一方で、誤解を恐れずに書くと、探索テストはコスパの良いテストです。観点の数や時間に合わせて、テストの質は落とさず、テストの量をコントロールしていきます。ざっくりまとめるなら、「やれることを全部やるテストではなく、やれるだけのことをやるテスト」です。

ただし、前提として「すべてを網羅するわけはない」ことが課題として挙げられます。よって、以下のような対策によって、心理的な不安を取り除き、品質に自信を持つ環境を作っていく必要があります。