ソフトウェアテストの2つの課題
朱峰錦司氏：ここからは課題の話になります。冒頭で取り上げたとおり課題はいろいろありますが、今日はソフトウェアテストに話題を絞ります。
ポイントは大きく2つあると思います。1つ目は「早くしないといけないのだから、遅くなっちゃいけないよね」です。当たり前の話です。ソフトウェアテストが足を引っ張らないこと。
でも、扱うものがどんどん複雑になって、どんどん大きくなっていくので、テストにかかる時間は当然延びてしまいます。専任であってもなくても、ソフトウェアテストに関わっている人は何かしらの工夫をして生産性を上げないと、デリバリーのボトルネックになってしまいます。それはまずいです。ソフトウェアテストの生産性をいかに上げるか、これが非常に重要なポイントになってくると思います。
（スライドを示して）これはけっこう重要な話だと思って、2つ目の課題として持ってきました。事前にもらったアンケートの中でも「大規模に限らず、なるべくドキュメントを書かずにうまく開発するためにはどうしたらいいのだろう」という質問をいただきました。
これは本当に根深い問題というか、長らく業界で扱われてきた問題かと思います。その1つとして「何を作るのか」ではなく、「なぜ作るのか」をちゃんと共有することです。基本的に、人間は分業してしまうと自分のスコープを明確にしようとするので、基本的には言われたことしかやらなくなってしまいます。そうではなくて「1チームだよね」と。
役割が違うだけで分業ではありません。「なぜこれをやるのか」という方向性をしっかり共有できると、それが仕様に細かく書かれていなくてもちゃんと自分たちで考えます。なんだったら、提示してきたよりももっと良いアイデアをエンジニアリングチームが打ち返すこともできるようになります。
したがって、WhatとHowも大事なのですが、何よりWhy。Whyの共有こそが、ドキュメント依存文化から脱却する1つの鍵だと私はとらえています。
ただ、これが大規模化してくるとそうも言っていられなくなります。結局、でかいものは分解しないと作れないからです。複数の小さなチームで大規模な製品・プロダクトに向き合っていくわけですから、分業するしかないのです。
おそらく、それ以外の有効な解は今のところ世の中には無いのだと思います。どのフレームワークでも、基本的にはプロダクトバックログを分解して、複数のチームでやっつけて、最後にそれをくっつけて出すわけです。先ほど紹介したLeSSだろうがSAFeだろうが、同じことを言っているのだと思います。したがって、分業せざるを得ません。
ただ分業すると、たとえ自分たちが扱っているものでも、分解されたものをあてがわれた人たちは最終形が見えにくくなってしまいます。自分たちの作っている物がすべてではなく、他の人たちが作っているものとくっついて最終的にどうなるのかが、かなり見えづらくなってしまいます。
それを結合してテストする人は全容がわかるのですが、その手前にいる人たちはけっこうわからなくなってしまいます。自分たちの限られたWhyはわかるが、全体のWhy、Whyの全容がわからず個別最適になってしまう。全体に対しての有効な提案のスピード感が下がり、停滞してしまう。アジリティと相反する状況が生まれてしまうと私は考えています。
したがって、自分たちのプロダクトが最終的にどう使われるのか、どう動くのかを、何かしらの仕掛けでちゃんと定期的に知る必要があります。アジャイルはプロダクトがどんどん進化していくので、1回こっきりではなく継続的に全容を知ることが大切です。各スクラムチームが知る機会を設ける。これが非常に重要な課題の1つなのではないかと私は考えます。
「ソフトウェアテストの生産性をいかに上げるか」「自分たちのプロダクトがどう動いているのか」の2つ。後者はテストチームだけ・QAチームだけではなく、全員が知ることが重要です。特に、分業された仕事を当てがわれているエンジニアの人たちがいかに知るか。これがアジリティを下げずに、むしろ加速させる（ための）キーとなります。
課題に対する3つのアプローチ
先ほどの2つの課題に対して、どのようなアプローチがあるかというと、たくさんある中で今日は3つに絞って持ってきました。
まずは前者の課題についてです。テストの生産性を上げる手がかりとしては、いかに自動テストをうまくやっていくかという話が1つ。一方で、自動テストがあるからには手動テストもあります。プロダクトが大規模化すればするほど、それは組み込み領域であったり他社のシステムであったりするため、テストの自動化は難しくなっていきます。
したがって、ある程度の手動テストが残ります。特に大規模になればなるほど、その割合は増えていくと私は考えています。なので、その手動テストも何かしらのかたちで生産性を上げないといけません。
2つ目の課題はプロダクトの価値です。みんなが自分たちのプロダクトの全容を知るためのうまいやり方があります。先にキーワードを言ってしまいますが、探索的テストという営みを、みんなで運用するのがいいと考えています。
アプローチ1 自動化ツールの活用
ここから先が最後のメインセクションとなります。自動テストをうまくやる、もしくは手動テストをうまくやる。今までとは違ったアプローチ、具体的には探索的テストに挑戦してみる。これらが、それぞれ具体的にどのようなものなのかについて話していきたいと思います。
1つ目は自動テストの話です。ここはやはり良いツールです。もともとコードベースで低レイヤーのテストの自動化ができた世界から、今は商用ツールが中心になっていますが、よりリッチで高いテストレベル、結合テスト・システムテスト・受け入れテストのレベルに耐え得るものが良いです。
ゴリゴリとコードを書くのではなく、ユーザーにとって直感的で使いやすいもの。そして、メンテナビリティ。運用保守しやすいもの。テストコード自体の運用保守、テスト資産の運用保守もサポートしているツールが今はどんどん出てきています。
（スライドを示し）そういったものを活用することが近道の1つだろうということで、具体的なアプローチ①として記載しています。先ほどの課題のところでは触れませんでしたが、これは生々しい現実問題であり、チームの規模が大きくなればなるほど、全員が「超できる人」というわけにはいかなくなっていきます。
少数精鋭という言葉があるように、小さなチームであれば腕っこきを集めることはできます。しかし、大きくなればなるほど、現実的にはある程度レベルがジュニアなメンバーも入れて、なんとかチームを組織しなければならなくなると思います。
そうなった時、特にテストを司っているジュニアな人がいきなりゴリゴリとテストコードを書けるかというと、やはりそうではないことが多いと思います。であるなら、コーディング技術を身につけることも必要ではありますが、もうちょっとポチポチと扱えるビジュアル的な製品を導入してもいいと思います。
自動テストの規模が大きくなればなるほど、当然、自動テストの分量も増えていきます。そして、その自動テストのメンテナンスに今度は時間がかかるようになって、場合によっては本末転倒な状況になりがちです。
スピードを早くするための自動テストがむしろ足を引っ張る。それはなかなかつらい状況だと思います。「プロダクトのコードがこう変わったからここを直せればいいよね」「なんなら自動で直し方の提案までしますよ」といった、AIに基づいたメンテナンスの支援もアリです。
自動テストメンテナンス支援をしてくれるようなツールが世の中には出てきているので、そういったものを活用することが、自動テストに関連する生産性向上の1つの有用な手段なのではないかと考えます。当社はこういったツールを作っているわけではないので、宣伝ではなく本当に有用だと思って紹介しています。
アプローチ2 テスト設計・テスト管理ツールの活用
次に手動テストについてです。先ほど言ったとおり、手動テストも依然残っています。特に、大規模になればなるほど残ります。そうなった場合、もうとにかく生産性を上げるしかありません。生産性を上げるためにツールの力を借りるのは有効です。極めて一般論ではありますが、ツールの力を借りてうまくやりましょうという話です。
その中の領域は2つあります。1つがテスト設計です。冒頭でプロダクト設計ではなくテスト設計という話をしました。テストのパターンをいちいち人間が勘と経験と度胸でやるのではありません。「仕様のモデルがこうだからこのパターンでやればいい」ような領域をエンジニアリングしているテスト設計技法が、世の中にはいろいろあるのです。
それをしっかり活用して、なんならそのツールを使って仕様モデルをちゃんと書いておけば、テストのパターンが半自動で出てくるようなツールとなります。
もしくはテスト管理です。自動テストは1日に何回もまわせる世界ですが、手動テストは今日何件、明日何件という世界です。件数を稼いでいても、結局バグだらけだったら意味がないので、バグや品質の状況を可視化することが非常に重要になってきます。
なので、テストの進捗状況や品質状況を可視化するテスト管理ツールをうまく扱うことがポイントです。そして、繰り返し発生する手動テストのテスト計画を爆速でやって、問題点にいち早く気づくことも、テストの生産性を上げる重要な要素になると思います。
アプローチ3 探索的テスト
先ほどキーワードを言ってしまいましたが、最後は探索的テストです。探索的テストは非常に高度なテスト技法といわれています。しっかりと計画を立てて行う、一般的なテストではありません。設計して、パターンを洗い出して、テスト実装して、データのパターンなどを準備して、最後にそれをテスト実行する。そういったものではないのです。
プロダクトをとにかく触ります。プロダクトをしっかり触って、「こう動くんだ。じゃあ、これをやったらバグるんじゃない？」と、自分のこれまでの知見をすべて動員して、テスト設計、テスト実行、テスト分析、をリアルタイムで頭の中でやっていきます。
ドキュメントを事前にしっかり書くのではなく、頭の中でリアルタイムでやっていくスタイルが、探索的テストです。
これは非常に高度な話ではありますが、この探索的テストをもう少しゆるくとらえて、「自分たちのプロダクトをとにかくちゃんと触ろう」と考えます。自分たちが開発する部分は分業されて、一部のところしか開発しないのですが。
2週間に1回、1ヶ月に1回でもいいから、全部がつながった状態でちゃんと触ってみて、「ここってこんなにもっさりするんだな」「ここはなんかちょっと使いにくいな」などという気づきをちゃんと得ていくことが非常に重要だと思います。分業されてスコープが限られた開発チームの敷居を取り払って、完成形のプロダクトをとにかく触る。ローンチ一歩手前のプロダクトを触る場を組み込んだ開発プロセスが非常に重要なのです。
これを探索的テストと呼んでしまうと、もしかしたらテスト業界の人には怒られてしまうかもしれません。でも、自分たちのプロダクトの価値を発見しようということです。テスト設計してリスクを低減するより、プロダクトの価値向上につながるテストもやってみてはいかがでしょうか。それが私からの提案です。
以上が、一般論として大規模アジャイルにおけるソフトウェアテストの生産性、もしくはアジリティを下げない、私が考える工夫の話でした。
ベリサーブが提供しているソリューション
最後に少しだけ時間をいただいて、ベリサーブという会社がどのようなソリューションを提供してるのか紹介させてください。
例えば、手動テストのテスト設計の効率化について。「仕様のモデルを作ったら、パーッとテストのパターンが半自動で出てくるといいよね」と話しました。実は、私たちの会社はまさにそれをサポートする「GIHOZ」というテスト技法設計支援ツール（を持っています）。
仕様のモデルをブラウザ上でポチポチと書くことで、一定の網羅基準に従ったパターンを抽出するものです。
ブラウザさえあれば使えるので、ソフトウェアをインストールする必要は一切ありません。
そしてテスト管理（です）。手動のテストの進捗状況やその時点における品質の状況、繰り返し発生するテストなどが挙げられます。「仕様のここが変わったから、テストケースのここを直さないといけないよね」などと言いながら、ファイルサーバーを漁ってExcelを探すことはもうやめましょうということです。世の中には、テスト管理ツールというジャンルがあるのです。
当社は「Quality Forward」というツールを出しています。しかし、どのツールでもいいと思います。当社のツール以外にも良い製品がいっぱいあるので、どれでもいいです。
当社の製品の良いところは、誰かが1件のテストを実行すれば、それがリアルタイムでレポートに出るところです。アジャイルにおいては、透明性・見える化が非常に重要だといわれています。まさに、テストの状況をリアルタイムで可視化する支援を行っています。
品質状況と件数の管理だけをやっていても仕方がありません。その中にバグが何件あるのかを可視化することも重要です。
あとは、今のソースコードの管理は非常にインテリジェントです。Git、それをラッピングしたGitHub、GitLabといった製品がいろいろあります。差分が一発でわかったり、バージョン管理が非常にインテリジェントにできたりしますが、テストケースも同じようにできたらいいと思うわけです。
Excelを見比べたり、Excelの後にバージョン1、バージョン2、バージョン3（新しい）などとファイル名を付けるのはもうやめましょうということです。ブラウザ上のスプレッドシートで、変更点を一発で可視化します。
失敗したテストだけを抽出して、次のテストの実行を簡単に作る。テストの資産をExcelで管理するのではなく、ツール上でさまざまな属性付けをして、テスト再実行とテスト再計画を加速させていくことは、当社のツールでも他社のツールでも実現できると思います。
最後。これはまだ世に出ていません。私自身、鋭意がんばっていますが、探索的テストです。“ソフトウェアテストのお触り会”と言ってもいいでしょう。
みんなで自分たちのプロダクトを触りましょう。リスク低減からプロダクト価値向上へと、考え方を変えていくのです。そして、誰かが気づいたことをちゃんとチームで共有できるようにしてあげます。
そんな探索スタイルのテストを支援するツールを、絶賛開発中です。
テストはだいたい成功か失敗かをマーキングするのですが、そこで気になったことをマーキングできるようにしてあげる工夫を施しています。
もしくは個人がやったテストで終わりにするのではなく、ちゃんとチームで最後に振り返る。例えば2週間に1回、1時間みんなでプロダクトを触り、その後の30分で振り返りをします。
「これは確かにバグだよね」「これはやっぱりいいんじゃない？」「これはちょっと保留だよね」などと、チームとしての見解をしっかり残せるようにしてあげます。そういった振り返りをサポートするなど、いろいろな工夫を盛り込んだ探索的テスト支援ツールも、今後提供できればと考えています。
ソフトウェアテストがアジャイル開発のボトルネックになってはいけない
最後はちょっと駆け足で宣伝じみた話をしました。以上で今日のセッションを終わります。「アジャイルって何なの？」「大規模アジャイルって何なの？」「どういった特徴があるの？」「ソフトウェアテストの課題とアプローチとは？」というテーマでみなさんにお話ししました。
アジャイル開発とは、ビジネスリスクを低減する開発スタイルだと。
そして、それが大規模化する流れは大きく2つあって、それは徐々に大きくなるパターンと最初から大きいパターンです。そして、それぞれに適したフレームワークもあるという話でした。
その中で、ソフトウェアテストはボトルネックになってはいけませんし、分業のせいで気づきが得られる機会が減ってもいけません。気づきを得る場がないといけない。場を設定しないといけない。
そういった話をしました。そして、それを支援する当社のツールも最後にちょっと紹介しました。
今日は宣伝の場ではないので、紹介した当社のツールでもし気になるものがあった人は、イベント管理ツールconpassを確認してください。そこに当社のテナントがあり、各種ツールの紹介やハンズオンのセミナーの企画もあるので、興味のある人はぜひチェックしてください。
最後に1個。これは本当にテストに関心のある人にしか響かないと思いますが、我々のツールラインナップとして、テストの分析があります。テストの中の超上流という非常にフワッとした領域をどうやってモデリングするのか。どうやって残していくのか。残すことによって共通認識を作ることをサポートするツールも絶賛検討中です。こういった領域に関心のある人は、当社にお声がけください。
最後はかなり駆け足になりましたが、以上で私の講演は終了します。
