ソフトウェアの品質向上のためにテストを実施し、バグを見つけ、修正する。開発に携わる方なら皆知っていることですが、それでも出荷後にバグが見つかりますし、不具合やトラブルは絶えません。この連載では、テスト界の第一人者、高橋寿一さんに実践的、かつ効率的な開発者テストに関して説明いただきます。
こんな方におすすめ
・上流工程でのテストをしたいけれど、忙しくてそれどころではない
・用意されたテストを一応しているが、具体的なテスト手法はよく知らない（一から設計してコードを書ける自信はない）
・AIや機械学習、アジャイル開発などにおける最新のテストの考え方を知りたい
情報工学博士。1964 年東京生まれ。フロリダ工科大学大学院にてCem Kaner 博士（探索的テスト手法考案者）、James Whittaker 博士（『How Google Tests Software』著者）にソフトウェア品質の指導を受けたあと、広島市立大学にてソフトウェア品質研究により博士号取得。Microsoft シアトル本社・SAP ジャパンでソフトウェアテスト業務に従事、ソニー（株）ソフトウェア品質担当部長を経て、株式会社AGEST 執行役員。
バグとテストの必要性を振り返ってみる
せっかくなので少し本質的な議論をこの連載でしてみましょう。
Q. なぜテストは必要なのでしょうか？
A. なぜならバグが出るからです。
どのくらいバグが出るかと言うと…たくさんです！
なんと専門家らしからぬ意見！とお怒りの言葉がでると思いますが、実際のところ、ソフトウェア開発コストに占める品質保証にかかる費用はだいたい半分になります。この種の文献はたくさんあるのですが、どの文献を見ても40-60%です。
見てわかる通り、テストの費用は膨大です。バグもたくさん見つかります。ここではまず、どうやって論理的かつ効率的にテストするかの話をしましょう。どういうコンセプトでテストを設計するかについてです。
私は昔、ソフトウェアテストの研究で有名なフロリダ工科大学の大学院で、James Whittaker教授に学びました。『テストから見えてくる グーグルのソフトウェア開発』の著者といえば、ご存じの方もいるでしょう。
Jamesは最初の授業で、まずバグについて教えました。学生たちに20ドル札を振りかざして、来週までにMicrosoftのPowerPoint（もちろん製品版）のバグを見つけてくるように！一番素晴らしいバグを見つけた人には20ドルをあげる！と。今ならコンプライアンス違反で、教授会にかけられてこっぴどく怒られそうですが。
テストというのは、日本では品質保証とも言われますが、最も大切なことはバグを見つけることです。たぶん工学において唯一変な学問かもしれませんね。機械工学や電気・電子工学などは品質を定量的に計測し市場での不良予測がある程度可能です。けれどソフトウェアは
みたいな心意気！で語られることも。もしその前提に立つのならば、2つの知識が必要です。1つはどこにバグがあるか見つけること。そしてその場所にどうテスト手法を適用するかを知ることです。Jamesは授業で続けて以下のような図をホワイトボードに書きました。
ソフトウェアは4つのことしかしない、そのため4つの動作をちゃんとテストすればバグは見つかるという考え方です。上記の考え方は、現代のアジャイル開発におけるテストでも、AIソフトウェアに対するテストでも通用します。ただJamesが言ったのは20年前なので、それは現代では以下のように修正する必要があると考えます。
上図の通り、データの一貫性もしくは整合性というものが現代のソフトウェアでは重要になってきます。
データというのはデータベース・サーバーに出し入れするだけのものではありません。たとえば膨大なpre-condition（事前条件）というものがあると、ソフトウェアの振る舞いに依存し、いわゆるバグが生まれやすくなります。普通の状態ならソフトウェアはうまく動くけれど、ちょっとだけ設定の初期値を変えたら動かなくなった、なんてことはありませんか。事前条件がたくさんあるゆえに起こってしまう例です。身近なものだと、皆さんのスマホの設定は、どんどん設定項目が増え複雑になってきているのもその一つです。
条件の複雑さでいうと、最近増えてきたAIソフトウェアも挙げられます。AIソフトウェアの場合、機械学習における内部の処理が複雑で、「計算」（下図でいうニューラルネットワーク）過程そのもののテストが重要となってきています。
少し乱暴な言い方ですが、いままでのソフトウェアはたいてい４つの処理のうち、入力だけちゃんと扱っていればなんとなく品質保証ができたかもしれません。ただ、最近、特にAIや機械学習においては膨大な学習データ等があるため、データの一貫性テストが非常に重要になってきています。
今後のソフトウェアテストは、入力処理、出力処理、計算、そしてデータ一貫性の４つの処理の全部をバランスよく行うのが重要になってきます。
バグは全て見つけるべきなのか
バグの数は無限か有限か、という議論があります。
昔は上記のようなグラフを示して、「バグが出るところは以前バグが出たところ。叩けば叩くだけバグが出る！」みたいなことを言って弱い部分をバンバン叩いてバグを出していた時代もありました。
しかし現代のソフトウェアは肥大化しすぎて、弱いところだらけ。すべてのバグを見つけることは困難です。そのためバグを全部探すというより、ユーザーにとって使いやすい・長く使えるソフトウェアはどういうものかを想定し、ソフトウェア品質を担保するというふうに方針を変えたほうがいいかもしれないと考えます。
例えば、最近よくニュースになる銀行のシステム不具合は、ある部分が止まると、システム全体の系が止まってしまうため、大きな問題となってしまいます（もちろん、大規模のソフトウェアなら何十何百万のテストケースを作っているでしょうが、ただテストケースを積み重ねても結局ユーザーが使えなくなるなら意味はないですよね）。
これに対しNetflixは、ある部分が止まっても、全体の系が止まらないソフトウェア作りをしています。カオスエンジニアリングという手法を用いて、ランダムにさまざまなマイクロサービスを止めたり、遅くしたりしてシステムの堅牢性を見ているのです。現代のテストの見本であるといっても過言ではありません。
バグを見つける作業は必要ですが、まずはマイクロサービスレベルとも言える部分的な品質を担保し、それからはシステムの系として品質を担保するのがいいのではないかと筆者は思っています。
そうするとバグの数を観察して、1日あたりや1週間あたりのバグ発見数が減ってきたらか出荷しようという概念は当然なくなってきます。特にアジャイル開発ではそんなことしても意味はありません。アジャイル時代のテスト開発についてはこの連載でいずれ触れていきます。
これからの品質保証で求められること
ここまで読まれた方は、矛盾に気づくかもしれません。この記事の前半では「バグを見つけろ」と言って、後半では「バグを多量に見つけるな」という記述をしているように見えるからです。はい、矛盾しています。
従来のウォーターフォール時代の品質保証活動はそこまで矛盾が生じることはありませんでした。しかしアジャイル時代はまだ始まったばかりです。この矛盾をいかに各製品において適宜解決していくのかが、これからのアジャイル時代の品質保証と言えます。ある意味、アジャイル憲章にある「計画に従うより変化への対応」が重要かもしれません。
「バグは常に見つける気持ちで、でも全部見つけるのは無理だから工夫しなきゃ！」が実は筆者の本音だったりもします。この連載では皆さんにテストについての理解を深めてもらうと同時に、このあたりの工夫についてもお話できたらと思っています。次回もお楽しみに。
