こんにちは！ショウです。
先日、マイグレーション観点でのテスト設計を行う機会があり、どのような観点を意識して設計するべきか調べていたところ、リプレイスという似た意味を持つ単語があることを知りました。よくよく調べてみると、似た意味の言葉ではありますが、それぞれのテスト観点には違いがあることが分かりました！
今回の記事では、そんなマイグレーションとリプレイスのテスト観点の違いについて、お話していきたいと思います。
マイグレーションとは？
まずはじめに、今回の記事を執筆するきっかけとなった「マイグレーション」について説明します。
マイグレーションとは移転・移行などの意味を持つ英単語で、IT分野ではソフトウェアやデータを別の環境に移行したり、新しい環境に切り替えたりすることを意味する言葉です。旧式やサポート切れとなる古いシステムから新たに作り直した新式の環境へ移行するレガシーマイグレーションの他に、異なる装置やソフトウェア、データ形式間でデータを移動するデータマイグレーションなど、マイグレーションと一口に言っても様々なものがあります。
マイグレーションを行う目的としては、最適な環境に移行することで運用コストの改善を図り、ソフトウェアやデータをより有効的に使用出来るようにすることです。
主なメリットとして、移行前と移行後の動作が一致しているという明確な合格条件があるので、認識齟齬が起きにくく、システムの品質を向上させやすい点です。
デメリットとしては、新環境に向けたデータやシステムの変換作業と平行して大幅な仕様変更を行うことが難しく、仕様変更を行わない前提で開発を進める必要がある点です。
リプレイスとは？
続いて、「リプレイス」 についてです。
リプレイスとは「交換・置換」などの意味を持つ英単語で、IT分野では古くなったり破損してしまったハードウェアやソフトウェアなどを新しい物や同等の機能を持った別のものに置き換えることを意味します。リプレイスを行う目的としては、システムを安定して運用することです。システムに不具合が無くても運用期間が長くなると下記のような劣化が起きます。
- 処理データ量が増え、ハードウェアのスペックが追いつかずに動作が重くなる
- 最新のソフトウェアやアップデートに対応出来ない
- 進化を続ける最新のコンピューターウィルスに対抗出来ない
この劣化によって、業務の非効率化や情報流出などのトラブルが発生するリスクがあるため、リプレイスが必要となります。
主なメリットは、ハードウェアやソフトウェアを新しいものに置き換えることにより処理能力が向上し、システム動作が安定することであり、デメリットはリプレイスの方式にもよりますが、コストがかかることや現行のシステムを継続する場合にリプレイス後に期待通りの動作にならない場合がある点です。
それぞれのテスト観点の違いとは？
では、マイグレーションとリプレイスそれぞれのテスト観点の違いを考えていきます。
現新比較テストについて
マイグレーションとリプレイスにおいてポイントとなるテスト観点のうちの一つとして、「現新比較テスト」が挙げられます。「現新比較テスト」とは、対象となるプロダクトの改修前後のデータや出力等を比較し、改修前後で問題となる現象や不具合が発生しないことを確認するテストとなります。
マイグレーションで有効なテスト観点
続いて、マイグレーションで有効となるテスト観点について考えてみましょう。
マイグレーションでは、システムの動作環境が新環境に変わるため、以下の3つの観点が必要となります。
1. システム全体の機能動作の現新比較
- テスト観点：新環境に移行した影響によって移行前に起きていなかった不具合や問題等が発生していないか
- テスト例：DB処理（新規テーブルや新規レコード）に着目した機能テスト
システム全体の単体機能に対する自動テスト
2. 性能（パフォーマンス）の現新比較
- テスト観点：新環境への移行に伴って性能が前環境と同等または向上しているか
- テスト例：DB処理（新規テーブルや新規レコード）に着目した性能テスト
新環境と前環境のシステムに着目した負荷テスト
3. 業務視点の要求を満たしているか
- テスト観点：新環境に移行して業務運用する際、業務視点の要求から外れていないか
- テスト例：検証環境での本番データを流し込んだ受け入れテスト・運用テスト
機能要求に関するユーザビリティテスト
以上がマイグレーションで有効なテスト観点と各理由となります。
リプレイスで有効なテスト観点
次に、リプレイスで有効となるテスト観点について解説します。
リプレイスでは、古くなったハードウェア・ソフトウェアの全部、または一部を新しいものに置き換えるため、以下の3つの観点が必要となります。
1. リプレイス部分及び影響範囲での機能動作の現新比較
- テスト観点：リプレイスを行ったことによる置換部分や関連する機能などで不具合や問題等が発生していないか
- テスト例：
- ハードウェアとのI/Fに着目した機能テスト
- システムテストでの全数テスト（難しい場合は単体テストでのDBテーブル値）
2. 性能（パフォーマンス）の現新比較
- テスト観点：リプレイス前後で比較を行い、新環境の性能が同等または向上しているか
- テスト例：
- ハードウェアとのI/Fに着目した性能テスト
- ハードウェア・ソフトウェアに着目した環境テスト
3. リプレイス部分以外への影響の確認
- テスト観点：リプレイスを行った箇所以外で想定外の影響・不具合や問題等が発生していないか
- テスト例：
- システム全体における確認テスト
- リプレイスで変更された部分に着目した自動テスト
それぞれのテスト観点の違い
最後にマイグレーションとリプレイスでのテスト観点の主な違いを解説します。それぞれの有効なテスト観点を比較すると、以下のように重視しているポイントがテスト観点にも現れていることが考えられます。
- マイグレーション：「システム全体の影響確認」を重視
- リプレイス：「リプレイス部分の影響確認」を重視※
※「リプレイス部分以外への影響の確認」の通り、リプレイス部分以外を確認しない訳ではありませんが、他2つの観点の方が重要度が高いように思われますので、上記のように記載しております。
補足
補足として、マイグレーションには「リライト」・「リホスト」・「リビルド」と呼ばれる、3つの手法もあります。
「リライト」とは、アプリケーションやプログラムのロジックは変更せずに、使用言語やプログラムを新しく書き換えて、新規プラットフォームにて動作するように移行する手法となります。「リホスト」とは、既存のシステムと同じ言語を使用して新規プラットフォームへ移行する方法となります。「リビルド」とは、改めてアーキテクチャやプログラム設計からやり直し、システムを再構築する方法です。
最後に
以上がマイグレーションとリプレイス、及びそれぞれの基本的なテスト観点の違いと補足になります。私が実際に担当したプロジェクトでは、「レガシーマイグレーション」の「リホスト」として既存システムに存在している膨大なデータを新システムの「検証環境」に移行してから1回目のテストを行い、完了後に新システムの「本番環境」へデータを移行してから、簡易的なテストを再度行うような形でテストを行いました。
私自身、マイグレーション観点でのテスト設計は初めてだったため、どういったポイントに着目し、またどのような観点でテスト設計を行えばよいのかが当初はイマイチ把握できませんでした。しかし、本記事で紹介したように該当のテストの概要や方法などを調査し、対象のシステムに対して有効な観点をまとめたうえで、「求められる要件（移行データの一致）を満たすための期待結果の記述方法」や「それぞれ必要なテスト観点は何か」ということを意識しながらテスト設計を行うことで、情報も整理でき、新たな視点で設計作業に臨むことができました。今後のテストでもこのような経験を活かしていきたいと思います！
今回はマイグレーションとリプレイスについて考えてきました。似た意味の言葉・手法ですが、開発の手法に合わせて考慮すべきリスクが異なることが分かりました。また、実際のプロジェクトの状態やテスト対象となるシステムによっても、テストで優先的に必要となる観点やテスト技法が異なる場合もあるかと思います。記事の執筆を通して、あらゆる状況やリスクに応じたテストを行う意識が必要だと改めて認識しました。本記事がマイグレーションやリプレイスを含め、あらゆるテストで少しでもお役に立てたら幸いです。
