1．概要

計画、設計、ケース、手順書と続き、次は「テスト項目移管レポート」の説明になります。

ただ、この「テスト項目移管レポート」は現実的にほとんど作成されないドキュメントになります。
（私のこれまでの経験でも、現場で一度も見たことがありません…）

そのため、今回はIEEE829の「テスト項目移管レポート」の項目を説明しながら、なぜこのドキュメントが作成されないのか解説したいと思います。

2．IEEE829のテスト項目移管レポートについて

移管という言葉を辞書で引くと、以下のような説明になっています。

• 移管　⇒管理を他に移すこと。管轄をかえること

また、参考書等を確認するとテスト項目移管レポートは「テスト対象ソフトウェア構成品のテスト環境への移管報告書」と記載されていたり、「リリースノート」と記載されていたりします。

まとめると、テスト項目移管レポートは以下2つの意味を持つドキュメントとなります。

• テスト開始前にテストする対象のソフトウェア管理を、検証担当者に移管するためのドキュメント
• テスト完了後にテストした対象のソフトウェア管理を、保守担当者に移管するためのドキュメント

そのため、IEEE829のテスト項目移管レポートは以下の項目を記載することになっています。

• 移管レポート識別番号
• 移管項目　⇒ドキュメント名やモジュール名等を記載
• 場所　　　⇒保管先のフォルダ名やチケット番号等を記載
• 状態：移管される項目の状態を記述　⇒検証済みなのか開発中なのか、担当者が誰から誰に変わるのか記載
• 承認  

3．現場で使われていない理由

現場で「テスト項目移管レポート」が作成されない理由は、恐らく以下であると考えています。

• ①担当者が変わらないので移管する必要がない
• ②別のツールで管理しているので、ドキュメント化する必要がない

①担当者が変わらないので移管する必要がない

多くの場合、開発は開発、検証は検証と担当者がきちんと分けられ、責任者が決められています。そのため、開発工程が進む中で移管するものがほとんどなく、結果として作成する必要がなくなります。

②別のツールで管理しているので、ドキュメント化する必要がない

一番作成されない理由は、ここだと思っております。

ソフトウェア開発では、エクセル等で管理せずに、GitだったりRedmine等の管理ツールを利用する場合が多いと思います。

そのため、チケット等に移管担当者や移管項目が記載できるようになっているので、わざわざドキュメント化する必要がなくなります。

4．まとめ

「テスト項目移管レポート」の内容は、おおよそ開発フローのどこかに含まれているので、ドキュメント化する必要がないものでもあります。

ただ、開発⇒検証⇒保守と工程が変わるごとに責任者が変わることがあるので、責任者を
きちんとわかるようにしておくこと、が重要な要素となります。