ソフトウェア品質保証

古い会社にありがちな弊害

世の中に、ソフトウェア開発が失敗する事例は多くある。

いつまでたってもバグがなくならず、
バグがあるのを知っていて出荷してしまい、
お客様に迷惑をかけつつも、
いつまでたっても、ソフトウェア開発の能力が高まらない組織というものがある。

身近な組織を観察してみた。

・ソフトウェア開発チームと品質保証チームが仲間になってしまう
・品質保証チームがソフトウェア開発チームのご用聞きになってしまう
・品質保証チームのマネージャが品質保証の素人である
・品質保証チームが品質保証の仕事をしない
・品質保証チームがどうでもいいことに口を出しすぎる
・品質保証チームに品質保証のスキルと経験がない
・品質保証チームに実はソフトウェア開発チームに入りたい人がいる
・品質保証チームが品質保証とはデータを集めることだと思っている
・品質保証チームが品質保証とは報告書を作ることだと思っている
・シニアマネージャが、品質保証チームには頭数だけそろえれば良いと思っている
・シニアマネージャが、実は品質保証なんていらないと思っている

簡単に列挙できる。
いくらでも問題をあげられそうだ。


こうして並べてみると、ソフトウェア開発チームの問題というより、
品質保証チームの問題が多い。

しかし、その問題というのは、古ぼけてしまっている伝統企業にはありがちな問題のように見える。

古い伝統企業はソフトウェア開発をするな、

というのは、やや乱暴な言い方かもしれないが、

若い元気な企業に比べると、その資質が劣るのは、疑いのないことのように思う。

それでも、古い伝統企業がなんとかやっていけるのは、

国は政府との関係があるからなんだろう。

とりわけムラ社会の日本ではそうなんだろう。

| | コメント (0) | トラックバック (0)

レビューで見つけた誤りの分析について

レビューを十分に行ったはずでも、

誤りが流出してしまうことがある。

そのような場合、流出した誤りを分析すると、

流出しやすい誤りの特徴や、

誤りを見逃してしまうレビューアーの習慣が明らかになる。

■分析で終わらず、情報を活用する

それらの情報を、

レビューガイドラインやチェックリストに応用することが、

個人やチームのレビュー能力の向上につながる。

■テストでも同じ

上のことは、レビューだけでなく、テストにも当てはまる。

テストで見つけられなかった誤りを分析することで、

さらに良いテストを設計できるようになる。


| | コメント (0) | トラックバック (0)

検証(レビュー、テスト)の費用対効果について

ソフトウェアの開発状況を調べていると、

前フェーズからの誤り流出が、費用対効果を考慮した計画の結果と考えられる場合がある。

つまり、コストのかかる検証を減らすかわりに、誤り流出リスクを管理して、計画的に誤りを流出させているのだ。

世間には、

「フロントローディングが良くて、誤り流出は悪い」というスローガンばかり唱える管理職もいるけれど、

この開発は、開発管理を適切に行っている良い事例だと言える。

■ソフトウェア品質保証はある意味ギャンブル

こんなことをいうと、上のような管理職には怒られるだろうが、

実際のところ、

ソフトウェアの品質保証は、ギャンブル的な一面がある。

誤りが流出するかもしれないリスクをとって、

レビューやテストのコストを削減することもできる。

そうやって、もし誤りが流出しなければ、

開発チームの勝ちだ。

■効果(勝ち負け)の検証

開発の終了後に、

検証の費用対効果を評価して、自分たちの方法の有効性を評価してみるのが良いだろう。

| | コメント (0) | トラックバック (0)

ソフトウェア品質保証

SQA

一般にほとんど知られていないこの言葉は、

Software Quality Assurance(ソフトウェア品質保証)の略語だ。

この言葉は、

一般にほとんど知られていないどころか、

企業のソフトウェア開発部門でも知られていないことも多いし、

その言葉を使っていても、

その定義は使う人によってバラバラ、

というのが実状だと思う。

どうせバラバラなのなら、早く言ったもの勝ちなので、

私も一言言ってみる。

ソフトウェア品質保証とはテストのことである。

と。

そして、

ソフトウェアに品質管理の考え方や手法は摘要できないぞ。

と。

それにしても、

ソフトウェアの品質管理ができるなどという勘違いをしている、

ソフトウェア品質保証部門や、

ソフトウェア開発部門や

ましてや経営層の人々の、

なんと多いことか。


ネジや電気回路といった、

同じ設計に基づいて、同じ製造過程が繰り替えされる場合には、

品質管理の考え方や手法は有効だろう。

しかし、

ソフトウェアはいつも一品生産で、

製造と呼べるのは、

CDーROMやDVDーROMに焼くときぐらいだ。

あえて言えば、

そう。

ソフトウェアは工業製品ではなく、美術品あるいは工芸品だ。

しかし、美術品や工芸品にも品質保証はある。

それは、いくら美しい工芸品でも、

簡単に形が壊れてしまったり、

塗装が剥げてしまっては、

その価値が損なわれるからだ。

だから、そうならないようにテストをする。

テストの目的は何か?

バグを見つけることだ。

ここが分かっていない人は多い。

ソフトウェア品質保証部門の人も、

ソフトウェア開発部門の人も、

等しくわかっていないことが多い。


そこが分かっていないので、

「何項目テストして、何項目バグを見つける」

というような指標値を、ソフトウェア品質保証部門の人がつくり、

ソフトウエア開発部門の人は、

「何項目テストして、何項目バグを見つけたからOKでしょう?」

と同意を求めてくる。

そこが間違いだ。

数字にはそれほど意味がない。

むしろ欲しい説明は、

「ソフトウェアのこの辺りに、バグが潜んでいる可能性が高いので、

それを確かめるために、こんなテストをしたところ、

これだけのバグが見つかりました。

他にも同様のバグが、

あそことか、そことかにあると思ったので、

こんなテストを追加したところ、

案の定、これだけのバグが見つかりました。

もうないと思いますが、

念のため、

リスクとして管理しておきます。」

というような説明だ。

数字にそれほど意味はない。

重要なのは、バグをみつけるテストのモデルだ。

この「ソフトウェア品質保証とはテストのことで、テストはバグを見つけるために行うのだ」

という文章は、

実に簡単だが、

実は、

私自身、つい最近になって、たどり着いたアイデアだ。

しかし、

この文章は、とても潔く、清々しいので、

気に入っている。

では最後にもう一度。

「ソフトウェア品質保証とはテストのことで、テストはバグを見つけるために行うのだ」

| | コメント (0) | トラックバック (0)