脱Excel！ TestLinkでアジャイルにテストをする
図4－4－4の連携フローを見ると、実はバグ検証はかなり複雑なワークフローである。図4－4－4のように厳格に管理する理由は、結合テスト以降のバグの原因は要件漏れや設計漏れのような致命的な欠陥が多いからだ。 このときに使われる重要な成果物は障害報告票（例：Redmineチケット）である。例えば、筆者の場合、図4－4－4のフローを、障害報告票を使ったフローで説明すると下記の流れになる。 まず、障害報告票はテストケースが失敗したとき、障害報告票へバグの現象、バグが発生した機能、発生日時、担当者をテスターが記載する。障害報告票は、昔は決められた用紙かExcelだったが、最近ならバグ管理システム（BTS）へデジタル化して登録する。 バグが複雑でテスターが担当者を決定できないなどの場合は、管理者がいったん預かり、担当者を決定する。そのRedmineチケットは「新規」ステータスになる。 次に、担当者にアサ
脱Excel！ TestLinkでアジャイルにテストをする
今回はTestLinkをテスト工程でどのように使うのか、テスト特有のマネジメント手法や概念を、TestLinkの機能に合わせて詳しく説明した。 【1】TestLinkの概要 TestLinkはPHPで作られたテスト管理Webシステムである。最新版はVer 1.8.3 （2009年6月）で、GPLで公開されている。WAMP、LAMP環境で動作する。 主な機能は下記である。 （参考：「きちんと学びたいテストエンジニアのためのTestLink入門」（gihyo.jp）、「簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト」） 数千から数万のテストケースを一括登録して貯蔵できるので、テストケースを再利用できる テストケースとは別に、テスト実施結果を履歴として残せる テスト実施結果をいろいろな観点で集計できる テストケースからバグ管理システムと連携してバグ修正
レビューをTestLink＋Redmineで管理できないか？ - プログラマの思索
SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。 ＃後でまとめる。 SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。 上流工程の品質UPが鍵を握る。 そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。 しかし、設計レビューそのものの品質が低いように思う。 僕がいつもレビューで問題と思う点は、二つある。 一つは、レビューのプロセスがあいまいできちんと定義されていないこと。 例えば、レビューする際の観点がレビューアによってまちまちだったりする。 レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。 もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。 例えば、レビュー後修正の品質チェックが個人任せで、他人のチ
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
