肥大化し続けるソフトウェアをどうテストする？ アジャイル時代のソフトウェアテストに必要な考え方：海外企業に学ぶテスト自動化（終）

海外の先進的企業の事例を基にテスト自動化に使われる手法を解説する本連載。最終回は、アジャイル開発におけるテスト自動化において重要な考え方とは何かを解説する。

[高橋寿一，AGEST]

　これまでの連載でミューテーションテストとカオスエンジニアリングを紹介しました。先進企業においては「時間はお金で買うもの、特に品質担保の時間はなるべく少ない方がいい」「テストの時間がゼロになるならお金はいくらでもつぎ込みたい」というのが本音だと思います。GAFAM（Google、Amazon.com、Facebook、Apple、Microsoft）は十分な利益があるのでお金で時間を買って先行者利益を得たいはずだと筆者は考えています。Googleのあるテスト担当者は「私たちはマニュアルテストをしている時間がないから自動化するのだ」と言っていたそうです。これはコスト削減のためにテストを自動化するという多くの日本企業の姿勢とは異なります。

　アジャイル時代の今後のソフトウェアテストは、次の2つが重要であると考えています。

• 単体テストの比重に重きを置き、その結果から品質を確率統計的に判断する
• 自動化されたランダムテストを多用する、その結果から品質を確率統計的に判断する

　下図はGoogleが単体テストにテストの重きをおくという指針を示したものです。連載第1回で述べたように、Googleでは単体テストベースでミューテーションテストを行っています。

　しかし、多くの日本の企業では下図のように、自動化すべきでないUIから一生懸命に自動化しているのではないでしょうか。

　いまだにUIの動作を記録して再生させる自動化ツールを喜んで使っている日本のソフトウェア組織がたくさんあります。言い方は酷かもしれませんが、もう少し戦略的にテストというものに取り組んでみませんか。ソフトウェアは肥大化しています。無限の空間をどう効率的にテストするかというのは非常に重要な考え方です。UIをただなぞるだけの自動化では製品全体の0.001％しかテストできていないかもしれません。

　上記のようなアジャイル開発ではデイリースクラムの中へ定量的に毎日計測できる品質メトリクスを入れなければ意味がありません。そういう意味ではミューテーションテストもカオスエンジニアリングも定量的な品質指標を毎日出すことができます。

ランダムはでたらめではない

　これまでの連載の中で「膨大×膨大＝無限大」を語ってきました。そして無限大な対象に対して、ランダムが重要であるとも述べました。しかし、著名なテスト研究者であったBoris Beizer氏が次のような発言をしています。「ランダムテストでバグが見つかるのは、テストの計画の不十分からくるものである。もし計画が十分戦略的であればランダムテストは必要ない」

　この言葉がウオーターフォール時代の緻密で計画的なテストを支えてきたのもまた事実です。

　ウオーターフォール時代、そしてソフトウェアがクライアントもしくはサーバという閉じた形で独立的であれば、上記の理論は正しいかもしれません。しかし、現代のソフトウェアはサーバ、クラウド、クライアント、オープンソースのコード……とソフトウェアが複雑極まりない構成になっています。綿密に計画されたテストや、スキルのあるテスト設計者によるテストケース作成には意味がなくなりつつあります。

　そうなるとバグがどこにあるか分からないことを前提としたランダムテストが実は有用なことが分かります。例えば、以下のような入力空間があるとします。そしてそのどこかに6個のバグが仕込んであります。ランダムに3つのテストケースを入力して、バグが出る確率はどのくらいでしょうか？

　下記のような計算式で発見確率を計算できます。

　ランダムだと端っこばっかりテストするケースもあって少し怖いので、テスト空間を3つに等分する工夫をし、各空間に1つずつ入力をします。そうすれば満遍なくテストができるように思います。

　そうするとまた下記のような計算式でバグ発見確率を計算できます。

