トップページ | 2005年5月 »

バグか試験手順ミスか

試験の結果がNGとなった場合 テスターは まず それがバグなのか試験ミスなのかを判断する必要があります。試験手順書のとおりに実施した結果が手順書どおりでなくても、試験ミスが一定の割合で入ってしまうため、一概に試験NGとはいえないからです。

私の経験上、一番最近担当したプロジェクトでは、1~2割程度の試験ミスがあり、一番酷かったプロジェクトでは4割程度の試験ミスがありました。
はっきり言って無視できない発生頻度です。

一言で試験ミスと言っても、いくつかパターンがあります。
たとえば、試験手順書作成者と試験実施者、試験データ作成者が別れているような場合、ミスはこんな感じで発生します。
 ・試験手順書作成者:
   試験手順書誤記
 ・試験実施者    :
   試験結果の見間違い、試験手順書の内容誤解
 ・試験データ作成者:
   試験データの誤り

やっぱり、人間はどうしてもミスをしてしまいますので、ミスを減らそうと思えばレビューを増やすしかありません。
でもレビューを増やすと目先の効率が落ちてしまうためなかなか時間が取れません。
だからといって放置すれば試験ミスが増えるし…

何かよい方法はないものか、思案の日々です

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

@nifty:NEWS@nifty:死亡51人・負傷417人、まだ車内に多数の乗客(読売新聞)

@nifty:NEWS@nifty:死亡51人・負傷417人、まだ車内に多数の乗客(読売新聞).

正直背筋の凍る思いをしました。

昔事故現場の近所に住んでいたことがありますし、あの路線には何度も乗ったことがあるだけに他人事には思えません。

車の事故なんかだと、気をつけることである程度の予防ができる気もしますが、電車の脱線の場合注意の仕様がありませんので、非常に恐ろしいです。

いずれにせよ、まだ救出されていない方もいらっしゃるようですし、一刻も早い救出を祈るばかりです。

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

マウス

つい最近まではPC付属品の光学マウスを使っていたのですが、思い切って新しいマウスを購入してしまいました。

LogitechのMX1000です。

どうせ買い換えるならイイやつにしようと奮発しました。

使ってみての長所ですが、やっぱりマウスが動かしやすいです。ワイヤレスマウスを使用するのは今回初めてなんですが、ケーブルがないとマウスケーブルの有る/無いの違いがこれほど大きいとは思っていませんでした。

あとは、エルゴノミクスデザインですね。マウスを握ると結構気持ちがいいです。

ただ、長所ばかりではなく次のような欠点もあります。

・ベースステーションをモニタの横に置くと 電波のとびが悪くなる。20cmぐらいしか飛ばない。

・マウスをしっかりにぎらないといけない

・クルーズアップ/ダウンのスクロール速度が速すぎる

という感じで、手放しではほめられませんが、トータルで考えるとなかなかいい感じです。会社用と家用で2台も買ってしまいました。これで安ければ絶賛するところなんですが、値段が高いのが痛いところです…

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

素人のテスター

ソフトウェア開発が佳境にさしかかると、いよいよソフトウェアテストが始まります。
このテストが本格化すると大量に発生するバグとの格闘が始まるわけです。

自分で設計からテストまで行う場合は、バグを見つけるー>修正->バグを見つける->修正…の流れを自分自身で繰り返すため、一つのバグが原因で複数の症状が発生することはあまりありません。

逆に他人にテストをしてもらう場合、障害が見つかってもそれが同一の原因によるものか否かの区別がつかないため、一個のバグが原因で大量のバグレポートが発行されることがあります。
仕方ない部分は多いにあるとはいえ、同一の原因に対する2枚目以降のバグレポートは、バグ改修担当者にとっては作業量が増えるだけの代物で、はっきり言って無駄です。

開発経験のある人やある程度テストに慣れている人ならば、似たようなバグが連続発生すればそこで「おや?」と気づいて、そのタイミングで実装担当者へ連絡するとか、似た傾向のテストを止めるようなことをしてくれるんですが…

まれに、ほぼ同一の症状に対して大量のバグレポートを発行してくるテスターが存在して困ります。テスターの仕事はバグを見つけることですが、バグの件数を増やせばいいというものではありません。同一の原因から発生する事象毎に大量のバグレポートを発行しても、それが作業量を増やすだけだということがわかっていません。

高度な要求をテスターに求めるつもりはないですが、せめて 足を引っ張るのだけは勘弁してもらいたいところです。

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

仕様変更と不具合対応


私の経験上、お客さんや親会社からの改修依頼は内容が不具合対応であっても無理やり仕様変更とみなすことが多いです。実際、不具合対応だとお金がもらえませんが、仕様変更ならば開発費等の名目でお金をもらえますのでこの違いは大きいです。
しかし依頼の内容を冷静に考えると仕様変更と呼びつつ、実はただの不具合対応というのもしばしばあります。
正直なところ何を仕様変更とみなして、何を不具合対応とみなすかというのは難しい問題です。

客観的に考えてみると、ソフトを開発していて、開発中に「本当の意味での仕様変更」にであったことはほとんどないような気がします。
よく「仕様変更」とよんでいるものが実はただの不具合対応ではないかということです。

どういうことかと言うと、開発が進むにつれて開発当初は見えていなかった問題が見えてきたり、今の設計や実装では当初要求されていた「仕様」を満たせないことが発覚することがよくあります。
こんな場合、お客さんに対して「今の実装方法だとこんな制限がつきますよ」
という風に話しを持っていきます。

それを受けたお客さんや親会社が「それじゃぁ困るよ」ってな話しで設計方法の変更を要求してくればしめたものです。
「それは仕様変更ですので、開発費をいただきます」という方向へ話しを持っていけます。

でも、ふと思うんです。
こんな作業の進め方って、ほんとうに正しいのだろうか?と。
かと言いつつ、不具合と認めてしまうとお金がもらえないので、なかなか認められないのですが…

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

最近の開発期間

ソフト開発を長年やっていると、よく修羅場に出会います。開発スパンが長いプロジェクトの場合はある程度まったりできるのですが、短い場合は最初から悲惨な状況だったりします。

昔は1年~2年ぐらいの長いプロジェクトがありましたので結構楽ができていた気がするのですが、世の中はどんな感じなんでしょう?

私のまわりでは確実に短期間、短納期なプロジェクトが増えてきています。
できることなら修羅場な期間と同程度のまったり期間が欲しいのですが、なかなかそううまいこと世の中回ってくれません。 先のことを考えると頭が痛くなってくる次第です…

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

ブログ


どこまで続けられるかはわかりませんが、
ソフトウェア開発について、
日々思うことやら、技術論、開発論やら書いてみたいと思います。

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

トップページ | 2005年5月 »