［レポート］
私はソフトウェア品質管理実践手法コースに出席してきました。
コースの内容は(株)東芝ソフトウェア技術センターの平山雅之さんによる「数値データを利用したソフトウェアの高品質化」と、電気通信大学講師の西康晴さんによる「ソフトウェアテストの体系と実践 〜ツボを押さえた品質向上〜」です。それぞれ約１時間半のセミナーでした。
双方のコースともソフトウェア高品質化のための手法を説明するものです。
私の部署では組込みシステムをターゲットにオブジェクト指向技術をやっているわけですが、最終的に目標とする所は組込みシステムソフトウェアの高品質化にありますので、このあたりも最新の動向をウォッチして、できればノウハウとして身に付けていこうという所です。
(株) 東芝
ソフトウェア技術センター
経営変革エキスパート
平山 雅之 氏平山さんは東芝のソフトウェア技術センターで経営変革エキスパートとしてソフトウェアの設計および高品質化などの支援業務を担当しておられます。昨年からは東海大学情報学部非常勤講師も兼務されている、ということでした。
セミナーでは東芝のプロジェクトでソフトウェアのメトリクス（数的指標）を計測して活用した経験をベースに、メトリクスをソフトウェアの高品質化に役立てるノウハウを説明されました。
英 Programming Research 社のQAC++ を使って計測したコードメトリクスなどの活用法を説明されていました。
QAC++ の代理店の東陽テクニカのホームページ(https://www.toyo.co.jp/ss/)
QAC++ では以下のようなメトリクスを計測することができます(以下は主要なもので、全部で44のメトリクスが計測できます)。
- クラスのメソッド数
- メソッドの行数(クラス当たりの平均も計測可能)
- クラスの凝集度
ベースクラス以外の他のクラスのメソッドをどのくらい呼び出しているか- メソッドのロジックの分岐の複雑さ（経路複雑度、クラス当たりの平均も計測可能）
- メソッドにおける論理構造のネスティングの深さ（クラス当たりの平均も計測可能）
- クラスの派生の深さ
- クラスの不具合の出やすさの総合判定
QAC++以外では、以下のようなメトリクス計測、活用例が説明されていました。
- 限られた時間内で重大な不具合を検出するために、利用頻度、機能の複雑さ、不具合の影響度の重みづけをして、選択的にテストを行い、有効であった。
- リスク抽出をし、重みづけを行い、プロジェクトの持つリスクにどのような傾向があるかを分析した。
意思決定のリスクが多かった。- リスク一覧でピックアップしたリスクを担当者に割り振って、リスクが何日で解決されているか（リスク滞留期間）を計測した。プロジェクトマネージャの所での滞留が最も多かった。
平山さんが最も強調されていたことは、
- メトリクスを計測しただけではだめ
- メトリクスを活用してプロダクトとプロセスの改善をせよ
ということでした。
そのために以下のようなことをアドバイスされていました。
- 計測する前に仮説を立てて、計測するメトリクスを選びなさい。
- 計測にコストがかかるメトリクスは計測が続かないので、計測にコストがかからないメトリクスを計測しなさい。（例えばツールで簡単に計測できればコストがかからない。）
- 悪い計測値が必然性があって出る場合があるので、その場合は無理に計測値を下げようとせず、悪い設計や実装によって悪い値が出ている部分に対して対策を行うようにしなさい。
コンサルなどでプロジェクトを進めていて、ソフトウェアの可視化が難しいことを実感しています。
モデルのレベルならまだレビューもできるのですが、コードのレベルになるとレビューのコストが急激に大きくなります。開発者としては、ツールにコードの品質を評価されるのは感情的にちょっと複雑な部分がありますが、例えば保守フェーズにあるソフトウェアのリファクタリングをする場合にコードメトリクスを取って、弱そうな部分からレビューしていく、というような使い方は費用対効果も良く、レビューする理由づけにもなるので良いと思います。
ただし、誰々が作った悪い、というのが出てきますので、不幸にして悪い値が出てしまった人を責めるのではなく、チームの皆で勉強しましょう、というような雰囲気でフォローしてあげることが重要だと思います。
電気通信大学
電気通信学部
システム工学科 講師
西 康晴 氏西さんはたぶん日本で一番有名なテスト技術者／研究者です。
ご存知の方も多いと思いますが、西さんはテスト技術者の情報交換のためにテスト技術者交流会 (https://blues.se.uec.ac.jp/swtest/) を立ち上げました。
テスト技術者交流会では、「基礎から学ぶソフトウェアテスト」や「ソフトウェアテスト293の鉄則」などを翻訳、出版し、ヒットさせています。
以前は日本語で簡単に読める実践的なテストの本はなかったのですが、この本のおかげで簡単にテストの技術やコツが勉強できるようになりました。西さんは大学でソフトウェアテストを研究し、テストコンサルをやる会社でコンサルタントを経験して、この春から電通大学で自分の研究室を持って、講師として活動しています。ご本人は今回のセミナーでテストエバンジェリストを名乗っていましたが、まさにその肩書きがぴったりくる人です。
この他、組込みソフトウェアは日本が優位性を持ちえる分野と考えられており、組込みソフトウェア技術者管理者育成研究会 (https://www.sessame.jp/) で組込みソフトウェア技術者を育てる活動も行っておられます。
私も２年前に知り合いにならせてもらって、年が近いこともあり、時々行き来してお互いの情報を交換しています。
まず、テストの話に先立ち、以下のような話をされていました。
- ビジネス上、魅力あるソフトウェアを開発することが重要
- 魅力あるソフトウェアとは「魅力ある機能」と「高い信頼感」を持ったソフトウェア
- ソフトウェア技術者や管理者は魅力あるソフトウェアを作ることを目標にすべき
- テストをしっかりやることで、ソフトウェアの信頼性を向上させ、高い信頼感を獲得する。
ソフトウェアテストの基本的な考えとしては以下のようなことを挙げられていました。
- 全てのテストをやることは不可能なので、有効性の高い(不具合を見つける可能性が高い)テストからやっていく
- ソフトウェアテスト技術は有効性の高いテストを決めるための技術
セミナーで覚えて帰って欲しいこととして、有効性の高いテストを行うためのキーワードを２つ挙げられていました。
- 網羅
思いつきでテストするのではなく、網羅性のあるテストをする。- 境界値
最も不具合を検出する可能性が高いテストをする。以下のような例題も出されました。
この例題はMyersの三角形と呼ばれる問題です。みなさんもテストケースを考えてみてください。解答は最後に書いておきますが、ぜひ自分で解いてみてください。「網羅」と「境界値」を考えるのがヒントになります。
以下のコンソールプログラムをテストします。テストケースを考えなさい。
- このプログラムでは３つの整数が入力される。(プログラムでは３つの整数が必ず入力される仕様とする。)
- ３つの値はそれぞれ三角形の辺の長さを表す。
- プログラムでは三角形が不等辺三角形か、二等辺三角形か正三角形かのどれかを出力する。
- プログラム実行例：
3辺の値を入力してください
a辺の長さ：2
b辺の長さ：2
c辺の長さ：3
三角形は二等辺三角形です。
3辺の値を入力してください
この他、興味深かったトピックとして、日本ではいまだに
- ホワイトボックステスト
- ブラックボックステスト
という分類が一般的だが、欧米では
- ユーザ指向テスト
- 不具合指向テスト
- 仕様指向テスト
- 設計指向テスト
という分類が一般的になっている。
西さんはブラックボックステストだけでは限界があるので、
- マクロな設計情報（アーキテクチャ設計や状態設計など）を元にしたテスト設計
- テストを考慮した設計
などが必要だと考えており、今後も研究していきたいということでした。
最近はXPブームおかげで、プログラマもユニットテストをやることがかなり一般的になってきました。
ユニットテストをより高レベルで行おうとすると、テストの技術が必要になってきます。プログラマもこの辺の技術を勉強することが必要だと思っています。
西さんも言っておられるように、次の大きなトピックとして
- テストも見越した設計をする
ということがあります。
例えば、小さい例では、フラグによる実装をせず、極力状態で設計する、というようなこともテストしやすい設計といえます。
このトピックもプログラマが積極的に追求すべき課題ではないでしょうか。
テストはプログラマにとっても大きなキーワードになってきていることを感じさせるセミナーでした。
＜有効な三角形となるテストケース＞
- 有効な不等辺三角形となる値セット
- 有効な正三角形となる値セット
- 有効な二等辺三角形となる値セットで a = b の場合
- 有効な二等辺三角形となる値セットで b = c の場合
- 有効な二等辺三角形となる値セットで a = c の場合
＜有効な三角形とならないテストケース＞
- 長さが０の辺がある場合
- 長さが負の値の辺がある場合
- 整数でない辺がある場合
- ３辺が０(無効な値で３辺が等しい場合を代表している)
- ２辺の和がもう１辺と等しくなる値セットで a = b + c の場合
- ２辺の和がもう１辺と等しくなる値セットで b = a + c の場合
- ２辺の和がもう１辺と等しくなる値セットで c = a + b の場合
- ２辺の和がもう１辺より小さくなる値セットで a > b + c の場合
- ２辺の和がもう１辺より小さくなる値セットで b > a + c の場合
- ２辺の和がもう１辺より小さくなる値セットで c > a + b の場合
＊テストの期待結果をテストケースに書いていたら＋１点とする。
＜コメント＞
西さんによると平均的なプログラマは７点くらいだそうです。
整数は「自然数、自然数に対応する負数および0の総称」ですので、負数、0が入力されることも考慮しないといけません。
この問題ではプログラムで整数を受け付けていましたが、正の整数以外ははじくようにしておけば、テストを簡略化することができますね。
テストを考慮して仕様を設計しておく、といった話ですね。
| © 2003 OGIS-RI Co., Ltd. |
|
