「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは
今回は、バグレポートの典型的な問題パターンを紹介します。ここで紹介するパターンは、バグ票ワーストプラクティス検討プロジェクトが収集中の「困った」バグレポートとして挙げられたものを参考にしています。プロジェクトは継続して困ったバグレポートを収集していますので、こちらのアンケートフォームから情報をお寄せください。 それでは、具体例を交えて問題のあるパターンの典型例を見てみましょう。 このバグレポートはいったい何を言いたいのか システムテストの開始直後 テストエンジニアA： このシステムでは、連携システムXからの日時のデータのタイムゾーンが他のサブシステムのタイムゾーンと違っていて、ここにバグがよく起こるんだよな・・。今回もそうかもしれないから、まずは、ここをテストしてみよう。 連携システムXを含めたテストの実施中 テストエンジニアA： ほら、やっぱり。連携システムXからの送信データが過去日付だ
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？
バグレポートに関する問題はどこでも起きている 本記事は、バグの修正依頼として作成されるバグ票（バグレポート）を対象としています。プログラマが自身でデバッグを一通り終えた後で、テストを専門とするテストエンジニアにそのプログラムをテストしてもらい、その際に検出されたバグを報告してもらうための文書がバグレポートです。独立した部門でテストを実施している会社では、このような形態とバグレポートによる修正依頼が一般的だと思います。 本連載は、テストエンジニア向けに、バグ修正のプロセスにおいて非常に重要でありながら、あまり注目されていないバグレポートのあるべき姿をさぐってみたいと思います。 早速ですが、プログラマとテストエンジニアの間でこのようなやりとりがあるのを見たことはありませんか？ テストエンジニアとプログラマの間でこんなやりとりが起こっていませんか？ 開発進捗会議にて プロジェクトリーダ： Aさん
[Think IT] 第3回：チケットドリブン開発でバグ削減！ (1/3)
【バグ管理の作法】Trac徹底活用！ 第3回：チケットドリブン開発でバグ削減！ 著者：masuidrive 公開日：2007/12/20（木） チケットが中心の開発手法 「第2回：なぜTracの導入に失敗するのか？」では、Tracの中心機能となるチケットについて説明し、導入のポイントをまとめた。今回はチケットを開発の中心位置に持ってくる「チケットドリブン開発」について解説していこう。 チケットドリブン開発とは チケットドリブン開発（チケット駆動開発：Ticket Driven Development）とは、チケットを書いてから開発を行うという手法だ。読者の皆さんもご存じのようにテストドリブン開発（Test Driven Development）をもじったものである。このチケットドリブン開発は「まちゅダイアリー（http://www.machu.jp/diary/）」のまちゅ氏がITpro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
