事例

オージス総研のソフトウェア品質管理ソリューション

連載第3回
金融業界のシステムご担当者様

さらなる品質の高度化にむけて -テスト工程そのものの改善-

注:文中の製品体系は執筆当時のものです。最新情報は弊社までお問い合わせください。

連載第1、2回で金融システムの開発現場へのCoverity導入を支援したプロジェクトマネジャーの声をお伝えしました。「実際のソースコードの品質を可視化」し、さらに「コーディング工程で生じたバグはコーディング工程で取りきる」こと、そしてその結果としてそうしたバグを「テスト工程に流さない」ことのメリット、および、そこへ向かうためにCoverityがいかに有効かが見えてきました。

連載を締めくくる第3回では、Coverityの関連ツールによってテスト工程そのものをどのように改善できるかその展望を示したいと思います。コーディング工程とテスト工程は、開発スケジュールの線表上は一方向に進んでいくように描かれます。しかし、実際の現場では2つの工程間、あるいはコーディングチームとテストチームの間を行ったり来たりしている、ということがむしろ普通でしょう。テストで見つかった問題(例えば仕様と実装が一致していない、設計時に考慮されていなかった例外条件に対応しておらずエラーになる、性能要件を満たしていない、など)を修正するために設計・コーディング工程まで手戻りし、修正後に回帰テストを行う、ということは不可避的に発生します。発生するからこそテスト工程があるのですし、手戻り工数は計画段階でもある程度見込んではいるはずです。問題は、見込んだその「ある程度」の範囲内に手戻り工数を収めるためのコントロールが難しいことです。

手戻り工数を想定範囲内に収めるために何ができるでしょうか?ここで申し上げたいポイントは、修正と回帰テストを行う際に、「どの範囲をテストすべきか」そして「その範囲を過不足なくテストするためのテストケースはどれか」を適切に見極めることで、回帰テストを合理化できるということです。これはしかし、まさに「言うは易し」です。

img_coverity_005t (1).jpg


機能テストに関しては、「機能Aに手を入れたのだから、これに関する機能テストを再実行すればよい」というように判断は比較的容易です。では、コーディングレベルでのある個所の修正の影響が、思わぬ範囲に及ぶ可能性についてはどうでしょうか。これを把握・コントロールしないことには、1つの問題を修正するとそれが新たなバグを作り込む、いわゆる「デグレ※1」と呼ばれる現象に現場は悩まされることになります。

デグレを抑えながら合理的に回帰テストを進めるためにはツールによる支援が必要です。特に、静的解析の手法と動的解析の手法の組み合わせが有効です。これを行うのがCoverityの関連製品であるTest Advisorです。Test Advisorは2つのエディションで構成されます。Test Advisor - Development(以降TA-Dと表記)とTest Advisor - QA(以降TA-QAと表記です。

TA-Dは、ソフトウェアに対する修正の影響度をスコアリングし、バグの発生リスクが高いコード行を色分けして可視化します。バグ発生リスクの高いところから優先的にホワイトボックステストを実施することで、テストの実効性(バグを見つける効率)を高めます。これは純粋に静的解析の手法で、コーディングチーム向けです。

TA-QAは、いわば「テストのX線検査」とでも言うべき働きによりテストチームを支援します。TA-QAは2段階の解析を行います。第1段階はいわば準備段階で、既にあるテストを通しで実行しながら、それぞれのテストケースがテスト対象のソフトウェアのどの部分(クラス、メソッド)を通しているのかを動的解析によってキャプチャリングします。(なお、テストの実行は、人間による画面の打鍵テストでも、Selenium※2のようなWebアプリテスト自動化ツールによるものでも構いません。)第2段階は、テスト対象のソフトウェアが修正された際に、修正前のバージョンと修正後のバージョンの差異(つまり修正個所)を自動で静的解析し、その上で、過不足なく修正個所をテストするために再実施すべきテストケースを、第1段階でキャプチャリングしたテストケースの中から特定します。もしテストケースに不足があればどのようなテストケースが不足しているかも特定します。

img_coverity_006tl.gif

TA-QAを用いない場合、人間が修正の範囲と既存のテストの関係を推測しますが範囲の絞り込みは困難で、結果として無駄に多くのテストケースを再実施したり、本当は不足しているテストケースがあるのに気付かずデグレを見逃してしまったり、ということが起こりがちです。適切に回帰テストを設計できるテスト技術者は容易に育成できないため、TA-QAによる支援が有効です。

まとめると、コーディング工程の品質改善に取り組んだ後は、いよいよテスト工程そのものの改善へと進むことができます。そしてTest Advisorの2つのエディションが、そのお手伝いをします。実際、Test Advisorによって繰り返し行われるテストの効率を3倍以上に高めた事例もございます。ソフトウェア開発工程のさらなる改善にむけて、テスト工程の効率化についてご検討されてみませんか。

※1:デグレ
こここでは、あるバグを修正したことにより、これまで使えた機能が使えなくなる、バグや不具合が増えるなど、かえって品質が下がってしまうことを意味する。

※2:Selenium
http://docs.seleniumhq.org/

関連サービス