MS_MigrationTestEffort

移行時のテスト工程の工数

• 戻る（テスト、移行見積もりの概要）
  • 移行性評価作業の作業内容
  • 移行時のテスト工程の工数

概要

移行時のテスト工程の工数見積について。

詳細

• 前提条件下に於ける移行のテスト工数（ ≒ 手修正無しコンバージョン移行に必要な工数）は、
  新規の 50 ～ 40% であるので、移行案件の生産性は、最大で新規開発時の 2.5 倍程度と
  仮定できます（最大 ＝ 手修正無しのコンバージョン移行の場合）。

• リプレース案件等で「テスト工数を単体テスト工数を除いた結合テスト工数から」とした場合、
  生産効率は、新規の 3/10 の逆数倍（＝ 3.3 倍）となりますが、単体テストを端折る場合の
  リスク（仕様を理解させる工数確保も別途必要になってくる）があります。

移行メモ（前提条件の所在）: 元ページは「前提条件下」のリンク先を
「移行・マイグレーション」のアンカーとしていたが、
実際に工程別の工数比率（設計 : 開発 : テスト = 3 : 4 : 3）を定義しているのは
移行見積もりの概要であるため、そちらへ張り替えた。

補足（この比率の読み方）: 上記の「新規の 50 ～ 40%」「2.5 倍」は、
手修正無しのコンバージョン移行という最良ケースの上限値である。
実際の案件では手修正有りのコンバージョン移行や
ポーティング移行が混在するため、
対象モジュールを方式別に仕分けたうえで、方式ごとに係数を変えて積み上げる方が精度が高い。

既存のCLがある場合

移行メモ（用語）: 本ページの「CL」はチェック リスト（テスト項目書）を指す。

既存の CL がある場合は、更に工数を削減できます。

• 仮に、既存の CL を全て流用可能で CL 作成工数がテスト工数の 1/2 であった場合、
  更に倍（最大で新規開発時の 2.5 × 2 = 5 倍）の生産性が出ると仮定することもできますが、
  実際は引継ぎなどの関係で、それ程高い生産性は出ないと考えます。

• （新規開発時のメンバがそのまま集められる場合は、この限りで無い可能性はあります）

CLの作成と消化の工数

以下、移行に於けるテスト工程（CL の作成と消化）の工数について言及します。

CL作成工数

下記の理由により、移行時のテスト工程は、新規開発時のテスト工程の工数より多くかかると考えます。

• 新規開発時に CL を起す作業は、設計 / PG の工程で、作業者が母体の仕様を理解しているため高い生産性で遂行できる。

  ↓

• 移行時に CL を再作成するのは、作業者が母体の仕様を理解しながらになるので、生産性は、新規開発時より低くなる。

CL消化工数

下記の理由により、移行時、既存の CL を全て流用可能でも、それ程生産性は高くならないと考えます。

• 新規開発時に CL を消化する作業は、設計 / PG の工程で、作業者が母体の仕様を理解しているため高い生産性で遂行できる。

  ↓

• 移行時に CL を流用する場合、CL 消化作業の作業者は、ある程度母体の仕様を理解しながらテストを遂行する必要があるため、生産性は、新規開発時より低くなる。

補足（移行案件で効く自動化）: 移行では入出力が変わらないことが期待値になるため、
移行前後の画面・帳票・電文を突き合わせる**回帰テスト（差分比較）**と相性が良い。
CL の消化を人手で繰り返す代わりに、移行前環境で採取した期待値を
そのままアサーションに使えるので、上記の「母体理解のぶんだけ生産性が落ちる」問題を
部分的に回避できる。ただし、日時・採番・ソート順など環境依存の差分を
除外する前処理の作り込みが別途必要になる点は見積もりに含めておくこと。

参考

母体理解（リバースエンジニアリング）

• リエンジ用途でリバース・ツールを利用

---

Tags: 移行, テスト