「コーディングは無理でも、バグ報告ならできる」 [ソフトウェアテスト]
Linux のバグトラッキングに手順や、バグレポートをどう書くかというお話。
一般的なアプリケーションを作る場合にも役立つだろう。
「コーディングは無理でも、バグ報告ならできる」
http://japan.internet.com/linuxtoday/20060825/4.html
目次
1 バグ探し
2 責任の分散とバグの確認
3 バグレポートには何を書く?
4 修正できないバグはどうする?
バグを見つける立場と直す立場 [ソフトウェアテスト]
アメリカで働いている方のBlog
バグを見つける立場と直す立場
http://blog.livedoor.jp/livingseattle/archives/9064310.html
この方は両方の立場を経験されたようです。
バグ発見するチームとバグを修正するチームが独立しているとのことで、
どのようにバグ管理ツールを使ってバグ管理を行っているかに興味があります。
ソフトウェアテストシンポジウム 2006 in 大阪 [ソフトウェアテスト]
ソフトウェアテストシンポジウム 2006 in 大阪
http://www.jasst.jp/
4月3日から参加申し込みが受付開始されています。
東京とは違う内容もあるので、行ってみたいと思いますが、
やはり東京からちょっと遠い・・・
電気通信大学 西康晴氏に聞く、テスト技術の未来 [ソフトウェアテスト]
電気通信大学 西康晴氏に聞く、テスト技術の未来
http://www.atmarkit.co.jp/farc/rensai/bto01/bto01.html
2年前の記事だが、現状もあんまり変わっていないと思う。
是非読んでおきたい記事だ。
豆蔵 テスト・プロセスを新たに定義して品質支援を手厚くした、反復型ソフトウエア開発プロセスの新版「enThologyシステム開発プロセス(通称:豆蔵プロセス) V3.0」を発表 [ソフトウェアテスト]
テスト・プロセスを新たに定義して品質支援を手厚くした、反復型ソフトウエア開発プロセスの新版「enThologyシステム開発プロセス(通称:豆蔵プロセス) V3.0」を発表
http://itpro.nikkeibp.co.jp/article/NEWS/20060403/234426/
品質確保のためにテスト・プロセスを新たに定義するってのは、なんか微妙に感じる。
品質を確保するためには、上流工程からの品質の作りこみが必要で、
テストは、品質を確認・保証するものであると考えているからである。
テスト工程ではなく、テスト・プロセスと書かれているので、
要求開発なども含めた開発プロセス全体における品質確保のためのプロセスかもしれない。
どうなっているか確認する必要がありますね。
バグ登録・管理ツールを含む分散開発支援ツールの新版「SourceForge Enterprise Edition 4.3」 [ソフトウェアテスト]
バグ登録・管理ツールを含む
分散開発支援ツールの新版「SourceForge Enterprise Edition 4.3」が発売されたとのこと
http://itpro.nikkeibp.co.jp/article/NEWS/20060223/230491/
“寄せ書きツール”Wikiを統合し,プロジェクトのメンバーの情報共有をより容易にしたとのこと。
バグ情報は共有するべきですよね。
ソフトウェア開発支援システム Duepack [ソフトウェアテスト]
検索にて発見した。
ソフトウェア開発支援システム Duepack
http://www.j-techno.co.jp/softs/duepark/
この会社は他にも、ソフトウェア品質管理・分析ソフトも発売しているらしい。
いろいろなグラフが見れて、楽しそうではある。
本「若手SEのための ソフトウェアテストの常識」 [ソフトウェアテスト]
バグ管理図 [ソフトウェアテスト]
検索をしていたら、「バグ管理図」というものがあるのを見つけた。
初耳だったので、検索すると、どうやら情報処理技術者試験の問題文の中にこの言葉があるらしい。というか、この問題文のなか「だけで」使われているみたいである。
一般的な信頼度成長曲線(縦軸:バグ数・横軸:時間)ではなく、
縦軸:バグ検出数・未消化テスト項目数・未解決バグ数(項目数)
横軸:時間
のグラフらしい。
しかし、定義を書いたものは見つけられなかった。
一般的に「バグ管理図」というのだろうか?
知っている方がいらっしゃったら、是非コメントお願いします。