脱Excel！ TestLinkでアジャイルにテストをする：エンジニアがお薦めする 現場で使えるツール10選（5）（4/6 ページ）

[あきぴー，＠IT]

【4−4−3】失敗した場合、BTSチケットと連携する

　テストに失敗した場合、失敗のステータスへ更新する。さらに、失敗したテストケースは必ずBTSチケットと連携させる。理由は、失敗したテストケースを使って、バグの再検証を行いたいからだ。

図4−4−3　失敗したテストケースとBTSチケットを連携した画面

　例えば、筆者は、TestLinkのテストケースとRedmineのチケットのステータスを下記のようにワークフロー管理している。ただし、筆者のチームでは、専門のテストチームがいないため、開発チームが兼任する形式にしている。

図4−4−4　TestLinkのバグ検証とRedmineのバグ修正の連携フロー

　図4−4−4の連携フローを見ると、実はバグ検証はかなり複雑なワークフローである。図4−4−4のように厳格に管理する理由は、結合テスト以降のバグの原因は要件漏れや設計漏れのような致命的な欠陥が多いからだ。

　このときに使われる重要な成果物は障害報告票（例：Redmineチケット）である。例えば、筆者の場合、図4−4−4のフローを、障害報告票を使ったフローで説明すると下記の流れになる。

　まず、障害報告票はテストケースが失敗したとき、障害報告票へバグの現象、バグが発生した機能、発生日時、担当者をテスターが記載する。障害報告票は、昔は決められた用紙かExcelだったが、最近ならバグ管理システム（BTS）へデジタル化して登録する。 バグが複雑でテスターが担当者を決定できないなどの場合は、管理者がいったん預かり、担当者を決定する。そのRedmineチケットは「新規」ステータスになる。

　次に、担当者にアサインされた設計者や開発者は、バグの原因だけでなく、類似したバグがほかに存在しないかも併せて調査する。このときのRedmineチケットは「担当」ステータスである。設計者や開発者は原因や類似調査の結果、修正方針をRedmineチケットへ追記していく。RedmineのようなBTSでは、チケットに上記内容が作業履歴として残るので、後の運用保守で役立つ。

　失敗の原因が判明して修正方針が定まり、開発者が修正を完了してコミットしたら、Redmineチケットを「解決」ステータスへ更新してテスターに送り返す。TestLinkでは、「失敗したテストケース」画面でRedmineチケットの状態もリアルタイムに表示するため、Redmineチケットが「解決」に表示されたら、テスターはすぐに再テストに取り掛かれる。

　最後に、テスターは、失敗したテストケースを再テストして「成功」ならば、Redmineチケットを「検証完了」にしてバグ検証が終わる。最後に、管理者が「検証完了」になったRedmineチケットを精査して「終了」ステータスで終わる。

　上記のワークフローをRedmineチケットの状態遷移図で説明すると、図4−4−5のようになる。

図4−4−5　バグ修正に対するRedmineチケットの状態遷移図

　Redmineの初期設定のワークフローは「新規→担当→解決→終了」しかなく、テスターがTestLinkで再テスト中の場合や、テスターが検証し終えた場合のステータスが存在しない。そのため筆者のチームからは、テスターがRedmineの初期設定のワークフローでは作業しにくいという意見があった。

　そこで筆者は、Redmineチケットのステータスに、テスターが修正したバグを再検証しているときは「検証中」、バグの検証を終了したときは「検証完了」を追加し、最後に管理者が必ずRedmineチケットを精査して「終了」ステータスへ変更する運用にしている。この運用によって、バグ修正のチケットをいま誰が作業中なのか、誰でも分かるようになった。

　テストケースとチケットのステータスを連携させて管理するワークフローがスムーズに流れるならば、バグ検証は必ず、開発者とテスターの2人で対応する作業（ペアプログラミング）になり、品質向上に役立つ利点がある。

【4−4−4】テストケースをブロックする

　テストに失敗した場合、依存するテストケースはブロックにしてテスト保留にする。

図4−4−6　テスト実行（ブロック）の画面

　「ブロック」は事前条件を満足できないためテスト不能な状態を表す（参考：ソフトウェアテスト標準用語集 日本語版Ver 1.3（PDF））。例えば、小売系Webシステムでカート画面のDB（データベース）更新のテストケースが失敗したら、注文フローのテストケースはすべてブロックになるだろう。

　TestLinkでテストするときはブロックを上手に使うことが重要だ。上記のように、「失敗」したテストケースのバグのうち、ブロックが発生して影響が大きいバグは「ブロッキングバグ」、ブロッキングバグが原因でテストできないテストケースのうち、ブロックしないで失敗にしたテストケースのバグは「みなしバグ」といわれるらしい。

　つまり、「みなしバグ」はテストしていないから失敗してないし、バグも出ていないが、テストしたらバグが出る可能性が高い。

　「ブロッキングバグ」は「みなしバグ」の発生源であり、「ブロッキングバグ」の滞留時間が長いほど再テスト工数は膨れ上がり、リリースが遅れることになる。

　「みなしバグ」のテストケースは一生懸命テストしたとしても、工数の無駄だ。実際の現場では、バグが多発すると「みなしバグ」の切り分けが難しく、プロジェクト後半というただでさえリソースが少ない状況で、工数を無駄に浪費してしまいがちだ。そのため、「みなしバグ」のテストケースは保留にして、「ブロッキングバグ」の修正を最優先する意思決定が必要になる。

　TestLinkでは、テストケースがテストスイート単位にまとめられているので、ブロックするテストケースが分かりやすい。従って、管理者はテスト結果をリアルタイムにモニタリングできるため、テスト結果を見ながらバグの状況に応じて、テストを中断したり、別のテストを指示したりすることができる。

　また、ブロックしたテスト実施結果の備考欄に発生元のテストケースIDや原因、Redmineチケットを記入すれば、「ブロックしたテストケース」画面で一覧表示されるので便利である。

【4−5】テスト実施の集計結果を表示する

　テスト実施結果は、下記の画面でリアルタイムに集計されて閲覧できる。

図4−5−1　全般的なテスト計画のメトリクスの画面

　筆者が重宝する画面は、「失敗したテストケース」「ブロックされたテストケース」「各テストケースの全バグ」画面である。

図4−5−2　失敗したテストケースの画面

図4−5−3　ブロックされたテストケースの画面

図4−5−4　各テストケースの全バグの画面

　「各テストケースの全バグ」画面は登録したRedmineチケットと失敗したテストケースの一覧を表示する。従って、テスターは、Redmineチケットのステータスが「解決」に表示されれば即、再テストを開始できる。

　さらに、画面の項目「オープン」は終了していないRedmineチケット数、「解決済み」は終了したRedmineチケット数を表示する。ゆえに、TestLinkをアジャイル開発に組み込んだ場合、「オープン」が「0」にならなければ、バグがまだ残っているのでリリースできない。

　管理者は、「各テストケースの全バグ」画面を見れば、テスト計画終了後にバグの総数を計算しやすくなる利点がある。

　プロジェクトにひも付く実施したテスト計画は下記で一覧できる。過去のテスト計画を振り返るときに役立つだろう。

図4−5−5　メトリクス・ダッシュボードの画面