　2つの計算式の見た目は難しいですが、読者の方は実務では理解する必要はありません。何を言いたいかというと、人間の多少の工夫や想像で入力をバグの出やすいように考えようが、またランダムで入れようがバグの発見確率はあまり変わらないということです。従って創造的なテストケースを作る努力より、バリバリ自動でソースを改変したり（ミューテーションテスト）、プロセスを止めたり、ネットワークを遅くしたり（カオスモンキー）する方がテストとしては効率的なこともあります。考察の足りないシナリオテストを行うより、自動化されたランダムテストを実施する方がバグを見つける可能性が高いと筆者は考えています。

　さらに良いことに、計画されたランダムテストは、出荷後の市場バグの発生確率を計算できます。長らくソフトウェアテストは恣意（しい）的なテストケースに頼っていたため、テスト実行後の市場バグの発生確率は計算できませんでした。皆さんも上司から、「テストやったんだから、市場バグの発生の可能性を定量的に教えてくれない？」と言われたことはありませんか？　もちろん答えに窮しますよね。

　さまざまな機械、電機などの品質工学は統計的な指標を計算することが可能でした。しかし、ソフトウェアの品質工学だけは統計的な指標が使えません。例えば、MTTF（平均故障時間）はどこにでも使われている指標ですが、ソフトウェアへの適用事例はわずかしかありません。しかしランダムテストという方法論を使うことによって、MTBF（ソフトウェアの場合平均故障間隔）を求めることが可能です。

　皆さんも上記のようなグラフを書いたことがあるかもしれません。「開発期間が進むにつれ総バグ数が増えてないから出荷しよう」と言ったことがある方もいるかと思います。しかし、このグラフは恣意（しい）的なテストケースでのバグ発見数なので、定量的に品質を測れません。ここでランダムテストを行えば、少し難しいのですが下記のような確率統計の式を使うことでMTBFを計算できます。

　「このソフトウェアのMTBFは48時間だから、平均的ユーザーはバッテリーが切れるまで操作しても致命的な問題に遭遇する確率はn％」という計算ができます。これで定量的品質の数値化が可能になります。

まとめ

　アジャイル開発の手法は現代のソフトウェア開発の最適解といえます。品質保証という一点を除いては、大きなデメリットは差し当たり見つかりません。

　長い時間をかけてソフトウェアテスト手法は進化してきました。しかし、それはウオーターフォール前提であって、アジャイルにうまく適応できる部分はかなり少ないのではないかと筆者は感じています。それでもミューテーションテストのようにある部分は使えますし、カオスエンジニアリングのようにまったく新しいテストの世界を創出するものでもあるでしょう。

　ランダムのミューテーションテスト、ランダムの自動テストと、その結果を利用した定量的品質指標の導出はウオーターフォール開発が主流の時代には実現が難しかった、新しいテスト観を創出します。

　現在の日本ではテスト担当者のスキルセットの多くは既存のテスト手法に関するものだけということもあるのかもしれません。今後のテスト担当者のスキルには、コーディングや確率統計的スキルがもっともっと必要になってくるかもしれません。多くの米国企業では、テスト担当者に大学でコンピュータサイエンス分野を専攻していたか、それと同等のスキルを要求しています。今後は日本のテスト担当者も情報系の大学で得られるレベルの知識が必須になってくるのではないでしょうか。

著者紹介

高橋 寿一

情報工学博士。1964年東京生まれ。フロリダ工科大学大学院にてCem Kaner博士、James Whittaker博士にソフトウェアテストの指導を受けた後、広島市立大学にてソフトウェアテスト研究により博士号取得。米国Microsoft、SAP Labs、ソニーを経て、AGEST 執行役員 CTSO、AGEST Testing Lab.所長およびAGEST Academy学長を現職として兼任。情報処理学会及びIEEE会員

参考文献

• Duran,J.and Ntafos,S.“An Evaluation of Random Testing”IEEE Transactions on Software Engineering,vol.10,No.4.,pp.438-444,Jul.1984
• Hamlet, D., ”Partition Testing Does Not Inspire Confidence” IEEE Transactions on Software Engineering,vol. 16,No. 12,pp. 1402-1411,Dec.1990
• Software Testing Techniques,Boris Beizer,Van Nostrand Reinhold,1990