テスト計画・テストの分担と体制（その２）不具合の一次切り分けとデバッグ
不具合の一時切り分けはテストリーダか設計・実装リーダ
ソフトのテスト計画書では、一次切り分けとデバッグと最終確認の分担についても明記しておきます。見つかったバグのデバッグを担当するチームを決めるのが一時切り分けで、担当するチームがデバッグを行い、デバッグした結果の効果の最終確認をどのチームが行うかを明確にしておきましょう。
テストで見つけた不具合は一次切り分けで担当を決める
テストで検出された不具合はソフトのバグの場合もありますがバグでない場合もあるので、まず最初に不具合の一時切り分けが必要です。一時切り分けとは、以下のようにおおまかな原因による不具合の分類ですね。
- ソースコードの間違い （設計書どおにソフトが動作していない明確なソフトバグ）
- 設計書の間違い （設計書の間違いでソフトが要求仕様を満たさないソフトバグ）
- テスト手順間違い（テスト手順書の書いてあるテストの手順の間違い）
- 判定条件間違い （テスト手順書に書いてある判定条件の間違い）
- テスト環境不備 （テスト環境に問題があって間違ったテスト結果になった）
- テスト実施間違い（テストの手順書どおりにテストを実施していなかった）
１と２はソフトバグなのでそれぞれコーダや設計者にソフトをデバッグしてもらう必要があり、不具合を設計・実装チームに伝える必用があります。3と4はソフトには問題はなくテスト設計の間違いなので、テストチーム内のテスト設計者に伝えてテスト設計を修正してもらう必要があります。５はテスト機材やテスト用のデータの間違いなどテストの環境の問題なので、テストチームの中のテスト環境準備する担当者に伝えて環境を修正してもらう必要があります。６はテスト担当者に伝えて再テストですね。
このような不具合の一時切り分けで、その不具合に対して次に誰が何の作業をするのかが決まるので、一時切り分けはテスト作業やデバッグの作業効率に影響します。一時切り分けを正しく行うには、テスト対象のソフトやテスト全体についての知識とある程度の経験が要るので、多くの場合はテストチームのリーダが担当する事が多いのですが、場合によっては設計・実装チームのリーダが担当する事もあります。いずれにしても、一時切り分けの分担と実施の時期は、計画書に明確に書いておきましょう。
ソフトバグなら設計・実装チームがデバッグを担当
不具合が実装間違いや設計間違いのようなソフトバグなら、デバッグ作業を行うのは設計・実装チームの担当者です。一方で、不具合がテスト設計の間違いやテスト環境の問題なら、そんの対応はテストチームの担当者です。これらの修正作業の分担は、実際の担当者が居る１チームになるのは明白なので、わざわざテスト計画書に書いておかなくても良い場合が多いです。
ただし、大規模なソフト開発の場合などで、設計・実装チームの中が初版の設計・実装を担当するチームと、テストチームが発見したバグの修正を行うチームとに分かれている場合などは、デバッグを設計・実装チームの中のどのサブチームが分担するのかを、具体的に書いておいたほうが良い場合もあります。
修正効果の確認は実装者の分担だがテスト担当者が手伝う事もある
個々のソフトバグのデバッグ作業は ①原因の調査 ②ソースコードの修正 ③修正効果の確認 の３段階で進みます。多くの場合、実装担当者が①～③を担当するのですが、バグの件数が多く実装担当者の手が足りない時などには、③の作業をテスト担当者が手伝う事もあります。実装担当者には①と②の作業に専念してもらう事で、少しでもデバッグ効率を良くしたいような場合の分担方法です。
作業の効率から言うと、デバッグの内容を一番よく知っている実装担当者が①～③を担当するのが良いのですが、バグの件数が多くリリース時期が迫っている時などには、作業効率よりもデバッグ時間の短縮を優先したい場合もって、③をテストチームで分担する事もあります。
このような状況は、ソフト開発プロジェクトの状況にもよるので、テストの計画段階では分担をどうするのかを決め難いのですが、③テストチームで分担する場合が在るならば、そのような可能性がある事をテスト計画に書いておくほうが良いです。
デバッグを終えたソースコードの登録は設計・実装チームの誰が行うのか
デバッグによる修正効果が確認できたら、デバッグを終えたソースコードをマスターツリーに登録する作業が次に必要です。これは当然設計・実装チームが分担するのですが、実装担当者が自らマスターツリーへの登録を行う場合のあれば、マスターツリーの操作を専門に行う担当者がいて、その人がマスターツリーへの登録を行う場合もあります。
実装担当者がマスターツリーへの登録行うのが一般的なのですが、ソフト開発が大規模でマスターツリーへの誤登録による影響が大きい場合などは、マスターツリーの操作を専門に行う担当者を置いく事で、操作のミスや不正な手順によるマスターツリーへの間違った登録のリスクを少しでも減らす体制をとる事もあります。いずれにしても、マスターツリーへのソースコードの登録は重要な作業なので、テスト計画書にも分担を書いておくのが良いです。
修正完了の最終確認はテストチームの分担
デバッグの結果がマスターツリーに登録され、そのマスターツリーから修正版のソフト（実行イメージのソフト）が生成されたら、不具合が修正されている事の確認のためのテストが行われます。 これは、最初に不具合を発見したのと同じテスト項目をもう一度実施する事で、今後は正しいテスト結果が得られる事の確認なので、当然テストチームが分担します。
テストの分担と体制が掛けたら次はテストの管理です
テスト作業はテストチームと設計・実装チームとが連携して作業を進める場面が多いので、テスト計画書にはブレークダウンした作業のそれぞれについて、分担を書いておくのが良いです。 分担を書き出したらその次は、テスト計画書にテストの管理の方法を書き込みます。