~ソフトウェア品質の向上とそこに関わるすべての方へ~ Software Quality Profession

1.品質

しぶといバグを効率的に絞り出そう!

株式会社 日立製作所
ソフトウェア事業部生産技術部主管技師 居駒 幹夫

 一昔前に比べてソフトウェアの品質管理の考え方は広く普及しました。品質管理のスキルが高くなった組織では、出荷早々の障害頻発といったレベルの問題は少なくなります。しかし、そうなると目立ってくるのが品質管理の網をくぐり抜けた「しぶといバグ」です。出荷してから長い期間を経てポツポツそういうバグが現れてくるのが問題になっている組織も多いのではないでしょうか。

バグの寿命
バグの寿命

 上のグラフを見てください。ある(成熟度の高い)ソフトウェア開発組織でのバグの寿命グラフです。横軸は、製品を出荷してからの期間。縦軸は単位期間で発生した障害数です。横軸のスケールは明示できないのですが、週や月の単位ではなく、年の単位です。確かに、一番事故が発生しやすいのは出荷の直後なのですが、すぐに収束せず、10年、20年たってから発現するバグもあります。このグラフで注目してほしいのは、単に出荷してから長い期間を経て事故が発生するということだけではなく、指数分布、正規分布といった統計分布よりもずっと分散が大きいことです。統計的にはもうバグは滅多に出ないはずなのに、現実には障害が出てくる危険性が大いにあるということ、すなわちバグの寿命は結構長い。今風の言い方をすると、ロングテール、それもかなり太い尻尾を持っているのです。

 この問題の解決のためには、多角的なアプローチが必要でしょう。オーソドックスな考えの方であれば、「そもそも、そのようなバグを作り込まないようにしろ」、さらに、「開発プロセスの改善により、より早い工程でバグを摘出することが大切だ」と言うでしょう。筆者は、これらの施策に加え、「しぶといバグ」の性質を見極め、こういうバグを狙って絞り出すようなテスト技術やテストツールも普及させたいと思っています。「しぶといバグってなんでしぶといのだろう」、「これまでのテスト方法では何故摘出が難しかったのだろう」、「こうすれば、こういうバグだって絞り出せる!」と考えてみることも十分意味があるということです。

 私の経験からいうと、しぶといバグのしぶとい理由ベスト4は下記です。

  • ユーザの指定するパラメタの特別な組み合わせでないと発現しない
  • 動作環境(メモリ内容等々)によってたまたま発現する
  • 実行される順番やタイミングでたまたま発現する
  • 同値だと思っていたデータ範囲に思わぬ落とし穴があった

 こういうしぶといバグを、ソフトウェアをギュッと締め上げて絞り出すような技術と言ったら何でしょう。私は、テスト自動化による加速試験だと思います。

 日本のテスト業界では、テストの自動化とは、テストにかける労力を少なくする技術だと思われている方が多いようです。しかし、品質保証の立場からいうと、テストの自動化とは断じて「テストの十分度を高める技術」でなければなりません。どんなに売れているソフトウェアでもお客様の数は有限ですし、実行される回数も有限です。これをテスト自動化で先回りして、実運用での5年、10年を、開発環境での1日、2日に加速することが、しぶといバグ摘出に有効な技術になるはずだと思うのです。

 本コラムを読んでいる多くの方は、「話は分かったけど、現実的にそんなツール可能なの?」と思われているでしょう。実は、弊社内のテスト支援ツールRandomized-Cを強化して、無償公開します。このツール、テスト対象のソフトウェアをさまざまな環境、さまざまな入力データ、さまざまな実行順序、さまざまなタイミングで動作させ、その結果の確認を支援します。さらには、テスト対象プログラムの外部仕様(の一部)を指定することにより、その仕様の範囲で自動的に実行順序や、入力するパラメタを変えながらテストを続けます。

 では、どこまでテストするのか。これまでの同種の考えだと、「パラメタ数が多いので、All-Pairs法で強度2まで」とか、「ユースケースでの典型的な操作を数回」とかいったテストの間引き技法があります。このツールの場合、制限の対象は時間とテストのカバレージです。許された時間がある限り、単純なテストから、複雑なテストまでを繰り返し実行します。All-Pairs法の場合、強度1から始まって強度2,3, …と時間のある限り全組み合わせを目指してテストを続けます。時間切れになったときに、どの強度までテストが出来たかです。

Radndomized-Cのパラメタのイメージ
Radndomized-Cのパラメタのイメージ

 上図にRandomized-Cのパラメタのイメージを書いてみました。このツール、現状はUNIX系のOSで動作するC言語で書かれたソフトウェアを対象にしていますが、今後、適用対象範囲を広げていく予定です。

 こんなツールが欲しかったと思われた方、ためしに使ってみたい方、もう少し詳しい話しを聞いてみたい方、いらっしゃいましたら遠慮なく下記の連絡先にご一報下さい。

プロフィール
居駒 幹夫(いこま みきお) mailto:mikio.ikoma.yh@hitachi.com
株式会社 日立製作所
ソフトウェア事業部生産技術部主管技師
入社以来大規模ソフトウェアの品質保証、生産技術、プロセス改善に従事。プロセスと技術のバランスのとれたソフトウェア開発方法を確立、普及したいと長年思い続けています。
本件に関する連絡はメールでお願いします。
ソフトウェア品質のホンネ
SQuBOKソフトウェア品質体系ガイド
セミナー
SQiPセミナー
SQiPセミナー開催レポート
研究会
ソフトウェア品質管理研究会
シンポジウム
ソフトウェア品質シンポジウム
資格試験
ソフトウェア品質技術者資格試験
JSTQB 認定テスト技術者資格
国際会議
世界ソフトウェア品質会議
ASQN
ニュース
SQiPニュース
webマガジン「QualityOne
コミュニティ
ソフトウェア品質確証部長の会(東京)
ソフトウェア品質保証責任者の会(大阪)
SQiPコミュニティ
SQiP SIG
SQiPアーカイブ(研究成果や実践事例集
SQiPライブラリ
ソフトウェア品質管理の宝箱
調査・研究
ソフトウェア品質実態調査
調査・研究
 SQuBOK®ガイド