■

テストについて。

ソフトウェア・メトリクスとか言われ始めてだいぶ経ちますが、テストについての認識が、自分の周りであまり変わっていないです。テストをする、という事がどういう事がよく分かってない人が多いんです。テストをする、って事は対象の状態を確認、把握する事です。品質とは、このテストの内容によって決まってくる訳です。でも、ここで一つの勘違いがあるようです。「テストをする＝品質を確認する」が、「テストをする＝品質が向上する」という勘違いです。もうこの業界に入ってから6年くらい経ちましたが、こういう人が殆どです。

テストをして品質を把握できたとして、見るからに挙動がおかしいモノを見つけたら「修正して当たり前」という事なんでしょう。これは昔ながらのソフトウェア開発ではアリだったかも知れませんが、今の時代でこういう事を「当然」としてしまうと危険な気がします。テストを実施し、不具合っぽい挙動を見つけた場合、まずそれが不具合なのか仕様通りなのかを判定しなければいけませんよね。じゃあ、判定する為の基準って何かというと、これはお客様から頂いた要件だったり、要件から決定した仕様だったりする訳です。

では、テストを実施する作業者がちゃんと要件も仕様も把握していて、正しい判断が下せるのかというと、それは無理です。これは作業者のスキルを言っているのではなくて、テストを実施する作業者にそういった働きを期待するのは、要件定義や外部設計を担当した人間の怠慢だって事です。SES契約という名の偽装派遣で、かつ会社の上下関係、力関係の中で、テストを担当する人ってわりと買い叩かれている人たちってのが実情です。きちんと要件から仕様を決めて、その仕様を分かりやすく記述した仕様書を全てそろえてそれでも間違って作ってきた、みたいな話ならともかく、安いお金で、要件の把握だなんて上流工程の担当者ですら満足に出来てない事を期待するのは、お門違いも良いところで、そんなのはただの甘えです。

なので、正しくは「テストをする＝現在の品質を確認する」というミッションが達成できたら、続いて「現在の品質を分析」して、それが妥当かどうかを評価します。結果が妥当と見なせなければ、修正をしなければなりませんがこの時、それぞれの担当者の判断に任せるのではなく、きちんとチームの総意として修正する方向性を示してから、修正を行うべきなんです。そうでないと、オブジェクト指向とかデータ中心アプローチとか、色々な工夫で何とか高品質なシステム開発の実現をしようと業界の一部が頑張ったとしても、台無しです。

しかも、システムの品質の低下は、ややもすると前述の「買い叩かれた人」のスキルに原因を求めがちです。でもそれは、そういったメンバーにも理解できる仕様や工夫を作らなかった事や、そういうメンバーにも理解できるように説明をしなかった事が、原因なんです。（それでも、そういう予防策の斜め上から見事なまでに台無しにして回る奴も確実にいますけど）システムの品質というものはそのビジネスを左右します。これを一部の人間の努力にのみ求めていては、いつまでたってもお客様へのサービスの安定供給なんて出来ません。

システムの品質は、お客様の要件をまとめるところからそのシステムの起動に立ち会う人まで、全員が等しく責任を負う、という事をもう少しこの業界の人たちは理解すべきです。

と、ちょっと熱く語ってしまいましたが、このへんは後々じっくり考えたいです。