2006年11月05日(日)

チェックを減らして品質を上げる

テーマ:テスト
あるプログラマが、データベースに保持しているデータを独自形式のファイルに出力するプログラムを作った。処理自体は単純なのだが、項目数が多いため、動作確認が大変だった。彼は、全ての項目が正しく出力されていることをチェックするために、Excel を使うことにした。

まず、プログラムの入力データと出力データを、Excel のシート上に2列に並べた(※1)。そして、その次の列には、入力データと出力データのセルを比較する「数式」を書いた。両方のセルが同じ値なら "○"、違う値なら "×" を表示する数式である。

プログラムの動作が正しければ、シートの全ての行に "○" が表示されるはずだ。彼は、この方法で単体テストを完了させた(※2)。


しかしである。その後の結合テストで、このプログラムにバグが見つかった。1つの項目について、入力元の項目名が間違っていたのである。

当然、「なぜ単体テストで発見できなかったのか?」と問われた。そこで、単体テストで確認に使われた Excel ファイルを開いてみると、該当の項目にはちゃんと "×" がついていた。

つまり、彼は大量の "○" の中にある1つの "×" を見逃してしまったのである。Excel の「数式」で自動的にチェックしているということに安心して、結果の確認が疎かになってしまったのだ。



彼がデータの確認に Excel を使ったのはよい選択だ。しかし、項目ごとに "○" と "×" を表示しただけでは、結局は、その数だけ人間の目でチェックしなければならない。

人的ミスを減らすには、人間の仕事を減らすことだ。この例では、更に全項目の "×" をカウントする数式を追加することで、人間が見るべきところを1箇所に集中させることができる。項目が百個だろうが千個だろうが、人間は1つのセルを見ればよい。どうせ Excel を利用するのなら、そこまで「設計」して欲しかった(※3)。

ただ Excel の数式を書くというだけのことではあるが、これも立派なソフトウェアによるソリューション(問題解決)である。システム開発は問題だらけなので、問題解決のための「ネタ」には困らない。プログラマには、常に業務要求の分析力やソフトウェアの設計力を鍛えるための機会が与えられていると言っていいだろう。それを生かせるかどうかは、自分次第である。




※1
本当はデータを「2行」(つまり「横」)に並べたかったのだが、Excel の最大列数(256 列)を超えてしまうため、ここでは「縦」に並べた。

※2
本来なら、別の人間によるテスト記録(ここでは Excel シート)のチェックをもって「完了」とすべきだった。しかし、このケースでは、それができていなかった。

※3
もちろん、「数式」を間違えていないという前提であるが。



■関連記事
面倒くさいこと
プログラミングは体で覚えろ
テストを簡単にし、品質もアップする方法
気の利いたプログラムは顧客満足度を上げ、開発工数を下げる



Excelマニアックス!―誰も知らない、セルの裏側。
井上 孝司
ラトルズ
売り上げランキング: 96,872
おすすめ度の平均: 5
5 Excel生誕20周年


問題解決プロフェッショナル「思考と技術」
齋藤 嘉則 グロービス
ダイヤモンド社
売り上げランキング: 816
おすすめ度の平均: 4.54
5 平易だが奥は深い
4 問題解決の「思考」と「技術」の基本が分かる。
4 これで理論と実践をつなげられる!
AD
いいね!した人  |  コメント(6)  |  リブログ(0)
2005年06月12日(日)

「環境不足」はマルチブートで解消せよ

テーマ:テスト
2005年の今でも、Windows 95 で動くようなシステムを作ってくれ、と言われることがある。10年も前の OS を使うユーザーがどれほどいるのかは知らないが、不特定多数のユーザに利用してもらうシステムの場合、サポートする OS は多いほうが良いということだろうか。

しかし、これは、開発者にとっては大きな問題である。

