脱Excel！ TestLinkでアジャイルにテストをする
図4－4－4の連携フローを見ると、実はバグ検証はかなり複雑なワークフローである。図4－4－4のように厳格に管理する理由は、結合テスト以降のバグの原因は要件漏れや設計漏れのような致命的な欠陥が多いからだ。 このときに使われる重要な成果物は障害報告票（例：Redmineチケット）である。例えば、筆者の場合、図4－4－4のフローを、障害報告票を使ったフローで説明すると下記の流れになる。 まず、障害報告票はテストケースが失敗したとき、障害報告票へバグの現象、バグが発生した機能、発生日時、担当者をテスターが記載する。障害報告票は、昔は決められた用紙かExcelだったが、最近ならバグ管理システム（BTS）へデジタル化して登録する。 バグが複雑でテスターが担当者を決定できないなどの場合は、管理者がいったん預かり、担当者を決定する。そのRedmineチケットは「新規」ステータスになる。 次に、担当者にアサ
レビューをTestLink＋Redmineで管理できないか？ - プログラマの思索
SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。 ＃後でまとめる。 SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。 上流工程の品質UPが鍵を握る。 そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。 しかし、設計レビューそのものの品質が低いように思う。 僕がいつもレビューで問題と思う点は、二つある。 一つは、レビューのプロセスがあいまいできちんと定義されていないこと。 例えば、レビューする際の観点がレビューアによってまちまちだったりする。 レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。 もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。 例えば、レビュー後修正の品質チェックが個人任せで、他人のチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
