SaaS や ASP のバグ管理も使われている

【CEDEC2006】「ファンタシースターユニバースの開発現場より～5年間の歩み～」
http://www.rbbtoday.com/news/20060831/33534.html

の記述の中に、「・・バグチェックはB-TRAQと、開発ツールの・・」とあった。
SaaS や ASP のバグ管理も、使われているのだ。と認識を改めました。

SaaS でのバグトラッキング

「インフォテリア、バグ・トピック追跡管理ソフトをSaaSで提供」
http://enterprise.watch.impress.co.jp/cda/software/2006/09/05/8582.html

とのこと。

Topika という名前らしい。
専用サイト: http://www.topika.jp/

価格（利用料）が高いため、多くの利用者が付くかは疑問に思う。
（無償のフリーエディションは除く）

（追記）クローズドの開発プロジェクト向けではなく、
不特定多数のユーザの方に情報を入れてもらう用に利用するならば、有用かもしれないと
考え直しました。

「コーディングは無理でも、バグ報告ならできる」

Linux のバグトラッキングに手順や、バグレポートをどう書くかというお話。
一般的なアプリケーションを作る場合にも役立つだろう。

「コーディングは無理でも、バグ報告ならできる」
http://japan.internet.com/linuxtoday/20060825/4.html

目次
1 バグ探し
2 責任の分散とバグの確認
3 バグレポートには何を書く？　
4 修正できないバグはどうする？　

"IT業界の勘違い"

非常に面白いエピソード(?)が多いので。メモ。

Dr.きたみりゅうじの“IT業界の勘違い”クリニック
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s01200.jsp?p=lwg

新しいバグトラッキングシステム「TestingStudio」

株式会社ウェブテクノロジは、スタジオソリューションズ有限会社の開発したバグトラッキングシステム「TestingStudio」（テスティングスタジオ）を、8月16日より販売いたします。とのこと。

「「TestingStudio」は、スタジオソリューションズ有限会社が開発した、ゲーム開発専用バグトラッキングシステムです。」とのことだ。

確かに、
・添付画像（スクリーンキャプチャなど）に直接コメントやマーキングができる「コメント機能」
はゲーム開発には便利かもしれない。（でも、通常のアプリケーション開発などにも便利だと思う。）

他の特徴は、別にゲーム開発専用でなくても、使える特徴な気がする。
別に「ゲーム開発専用」でなく、「ゲーム開発現場の声を盛り込んだ」でも良かったのではないだろうか？

（18:10 追記）
製品のホームページを見たら、
※ お申し込みは「ゲームタイトル開発メーカー様」もしくは「ゲームタイトルデバッグ会社様」に限らせていただきます。
とのこと。納得。

ハネムーンナンバー トラックナンバー

仕事上に出てきたが、初めて聞いた言葉
「ハネムーンナンバー」と「トラックナンバー」

調べたら、以下のURLを発見
http://akiyah.bglb.jp/wikies/Akiyah/HoneymoonNumber
ほぼ同じ意味だが、ハネムーンナンバーとトラックナンバーは
微妙に意味が違うらしい。

しかし、字面から連想しづらい意味だなー。

意味を重視すると
ハネムーンナンバー -> 限界越え到達欠席者平均人数
トラックナンバー -> 限界越え到達最小欠席者人数
ってところか？
（余計判りづらい？）

ソフトウェア・テスト PRESS Vol.3

ソフトウェア・テスト PRESS Vol.3 が発売されたそうです。

目次をみると
第3部　テスト自動化の支援を行うツール活用術
（3）バグトラッキングツール

とあるので、購入するのが楽しみです。
読んだ感想も書き込もうと思っています。

ソフトウェア・テスト PRESS Vol.3

• 作者:
• 出版社/メーカー: 技術評論社
• 発売日: 2006/07/22
• メディア: 大型本

「テスティング」を究める

CIOMagazine の WEB より。
http://www.ciojp.com/contents/?id=00003112;t=0
”テストの重要性に目覚めたCIOに贈る「9つの教訓」と「5つの質問」”

テストに関して、これはやるべし！という作業や項目の参考になると思う。
ただ、「5つの質問」の中の、
「Q4. 見つかった欠陥を評価し、その解決策に優先順位を付けるためのプロセスはあるか？」
で、優先度と重要度をまとめて「重大度」となっていた。
前の記事 にも書いたが、優先度と重要度は分けて考えないと、適切な優先順位付けは難しいと思う。

バグデータベース（バグトラッキングシステム）を使わせるために

ジョエル・オン・ソフトウェアから
http://japanese.joelonsoftware.com/Articles/GettingThingsDoneWhenYour.html

あなたのチームの誰もバグデータベースを使おうとしなかったとする。そんなことは気にしないことだ。あなた自身のバグトラッキングをただ続けていればいい。あなた自身のコードに見つかったバグを入力する。他の誰かが修正すべきバグを見つけたときは、そのバグをバグデータベースを使って彼らに割り当てる。あなたが良いバグトラッキングソフトウェアを持っているのなら、それは彼らにメールで通知するだろう。彼らがバグを直さないならメールを送り続けることができる。いつかは彼らもバグトラッキングの価値を理解し、それを使い始めるだろう。品質保証チームがバグをバグトラッキングシステムに入力してくれないのなら、他のチャンネルからのバグレポートを単に拒絶すればいい。3000回目にあなたが「ねえ、聞いて。そいつを直したいんだけど忘れそうだ。バグをこのシステムに入れておいてくれない?」と言ったとき、彼らはデータベースを使い始めるだろう。

ちょっと多い引用になってしまったが、本当にこのとおりだろう。
ツールは作業をより効率的に行うために使えばいいのであって、強制する必要はない。
しかし、大人数で行うと情報共有が必要だ。
さらに、人間は忘れる。バグを発見した本人ですら、どんなバグであったのか忘れる。
バグ管理はツールを使うことで、より効率的に、またソフトウェア自体の品質を上げられる。

ソフトウェア開発に係わっている人は、是非、上記のように実践して欲しい。

プログラマフレンドリーなバグトラッキングシステム16bugs

CNET Japan に
「Web 2.0の挑戦者：プログラマフレンドリーなバグトラッキングシステム16bugs」
http://japan.cnet.com/column/ehub/story/0,2000065901,20155548,00.htm
というのがあった。

先日の記事の「Backlog」と同じようなASPサービスである。
このような場合、やはり「利用するのに、このサービス会社を信用できるかどうか」が問題だと思う。
機密情報とも言えるバグ情報（プロジェクト情報）を、他社にデータを預けることになるわけだから。

また、記事とサイトを見たが、
残念ながら、どの部分が「プログラマフレンドリー」なのかが分からなかった。
どの部分なのだろう・・・