ObjectSquare

[レポート]


ソフトウェア品質管理実践手法

はじめに

私はソフトウェア品質管理実践手法コースに出席してきました。

コースの内容は(株)東芝ソフトウェア技術センターの平山雅之さんによる「数値データを利用したソフトウェアの高品質化」と、電気通信大学講師の西康晴さんによる「ソフトウェアテストの体系と実践 〜ツボを押さえた品質向上〜」です。それぞれ約1時間半のセミナーでした。

双方のコースともソフトウェア高品質化のための手法を説明するものです。

私の部署では組込みシステムをターゲットにオブジェクト指向技術をやっているわけですが、最終的に目標とする所は組込みシステムソフトウェアの高品質化にありますので、このあたりも最新の動向をウォッチして、できればノウハウとして身に付けていこうという所です。


数値データを利用したソフトウェアの高品質化

講師:

(株) 東芝
ソフトウェア技術センター
経営変革エキスパート
平山 雅之 氏

平山さんは東芝のソフトウェア技術センターで経営変革エキスパートとしてソフトウェアの設計および高品質化などの支援業務を担当しておられます。昨年からは東海大学情報学部非常勤講師も兼務されている、ということでした。

内容:

セミナーでは東芝のプロジェクトでソフトウェアのメトリクス(数的指標)を計測して活用した経験をベースに、メトリクスをソフトウェアの高品質化に役立てるノウハウを説明されました。

英 Programming Research 社のQAC++ を使って計測したコードメトリクスなどの活用法を説明されていました。

QAC++ の代理店の東陽テクニカのホームページ(http://www.toyo.co.jp/ss/)

QAC++ では以下のようなメトリクスを計測することができます(以下は主要なもので、全部で44のメトリクスが計測できます)。

QAC++以外では、以下のようなメトリクス計測、活用例が説明されていました。

平山さんが最も強調されていたことは、

ということでした。

そのために以下のようなことをアドバイスされていました。

感想:

コンサルなどでプロジェクトを進めていて、ソフトウェアの可視化が難しいことを実感しています。
モデルのレベルならまだレビューもできるのですが、コードのレベルになるとレビューのコストが急激に大きくなります。

開発者としては、ツールにコードの品質を評価されるのは感情的にちょっと複雑な部分がありますが、例えば保守フェーズにあるソフトウェアのリファクタリングをする場合にコードメトリクスを取って、弱そうな部分からレビューしていく、というような使い方は費用対効果も良く、レビューする理由づけにもなるので良いと思います。

ただし、誰々が作った悪い、というのが出てきますので、不幸にして悪い値が出てしまった人を責めるのではなく、チームの皆で勉強しましょう、というような雰囲気でフォローしてあげることが重要だと思います。


ソフトウェアテストの体系と実践 〜ツボを押さえた品質向上〜

講師:

電気通信大学
電気通信学部
システム工学科 講師
西 康晴 氏

西さんはたぶん日本で一番有名なテスト技術者/研究者です。
ご存知の方も多いと思いますが、西さんはテスト技術者の情報交換のためにテスト技術者交流会 (http://blues.se.uec.ac.jp/swtest/) を立ち上げました。
テスト技術者交流会では、「基礎から学ぶソフトウェアテスト」や「ソフトウェアテスト293の鉄則」などを翻訳、出版し、ヒットさせています。
以前は日本語で簡単に読める実践的なテストの本はなかったのですが、この本のおかげで簡単にテストの技術やコツが勉強できるようになりました。

西さんは大学でソフトウェアテストを研究し、テストコンサルをやる会社でコンサルタントを経験して、この春から電通大学で自分の研究室を持って、講師として活動しています。ご本人は今回のセミナーでテストエバンジェリストを名乗っていましたが、まさにその肩書きがぴったりくる人です。

この他、組込みソフトウェアは日本が優位性を持ちえる分野と考えられており、組込みソフトウェア技術者管理者育成研究会 (http://www.sessame.jp/) で組込みソフトウェア技術者を育てる活動も行っておられます。

私も2年前に知り合いにならせてもらって、年が近いこともあり、時々行き来してお互いの情報を交換しています。

内容:

まず、テストの話に先立ち、以下のような話をされていました。

ソフトウェアテストの基本的な考えとしては以下のようなことを挙げられていました。

セミナーで覚えて帰って欲しいこととして、有効性の高いテストを行うためのキーワードを2つ挙げられていました。

  1. 網羅
    思いつきでテストするのではなく、網羅性のあるテストをする。
  2. 境界値
    最も不具合を検出する可能性が高いテストをする。

以下のような例題も出されました。
この例題はMyersの三角形と呼ばれる問題です。みなさんもテストケースを考えてみてください。解答は最後に書いておきますが、ぜひ自分で解いてみてください。「網羅」と「境界値」を考えるのがヒントになります。

以下のコンソールプログラムをテストします。テストケースを考えなさい。
  • このプログラムでは3つの整数が入力される。(プログラムでは3つの整数が必ず入力される仕様とする。)
  • 3つの値はそれぞれ三角形の辺の長さを表す。
  • プログラムでは三角形が不等辺三角形か、二等辺三角形か正三角形かのどれかを出力する。
  • プログラム実行例:
3辺の値を入力してください
a辺の長さ:2
b辺の長さ:2
c辺の長さ:3
三角形は二等辺三角形です。

3辺の値を入力してください

この他、興味深かったトピックとして、日本ではいまだに

という分類が一般的だが、欧米では

という分類が一般的になっている。

西さんはブラックボックステストだけでは限界があるので、

などが必要だと考えており、今後も研究していきたいということでした。

感想:

最近はXPブームおかげで、プログラマもユニットテストをやることがかなり一般的になってきました。
ユニットテストをより高レベルで行おうとすると、テストの技術が必要になってきます。プログラマもこの辺の技術を勉強することが必要だと思っています。
西さんも言っておられるように、次の大きなトピックとして

ということがあります。

例えば、小さい例では、フラグによる実装をせず、極力状態で設計する、というようなこともテストしやすい設計といえます。

このトピックもプログラマが積極的に追求すべき課題ではないでしょうか。
テストはプログラマにとっても大きなキーワードになってきていることを感じさせるセミナーでした。

Myersの三角形の解答:

<有効な三角形となるテストケース>

<有効な三角形とならないテストケース>

*テストの期待結果をテストケースに書いていたら+1点とする。

<コメント>

西さんによると平均的なプログラマは7点くらいだそうです。

整数は「自然数、自然数に対応する負数および0の総称」ですので、負数、0が入力されることも考慮しないといけません。
この問題ではプログラムで整数を受け付けていましたが、正の整数以外ははじくようにしておけば、テストを簡略化することができますね。
テストを考慮して仕様を設計しておく、といった話ですね。




© 2003 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP