バグ票をめぐる攻防に関して

はてなブックマークには 100字という字数制限がある。ここで、字数を数えるとき、
　　全角＝１字、半角英数字＝0.5字
というふうに計算されていた。
　
ところが、2014年11月ごろ、はてなブックマークのデザインが変更され、それとともに、
字数の数え方も変わった。つまり、半角も全角も、ともに１字と数えられるようになった。
はてなブックマークの字数における、半角文字の扱いについて

たぶん、これ仕様変更でない気がするんだけど、もともと「仕様」が存在するかどうかにもよるかなぁと思う。

とある事例

テストエンジニアB：
（なんだよ。まだまだバグだらけじゃないか・・・。ユーザがそこまで気を使って操作してくれると思ってるのかよ・・。仕様書に詳細がなくても、これくらいの入力ミスへのエラーメッセージくらい用意しとけよ。「住所は半角ではなく、全角で入力してください」だと？半角だとわかってるなら入力し直させるんじゃなくて、そっちで全角に変換しろよな。電話番号の欄が9, 10, 11桁を許してるけど、市外局番を含めて9桁の番号なんて、もうなくなったんだよ。いつの情報を使ってるんだ・・。）
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？ | Think IT（シンクイット）

ユーザー視点にたったテストエンジニアが、この動作おかしいんじゃないの？とバグ票を起票するわけですけど・・・

プログラマA：
なんだよこのタイトルは！バグの報告じゃなくて、感想じゃないか。ユーザに入力し直してもらうのは、発注者が指定したフレームワークの機能を使っているからで、好きでやってるんじゃない。そんなこともわからずにテストしているのか。それにこれはバグじゃない。
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？ | Think IT（シンクイット）

プログラマー側はバグでないと言い張るんですね。

じゃぁ、仕様か？というと、何処にも明記されたものがないという現実を前に、堂々巡りが起こりますってかんじですかねぇ。

5点目は「直す気はありません」という部分です。プロジェクトの体制にもよりますが、プログラマ自身の方針や考えなのか、全体方針や顧客の方針として決まっているのかでは、今後取れる対策が異なります。まだ変更の余地があるのか、それとももう変更の余地はないのかをテストエンジニアに知らせておきます。もし変更の余地があり、時間やコスト等の条件が揃えば、修正できる可能性もあります。
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？ | Think IT（シンクイット）

仕様かどうかなんて、なかなかはっきり分かっているケースも意外と少ないのと、
また、誰が仕様に責任をもってるかとか不鮮明な部分もあり、
一般ユーザーからみると、へんな仕様のものが出来上がると・・・。

バグ票の正しい書き方？！

バグ票に書かれるコンテンツ

誰が、
いつ、
何をしようとして、
何が起きたか、
このあとどうするか

それだけ書けばいいのです。書き手であるあなたの“思い”を含めてはいけません。あくまでも、事実のみ、記録するのです。
バグ票も書けないのに一人前のエンジニアと思ってはいけない - 室長のひとりごち

「仕様不良」という存在もあるので、書き手の「思い」という理由で切り捨ててはダメな場合も多いです。
検査部門がある場合は、検査部門の「思い」も思いっきり反映された「バグ票」が起票されることが多いです。

そうでないと、品質が上がらないんですね。
何でもかんでも、「仕様通りです」とか「バグではありません」が通用してしまったら、
最終ユーザー視点から見た品質が、低くなってしまうんです。

「プログラマー」と「テスター（検査する人）」との力関係が、プログラマーよりだったら、品質確保できないんですね。

プログラムの品質を評価しているというよりかは、システムの品質、もしくはサービスの品質を評価しているので、その点が分からない「プログラマー」は、良いものをつくりたい？と思っている人たちからは邪魔だと思う。

バグ票って、具体的になにを書くものなんですか？

１：現象
２：技術的原因
３：動機的原因
４：対策
５：再発防止策
バグ票に盛り込むべき5つの項目

こういうものを書かせる場合が多いかと思います。
1.現象　-＞バグの具体的な内容。再現できる条件がかかれているほどよい
2.対策　-＞バグの修正内容

「技術的原因、動機的原因」の部分、特に動機的原因の部分が難しいと思います。
動機的原因をきちんとかける人は数少ないし、また動機的原因をきちんと分析できるマネージャーもすくないと思います。

プロじゃない人、素人まがいの開発をしてるプロの人は、こういうのは、知っておくほうがよいと思う。

たぶん、これ、プログラムとかITとか関係ない世界の、品質確保の概念がそのままITの方にも導入されていると考えたほうがよいかと思います。

このあたりは品質評価・管理の部分だと思うので、
プログラムが得意とか、マネージメントが得意とかいう分野とは微妙に違うとは思う。

バグ票を使った個人攻撃？！

2. イヤミや個人攻撃の記述
少し極端な例ではありますが、バグの症状として「これが単体テスト終了後のものか不思議ですが、電話番号の欄に漢字を入力しても登録できます。仕様通り、数字かハイフン以外は受け付けないようにしてください。仕様はそちらで書いたんですよね？」のような記述です。「これが単体テスト終了後のものか不思議ですが、」と「仕様はそちらで書いたんですよね？」はバグ修正には必要のない記述です。どうしても伝えたいのであれば、別の手段を考えます
「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは | Think IT（シンクイット）

こんなの気にしてたら、サラリーマンとして仕事していけないとはおもうけど。
事情がある場合でもない場合でも、スルーして、機械的にこなしてたらいいと思う。

まあ、個人攻撃しているとかいうけど、
逆にテスターとしていろいろやっていたら、発狂するような事例もでてくるよ。

まず、テストする前に、机上でソースを見直してくださいとか
現状では、テストするだけ無駄ですとか、テストできる品質にありませんとか。

あと、確かに仕様通りで、バグとしてはあげれないんだけど、
本当に、これでいいとは思えないんだけどというものもあるけど、
親切であげるべきか？　知らなかったことにすべきかも悩むことはあろうかと思う。

ほかの業種でも同じだとおもうけど、
自身の作業に、（根拠ない）自信とプライドがないと、やっていけない場合が多いと思う

プログラマーは、テスターを低く見るな・・・!!

プログラマーは、自分たちがＳＥ？とかから低くみられると怒りだすのに、
平気で、テスターを低く見てたりして、逆に驚く。

こっちの事情も分かれっていうのは、
あっちの事情も分かってやれにつながらないと
いつまでたっても、改善されないとおもう。