バグ票を書くこともまたコミュニケーション - ワーストプラクティス収集に協力しませんか？
バグ票はバグを発見した人がそのバグを説明し、修正者（多くの場合は作成者）に修正してもらうことを報告するために記述する。バグの症状、再現方法、期待する動作を記述する。管理のために報告者、記入日、対応状況を記入する。
バグの発見と報告のために、修正者自身がバグ票を記入し、修正することもあるが、多くの場合、報告者と修正者は別の人になることが多い。バグ票の作成（起票）をコミュニケーションととらえることもできる。
ここ（本ブログの過去エントリ）にも書いたが、ソフトウェアレビューを含め、バグや欠陥の発見と指摘は別スキルだ。発見、再現が難しくクリティカルなバグを発見したとしても、それを伝える記述が適切でなければその価値も下がってしまう。
ソフトウェアテストシンポジウム2010関西の翌日に実施した勉強会の後の会食で、鈴木氏、近美氏と「バグ票にバグのことが書いてなくて、批判が書いてあるの見たことありますよね」とか同シンポジウム中でマイクロソフト長沢氏との雑談の中でも出てきた「バグピンポン」この話が盛り上がった。バグピンポンの詳細はここ（長沢氏のブログ）、ここ（本ブログの過去エントリ）にある。
あるべきバグ票の書き方を集めることもできるが悪い事例を集めてアンチパターンを抽出しようという話が盛り上がった。バグ票で開発担当やテスト担当を評価したり、修正方針がぶれたり等、様々な悪い事例がある。
匿名でそのような事例を集めるためにアンケートを作ってくださっているので、ご協力いただければと思う。集まった結果をまとめてどこかでフィードバックする予定だ。ここから入力できる。
ソフトウェアテストシンポジウム2011東京のライトニングトークスで、近美氏がこの活動を紹介くださっており、ここからスライドを見ることができる。また、鈴木氏が主著でSoftware Testing ManiaX vol. 4に寄稿している。