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

ITエンジニアの業務効率を改善するために、現役エンジニアが実際の現場で利用している便利ツールを、10回にわたり紹介します。

[あきぴー，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 次のページへ

【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チケットを記入すれば、「ブロックしたテストケース」画面で一覧表示されるので便利である。