「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは
今回は、バグレポートの典型的な問題パターンを紹介します。ここで紹介するパターンは、バグ票ワーストプラクティス検討プロジェクトが収集中の「困った」バグレポートとして挙げられたものを参考にしています。プロジェクトは継続して困ったバグレポートを収集していますので、こちらのアンケートフォームから情報をお寄せください。 それでは、具体例を交えて問題のあるパターンの典型例を見てみましょう。 このバグレポートはいったい何を言いたいのか システムテストの開始直後 テストエンジニアA： このシステムでは、連携システムXからの日時のデータのタイムゾーンが他のサブシステムのタイムゾーンと違っていて、ここにバグがよく起こるんだよな・・。今回もそうかもしれないから、まずは、ここをテストしてみよう。 連携システムXを含めたテストの実施中 テストエンジニアA： ほら、やっぱり。連携システムXからの送信データが過去日付だ
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？
バグレポートに関する問題はどこでも起きている 本記事は、バグの修正依頼として作成されるバグ票（バグレポート）を対象としています。プログラマが自身でデバッグを一通り終えた後で、テストを専門とするテストエンジニアにそのプログラムをテストしてもらい、その際に検出されたバグを報告してもらうための文書がバグレポートです。独立した部門でテストを実施している会社では、このような形態とバグレポートによる修正依頼が一般的だと思います。 本連載は、テストエンジニア向けに、バグ修正のプロセスにおいて非常に重要でありながら、あまり注目されていないバグレポートのあるべき姿をさぐってみたいと思います。 早速ですが、プログラマとテストエンジニアの間でこのようなやりとりがあるのを見たことはありませんか？ テストエンジニアとプログラマの間でこんなやりとりが起こっていませんか？ 開発進捗会議にて プロジェクトリーダ： Aさん
[ThinkIT] チェンジビジョン、プロジェクト見える化ツール「TRICHORD 1.2」をリリース
チケット管理システム「Trac」と「JUDE」のマインドマップとの連携を実現 チェンジビジョンは2007年8月7日、プロジェクト見える化ツール「TRICHORD（トライコード）」の新バージョン1.2をリリースしたと発表した。 TRICHORDはプロジェクトの「今」をリアルに共有し、今何をすべきかをチーム内で把握することを目的としたプロジェクト見える化ツールである。今回のリリースでは、使いやすさの向上に加え、チケット管理ツール「Trac」とマインドマップが連携できるなど、チームでさらに活用できる機能を追加したという。TRICHORD 1.2の主な新機能は以下の通り。 チケット管理システム（Tracとの連携） TracのチケットをTRICHORDに取り込み、タスクカード形式で管理することで、TRICHORDをフロントエンドとしてタスクを表示・管理することができる。 タブ形式データの取り込みと貼
単体テスト仕様書＆報告書
客先からの注文書を受け、その内容を受注入力する 受注入力した内容は伝票に出力される。印刷される伝票は、注文請書と注文伝票の2枚で、注文請書は客先に提出され、注文伝票は営業事務でファイリングする 受注の際、在庫があれば在庫に、在庫がなければ発注残に引き当てる。在庫も発注残もない場合は、営業担当者に判断を仰ぎ、発注依頼にまわすことができる DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全体を通した業務の流れ、部署ごとの業務の役割、業務に使う画面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。 総合テストでは、実運用に近い状態でシステムが有効に機能することを確認します。本番同様のデータを使い、要求分析で定めた業務の手順にそってシステムを使って業務をまわします。うまく運用がまわるか、不都合はないかと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
