読者です 読者をやめる 読者になる 読者になる

テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

テストってなんだろう? 第4回「欠陥の偏在」

7つの原則 Foundation Leval JSTQB

2日連続の「なそ」です。

ちょっと最近品質ってなんだっけ?状態に舞い戻ってきているので、勉強を兼ねてFLの復習を行ってます!

 

さてはて、7つの原則も4つ目「欠陥の偏在」です! とうとう折り返し地点ですね♪

 

これは、皆々様も経験あるのではないでしょうか?

人によって得意・不得意があるようにプログラミングにも癖が出ます。

プロジェクトや組織によっても癖が出ます。要はQCDのどこに重点を置くかという問題なのでは無いでしょうか?

本当は癖など出さずに万人向けのプログラムを書くべきなのでしょう。しかし、膨大なルールやその時のトレンドを反映したプログラムは現に沢山存在するのです!(言い切ってしまってますが、本当にちゃんとしている所もあります)

そういうことで、バグの発現にはある程度予測できます。できることならチケットをいい感じに分類して傾向のメトリクスをとって見るものいいと思います。

 

プロダクトの特性だったり、プログラム固有の問題。はたまた個人の癖だったりします。それは秘伝のタレとなって、誰も触ることができない魔物と化します。「汝ら、リファクタリングを禁ず」とか看板(コメント)が残っているかも知れません。魔窟に住むドラゴンのごとくですね。勇者が現れるまで、そこには立ち入ることができません。。。

 

とまぁ、そんな壮大なものではないです(笑)

 

たいていの場合、過去の実績を元に知見がある人達をアサインして、属人性を持ってプロジェクトを運営したりしますね。過去のチケットから傾向を洗い出すって言うプロジェクトもあるでしょう。

過去に結合テストで失敗したプロジェクトがあれば、そこに重点を置くのも手です。

そうやっていろんな人の知見を得ながら少しずつ成長するべきだと私は思っています。

それが歴史を積み重ねるということで、老舗のSIerにしかできないことだと思ってました。今も思ってます。だからこそ、あの不甲斐なさには心底がっかりしたんです。

案件数で稼ぐ方法もあります。しかし、これにはその人達の知見をまとめにくいという問題もあります。

 

語り継ぐべきことは、過去の栄光ではなく過去の失敗談です。そういうものほど傾向が似ていたりします。でも、恥ずかしくて人に言いにくいんですよね。これ。。。(笑)

 

欠陥はまんべんなくプログラムに入り込むわけではなく、仕様が甘い所、作りが複雑な所に入り込みます。そういった所を開発者とコミュニケーションをとって、品質は問題無いということを宣言できるテストエンジニアに私はなりたい。

 

それでは、今日はこんなところで。