作成日 2017/3/26
最終更新日 2017/3/26

品質確保の難しさ

 品質確保は難しいです。その理由を説明します。
 品質不良の言い訳は聞きたくないって?
 不具合によって時間をつぶした人には申し訳ないし、気持ちは良く分かるのですが、どうしようもないのです。それを説明します。


1.そもそも全パターン試験できない
2.品質の定義がむずかしい
3.情報処理技術者試験での内容が薄い
4.最後に
5.参考文献など


1.そもそも全パターン試験できない

 いきなり、「は?」と思うでしょう。
 実はたった数十行のソースコードでも全パターン試験できないことが証明されています。

 例えば、画面から入力された値(数値)分だけ、繰り返し処理するプログラムがあったとします。
 0回の時、1回の時、2回の時、、、まあ、これくらい行えば、命令網羅・分岐網羅はするからほぼ、バグは無い様に思えます。
 しかし、30回の時に不具合が起きるとしたらどうですか?(例えば、原因はメモリ不足とする)。
 30回がOKとして31回は???他の原因で駄目かもしれません。
 また、処理を行っているときに、他から割り込みがあったらどうでしょうか?
 エクセルVBAではマクロの実行中に中断できますが、正しく中断できますか?これも、1回目のとき、2回目の時、、、全てです。

 全パターン試験するというのは、取り得る値、割り込みタイミング、その他の状態の全てのパターンで試験を行うということです。
 1回くらいなら試験できるかもって思うかもしれないですが、バグ修正したら、もう一回やり直しです。一体どれだけの時間がかかるのでしょうか?

 以下、引用の引用になってしまうかもしれませんが、書籍「基礎から学ぶソフトウェアテスト 〜テストの「プロ」を目指す人のために〜」(ISBN4-8222-8113-2)の21ページに記載されているものです。
1979年に,Myersはさらに単純なプログラムを書いた。その中にはループが一つ
とIF文が数個しかない。どんなプログラミング言語でも,20行で書けるはずだ。こ
んなプログラムでも,100兆のパスがあり,優秀なテスト担当者でも,全パスをテス
トするのに10億年かかる。
 うん。無理。
このページのトップへ

2.品質の定義がむずかしい

 品質の定義がむずかしいです。
 いやいや、品質が良い=バグが少ないあるいは無いことだろって?
 だから、今度はバグ定義がむずかしいです。

 言っている意味が分からないって?
 多くの人が思う、バグというのは正しく動かない、ですよね。でも、遅いというのもバグなんです。

 バグには2種類あると考えています。1つが機能性のバグで、もう1つが非機能性のバグです。非機能性というのは、動作は正しいが、「なんかなー」、というものです。
 先ほどあげた、遅いとかです。他にもいろいろあります。
 「遅い」というのは、具体的にどういう状況で何をして、何秒なのか?です。使うPCなんてみんなばらばらだから、定義が難しいです。もちろん、試験するけど、ソフトの利用者が実際に行う環境を完全に再現できないからね。

このページのトップへ

3.情報処理技術者試験での内容が薄い

 品質を語るのは難しいです。
 いろんな知識(設計技術、セキュリティ、JISなど)を必要とするためです。
 情報処理技術者試験は、薄く広くです。広いのは、良いことです。繰り返しになりますが、品質を語るためにはいろんな知識を必要とするためです。しかし、薄いからなぁ。

 例えば、モジュールの強度・結合度は、JIS X 0129-1で定義される品質のうち、保守性に関係してきます。
 しかし、参考書(古いのですが、ソフトウェア技術者の参考書)を見るとそこまでは書いていません。

 テストについては、ホワイトボックステスト、ブラックボックステストがあります。
 参考書では、後は、境界値分析、命令網羅などが書かれていますが、本当にこれだけ。。
 データ網羅とか、そんな記載なし。
 スレッド関連のバグは再現性が低いとか、もちろん、記載なし。
 やっぱり内容が薄いよ。
 まあ、でも、試験内容を増やすのは無謀だからね。

 情報処理技術者試験での内容が薄いと、どうしても知識不足になってしまうんです。
このページのトップへ

4.最後に

 繰り返しになりますが、品質を語るのは難しいです。
 これまた、繰り返しになりますが、いろんな知識(設計技術、セキュリティ、JISなど)を必要とするためです。
 実は品質については2008年頃にアップする予定でした。が、知識不足で一旦消えました。
 今は、2017年。9年かかった・・。
このページのトップへ

5.参考文献など

 このページを作成するのに参考にした書籍です。

番号

著者名

書籍名

ISBN

説明

1 Cem Kaner (著), Hung Quoc Nguyen (著), Jack Falk (著), テスト技術者交流会 (翻訳) 基本から学ぶソフトウェアテスト テストの「プロ」を目指す人のために 978-4822281137 p21に全パターン試験できないことについての記載があります。

Prev Up Next  Top

このページのトップへ

このページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。
このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方はメールをお願いします。

Microsoft 、Windows 、Visual Basic および Excel は米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
ここではExcel® をエクセル、Visual Basic® for Applications をVBAと表記する場合があります。
Mac 、Mac OS 、Mac OS X は米国Apple Computer,Inc.の登録商標または商標です。
その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。

このホームページの作成者はこれらの会社とはいっさい関係がありません。