というのも、同じ「Windows プログラム」を作るといっても、どのバージョンの Windows をターゲットにするかということによって、作り方が違ってくることがあるからだ。例えば、同じ機能でも、XP 専用のプログラムとして作るのは簡単だが、95 でも XP でも動くように作るには何倍もの時間と労力が掛かる場合もある。

技術的な難易度が高くなるというだけではない。サポートする OS のそれぞれで、ある意味重複した動作確認を行わなければならない。テストのために、パソコンを何台も用意して、色々な OS をインストールした、という経験のある人も多いだろう。

しかし、小規模な開発会社では、用意できるパソコンの数にも限界がある。作業スペースの問題もあるだろう。かといって、1台のパソコンに何度も OS をインストールしなおすのは、非常に手間が掛かる。


そんなときに便利なのが「マルチブート」である。1台のパソコンに複数の OS をインストールして、起動時にどの OS を利用するかを切り替えるのである。

Windows 以外の OS を切り替えて使うこともできるので、普段使っている Windows パソコンに、Linux 環境を追加するようなこともできる。

ただし、実際にマルチブート環境を構築するには、それなりの知識が必要である。特に、既に利用しているパソコンの環境を残したまま、別の OS を追加したいような場合には、リスクが伴う。

しかし、上記のような「環境不足」の問題でお悩みの方には、リスクに見合うだけのリターンはある。しっかりと勉強した上で、チャレンジしてみてはどうだろうか。




マルチブートの具体的な実現方法については、ネットで検索 すれば色々と情報が得られるだろう。「ブートマネージャ」と呼ばれるソフトが必要となるが、無料で入手できるものでも十分だと思う。私もMBM というフリーソフトを使っているが、高機能なのでお薦めだ。他に、「パーティショニングツール」と呼ばれるソフトが必要となる場合もあるが、その場合は、市販のパッケージを用意したほうがいいかもしれない。



みき ゆうき, チームエムツー 著
いろんなOSを1台のパソコンで使うための本
Partition Magic研究会 著
がんがん使おうPartition Magic
ネットジャパン
ノートン・パーティションマジック 8.0J
ライフボート
システムコマンダー 8
ソースネクスト
Acronis PartitionExpert Personal
AD
いいね!した人  |  コメント(2)  |  リブログ(0)
2005年03月27日(日)

バグを求めるものたち 後編

テーマ:テスト
テスト工程の品質を、テスト項目数やバグ件数のような「量的」な指標だけで把握することには限界がある。

プログラムの規模などから、どのくらいのテスト項目数が必要なのか、どのくらいバグが発見されるのか、といったことは、ある程度は想定できるかもしれない。

しかし、そうした量的な指標が有効なのは、開発するシステムの種類や特徴、プロジェクトチームのスキルなどが、安定している場合だけであろう。例えば、同じ開発メンバーが同じようなシステムを作る場合には、有効かもしれない。

逆に言えば、どんなプロジェクトにでも通用するような、量的基準を作ることは難しい。例えば、テスト項目数が基準値を満たしていても、テスト観点に抜け漏れがあれば、何の意味もない。


当たり前の話ではあるが、テスト工程の「品質」を正しく把握するためには「質的な」評価が必要である。

テストを行うに際に大切なのは、テスト項目の数ではない。テストの観点に偏りや抜け漏れがないか、ということである。それを確認するためには、テスト項目の内容を詳細にチェックしなければならない。

また、発生したバグについても、ただ件数を数えるだけではなく、内容まで分析しなければ意味がない。例えば、結合テストで10件のバグが見つかったとしよう。数字だけしか見なければ、ただそれだけの話である。しかし、内容まで調べれば、そのうち9件が「単体テストで見つけておくべきバグ」であることが分かったりする。このように、質的に意味のあるレベルまで分析しなければ、数値の意味はない。


量的な評価が、テスト項目の数を数えるだけでできるのに対し、質的な評価をするには、非常に多くの手間が掛かる。

しかし、だからといって、量的な指標を絶対視し、それだけでテストの品質を決めつけてよいというものではない。

