五月原清隆のブログハラスメント

これからは、セクハラでもない。パワハラでもない。ブロハラです。

テストデータビンカン選手権

 久し振りに、仕事関連の話を書いてみます。
 現在、私の作業は「相手ベンダーから送付されたテストデータの不具合をチェックする」というものです。基幹系業務システムともなれば、異機種間インタフェースが山のように発生しますから、そのデータの内容に不具合があると、それがそのままシステムの不具合となってしまうのです。それ故、システム開発が進んで実際にデータを出力できるようになると、そのデータに整合性があるかどうか、逐一チェックしなければならないのです。
 しかし、どのシステム開発プロジェクトでも同じなのか、初期に出てくるテストデータなんてのは実に見るも無惨なものです。コード体系の逸脱やマスタ不備なんてのは日常茶飯事で、データベースの桁数溢れなんて事もままあります。「業務知識があれば、こんなデータは寄越してこないだろうよ」というようなテストデータについて、逐一何処が不具合なのかを指摘し、改良を促すというのが、私の仕事なのです。
 それにしても、今回一緒に仕事をしているベンダーは、不具合を出し過ぎです。メールやミーティングでこちらから口を酸っぱくして説明した仕様が盛り込まれていないのは当たり前で、Shift_JISのファイルフォーマットなのに全半角を軽々と無視したり、NUMBER型の項目に平気で文字列を突っ込んでみたり、挙げ句の果てには「抽出結果0件」などとほざいて空ファイルを寄越してくる事すらあります。ここまで来ると、仕様をきちんと理解しているかどうかという以前に、「アンタらにITエンジニアとしての資質はあるのか?」という問題のような気もします。
 そこで、私は悟りました。「これは、インタフェーステストなんかではない。テストの名を借りた芸能界ビンカン選手権なのである!」と。

くりぃむナントカ

http://www.tv-asahi.co.jp/nantoka/

 要するに、

  • 不具合票の発行は1人1回のみ。
  • 簡単な不具合はポイントが低い。
  • 「仕様通り」という回答を食らったドンカンはマイナス10ポイント。

 という事で、有田哲平相手ベンダーが仕掛けてきた分かり易い不具合を見て不具合票を発行してしまうと、それは相手の思う壷です。それよりも、テストデータや仕様書を熟読しないと見付けられないような不具合を見付け出し、相手ベンダーに「ビンカン!」と言わせなければ、高額発注を出してもらえないって事なんでしょうね。こう考えれば、普通なら苛立ってしまうような不具合の数々にも、寧ろ平然と対応していられるというものです。
 いや、それにしたって1ポイントの不具合が多過ぎ(;´Д`)