管理者が恐れるべきは、「管理しているつもりになること」である。数値を測定し、表やグラフを作れば、なんとなく管理をしている気分になってしまう。しかし、質的に意味のない数値は、いくら集めても役に立たない。

そうした実のない管理方法が最悪の結果として現れるのは、抗いがたい権力をもって、開発者に「量的なノルマ」を課した時である。

前編中編 に書いたような弊害は、その例である。

ここで、「バグが出ないこと」に悩まされていたプロジェクトマネージャは、顧客に虚偽のバグ数を報告をすることもできたはずだ。それをさせなかったのは、彼の人としてのモラルである。

しかし、この顧客が必要以上に「バグ数の要求」を続けるならば、いつか誰かが虚偽の報告をしないともかぎらない。

バグ数を増やすために故意に品質を下げるくらいなら、嘘をついたほうがマシだと考える開発者は必ずいる。

開発者にとって、「品質を上げる」ということは、それほど重要なものなのである。





※単体テストはひとつの機能(部品)のみのテストで、結合テストは複数の機能を組み合わせたテスト。当然、それぞれのテストは「観点」が違う。結合テストは、単体テストの後に行う。



■関連記事
バグを求めるものたち 前編
バグを求めるものたち 中編



ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ボーリス バイザー
日経BP出版センター (1994/02)
売り上げランキング: 27,689
おすすめ度の平均: 5
5 ソフトウェアテストの基本となる2冊の本のうちの1冊
5 もっとも引用される本の一つ


実践的ソフトウェア測定
John McGarry Cheryl Jones Elizabeth Clark David Card Beth Layman 古山 恒夫 富野 寿
構造計画研究所 (2004/07)
売り上げランキング: 60,076
おすすめ度の平均: 4
4 メトリクスの教科書として最適

AD
いいね!した人  |  コメント(4)  |  リブログ(0)
2005年03月22日(火)

バグを求めるものたち 中編

テーマ:テスト
プログラムのテスト工程において、「○○ステップ あたり○○件の不具合が出なければならない」といった基準が設けられることがある。

それだけの数の不具合(バグ)がみつからないということは、テストが十分でないのだ、というわけである。

確かに、テストという工程だけをみれば、そのような判断も正しいのかもしれない。しかし、システム開発全体としてみれば、弊害もある。

伝統的なシステム開発では、テストの工程はプログラミングの工程の後に行われる。つまり、その場合、プログラミングが完了した時点で、一定数以上のバグが残っていなければならないということになってしまうのだ。


プログラミング完了時点でのバグをゼロにすることは、プログラマの目標のひとつである。彼らは、その目標を目指し、工夫、努力を続けている。前編 で述べたような「動作確認」もそのひとつである。

このようなプログラマの努力によって、プログラミング工程での品質が上がれば、テスト工程で見つかるバグは少なくなるのは当然である。

しかし、そのような場合でも、発見されたバグの数だけで、テストの精度が評価されるような状況では、「テストが十分に行われていない」と判断されてしまうのである。

前編で登場したプロジェクトマネージャの「プログラミング中にプログラムを動かすな」という指示は、こうした背景から出てきたものであった。彼は、顧客から、テスト工程の完了条件として、「最低バグ数」を提示されていたのである。

彼は過去にこの「最低バグ数」をなかなかクリアできずに困ったことがあるという。今回も、テスト工程でのバグが少なくなってしまうことを心配し、そのような指示を出したのである。


彼は、「動作確認」をプログラミング工程で行うか、テスト工程で行うか、という違いを、それほど重要視していないのかもしれない。

確かに、テスト工程で抜け漏れのない 100% 完璧なテストを行えるのであれば、彼のようなやり方でも、最終的に完成したプログラムの品質が下がることはないだろう。

しかし、現実には、よほど単純なシステムでない限り、「完璧なテスト」を行うことは困難である。「プログラミング中の動作確認」を禁止すれば、当然、バグが見逃される可能性は高くなり、品質は下がるだろう。実際、プログラミング中でなければ気がつかないような「テスト観点」というのもある。

また、仮に「完璧なテスト」が行えるとしても、バグというものは見つかるのが早ければ早いほどよいものである。後の工程になるほど、バグを修正することよる影響範囲が広くなるし、本来は必要なかったはずの「再テスト」の手間も増えるからだ。

プログラミング中にバグを見つけられるチャンスがあるのに、それをわざわざ禁止して手間を増やし、更には品質を下げてしまうというようなやり方が、果たして正しいといえるだろうか?

続く




■関連記事
バグを求めるものたち 前編
バグを求めるものたち 後編



若手SEのための ソフトウェアテストの常識
秋本 芳伸 岡田 泰子
ディー・アート (2006/01/25)


プロジェクト品質マネジメント―全体最適を実現する4つの柱
ティモシー・J. クロッペンボルグ ジョーゼフ・A. ペトリック
生産性出版 (2003/08)
売り上げランキング: 65,349


いいね!した人  |  コメント(2)  |  リブログ(0)
2005年03月21日(月)

バグを求めるものたち 前編

テーマ:テスト
「プログラミング中には、作ったプログラムを動かすな。ただソースコードを書いてコンパイルが通ればよい。とにかく、テスト工程に入るまでは絶対に動かさないこと」

あるプロジェクトマネージャが、プログラマにこのような指示をしていた。

おかしなことを言うものだ。

プログラミング中に「動作確認」ができるのなら、積極的に行うべきだろう。そのほうが品質のよいプログラムができるに決まっているからだ。


プログラミングの目的は、単に「ソースコードを書く」ことではない。「正しく動くプログラムを作る」ことである。

文章の誤字・脱字を探すのとは違って、ソースコード上のミス(バグ)は、読み返しただけではなかなか見つからない。実際にプログラムを動かして確認しなければ、見逃してしまうことも多い。経験が少ないプログラマであればなおさらである(※1)。

大きなシステムを作る場合でも、まず一部の機能だけのソースコードを書き、そこだけを動かしてみて、確認すべきだ。その部分が正しく動いたら、別の小さな機能を書く。少し書いては動作を確認し、動作を確認してはまた少し書く。このようにして、小さな機能を着実に作り、それを積み上げていくことで、品質の高いシステムが出来上がるのである(※2)。

プログラマが念入りに「動作確認」を行うほど、品質は高くなる。「プログラミング中にプログラムを動かすな」という指示は、品質を落とすためになされているとしか思えない。

私がそのような指示を受けたプログラマであったら、指示は無視して、プログラミング中の動作確認を行うだろうと思う。また、全てのプログラマにも、そうであって欲しいと思う。


問題は、なぜこのマネージャがバグの数を増やすような指示を出したのか、ということだ。

続く




※1
もちろん、ソースを読み返す必要がない、というわけではないので、誤解のないよう。

※2
テストドリブンとか、テストファーストと呼ばれる手法は、それを徹底(かつ自動化)したものといっていいだろう。



■関連記事
バグを求めるものたち 中編
バグを求めるものたち 後編



図解入門 よくわかる最新ソフトウェアテスト手法の基本と極意―ソフトウェア品質向上のための実践テスト手法
若林 宏
秀和システム (2003/11)
売り上げランキング: 238,824
おすすめ度の平均: 2.25
3 ソフトウェアテストで必要最小限の知識を紹介
2 手始めに読むための本
3 即実践本。この本でなくとも構わないが・・・


世界一わかりやすいプロジェクト・マネジメント
サニー ベーカー G.マイケル キャンベル キム ベーカー
総合法令出版 (2005/04)
売り上げランキング: 7,301
おすすめ度の平均: 5
5 分厚いが読み通す価値あり
5 判り易く・やる気にさせるプロジェクト管理指南書

いいね!した人  |  コメント(4)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。