Part 5-c. Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ編③


[アプリ互換性検証の効率化の手法② 見逃しリスクへの対応]

前述したように、非互換情報リスト(変更ログ)を使ってテストケースを絞り込むことで、アプリ互換性検証に関わる工数を大きく削減できますが、その一方で、非互換問題の見逃しによる障害リスクをゼロにすることは原理的にできません。このため、非互換障害が発生した場合の被害を最小化する施策も併せて取る必要があります。具体的な方法は主に以下の 2 つです。

  • A. 一部のアーリアダプタユーザに対する CB(または IP) の先行配信(リング配信)
    • 社員の一部に、先行して CB (または IP)を配布して実業務で使ってもらい、非互換障害が発生した場合には、すみやかに修正を行う。
  • B. ベンダーとの協業強化による迅速な障害修正対応フローの確立
    • 特にアプリを外注している場合には、速やかな修正ができる体制を整えてくおく。

image

それぞれについて補足説明すると、以下の通りです。

A. 一部のアーリアダプタユーザに対する CB(または IP) の先行配信

「アーリアダプタ」とは「早期利用ユーザ」のことで、いきなり全社員に一律で FU/SU を配信するのではなく、アーリアダプタから段階的に FU/SU を配信して利用者を増やしていくことにより、非互換問題発生時の問題を極小化しよう、というものになります。この考え方は Windows OS そのものの開発でも使われているもので、リング配信と呼ばれています。(ここでは話を簡単にするため、FU のリング配信についてのみ解説します。これがわかれば、SU についても似たような考え方ができるはずです。)

FU の実際のリング配信のやり方については、対象となるアプリの種類によって変わります。

  • コンシューマ向けサービスや ISV パッケージ製品・サービスの場合
    • この場合、ユーザ側は FU(November Update や Anniversary Update など)が CB としてリリースされると FU 適用を始めますので、それより先行して利用検証をしなければなりません。
    • このため、このケースでは Insider Preview を使って先行検証・リスクヘッジをすることになります。
  • 社内業務アプリの場合
    • この場合、大多数のユーザ(社員)が FU を使い始めるのは、FU が CBB 扱いになってからになります。
    • このため、一部のアーリーアダプタの社員に対して CB (としてリリースされた FU)を先行配信してしまい、社内業務アプリで不具合が出ないかどうかを確認してもらうことになります。

このように、アプリの種類によって、先行検証の時期や利用するビルドが異なるため、アプリの特性に合わせた、実地検証の期間の取り方などを事前に決定しておくことが必要です。下図はこれを概念的に示したものになりますが、こうした図をまとめておき、誰にどのように配信するのかを決めておくとよいでしょう。

image

実際の作業としては下記のような表を整理し、それぞれの配布リングにユーザや端末を割り当てていく形になります。(基本的には一度決めてしまえば、FU 配布の度にいちいち大きく変更するということはないはずです)

image illustration of rings

ちなみにマイクロソフトの社内においても似たような取り組みが行われており、先行して Windows OS や製品の最新中間版などを積極的に利用する社員を募集する形を採用しています。この仕組みは社内ではエリートプログラムと呼ばれており、新し物好きな社員が積極的に新しい OS を使う形になっています。(私自身も Surface Pro 4 を 2 台使っており、1 台は CB、もう 1 台は Insider Preview Fast Ring で利用しています。)(余談ですが、エリートプログラムは昔はドッグフードと呼ばれていたのですが、ドッグフードはちょっと名前的にイマイチですよねぇ;。犬の餌って;;)

B. ベンダーとの協業強化による迅速な障害修正対応フローの確立

また、併せて見直していただきたいのが、アーリーアダプタやエンドユーザから非互換障害が報告された際に、速やかに修正・再リリースが実施できる体制を整えておくことです。というのも、日本の大企業ではシステム開発を SI ベンダーや協力会社に外注していることが多く、不具合修正のやり取りに大きなオーバヘッドがかかるケースが少なくないためです。

  • 内製あるいはそれに準じる体制を取っていない場合
  • リリースに必要なテスト(デグレードテスト)が手作業で行われている場合
  • 修正作業の依頼や確認に、大量の書類による手続きが必要になっている場合

具体的な改善方法はケースバイケースであまりにも違いすぎると思いますのでここでは触れませんが、このような場合には、やり方の見直しや効率化を図り、速やかな障害修正対応フローを確立するようにしていただければと思います。

image

[アプリ互換性検証の効率化の手法③ テストのさらなる実施効率化]

ここまで、基本的なアプリ互換性検証の効率化として、① テストケースの絞り込み、② 見逃しリスクへの対応、という基本指針を示してきましたが、さらに以下のような手法を組み合わせていくことにより、互換性検証の作業をより効率化していくことができます。

  • A. 仮想環境の活用
    • 以下のような用途で仮想環境を活用すると、テストの作業効率が大幅に改善する
      • 次期 CBB クライアント環境を仮想環境として用意する(互換性検証用のテストマシンの準備工数が大きく削減される)
      • テスト用サーバ側環境を仮想環境として構築する(スナップショットを活用することで、テスト用サーバを容易に初期状態に巻き戻せるようになる)
  • B. 非有識者による再テストの実施
    • 互換性検証のたびに、業務や技術に詳しい SE やエンジニアが狩り出されると、現場業務に支障が出る
      • このため、非有識者でも再テストできるようにする
    • 具体的には、以下のような手法を組み合わせる
      • テスト環境の状態によって、テスト実施結果が変わらないようにテストケースを作成する(リピータブルにテストを設計する)
      • 有識者によるテストを、ビデオ録画などで記録しておき、これを活用する
  • C. UI テストの自動化
    • 仮想環境の利用や、リピータブルなテストケース設計が正しくできていると、UI テストの自動化も可能になる
      • UI テストの完全自動化はコストメリットが薄いが…
      • 互換性検証に必要な最小限のテストケースのみを自動化すると、メリットが非常に大きい
      • 累積パッチに対しても素早い互換性検証が可能になる他、迅速なデグレードテストなども可能になる
    • CUIT (Coded UI Test)ツールや 3rd party 製テストツールなどを用いて、UI 打鍵の自動化や適切な結果検証を行う
  • D. 全社的視点での互換性検証の最適化
    • 特に大企業の場合、全社的な目線で考えると、互換性検証を大きく最適化できる可能性がある
    • 主なポイントとしては…
      • テスト対象とする業務システムそのものの絞り込み(アーキテクチャが似ているシステム群は、そのうち一つだけを互換性検証の対象とする)
      • テストインフラの準備(個々の業務システムごとに用意するより、全社的に用意した方が安価)
      • 互換性検証テストチームの運営(専任チームを作った方が互換性検証のノウハウが貯まる)

こうしたテスト実施改善を進めていくためには、テストインフラの構築とテストツールの導入が欠かせません。というのも、残念ながら日本の開発現場の多くでは、未だ以下のような Excel テストが横行していると思います。

  • Excel 表を使ってテストケース一覧を書き出し、そこに〇×をつけていく。
  • 実施結果の証跡(エビデンス)を取るために、画面スナップショットを Excel の別シートにぺたぺたと貼り付けていく。

しかしこんなことをやっていてはテストの実施効率が全く上がりませんし、過去のテスト結果データを生かして次のテストに結び付けていくこともできません。近代的なテストインフラの構築とテストツールの導入により、テスト実施作業の効率化を推進していくべきでしょう。例えばマイクロソフト製品であれば、Hyper-V を用いた仮想化テスト環境(※ ラボ環境と呼ばれる)を構築したり、テスター向けツールである Microsoft Test Manager (MTM)を使うことでテスト実施作業の効率化を推進できますし、これらのツールや環境を、全社レベルで導入すると費用対効果もさらに高くなります。

image

image

[実際のテスト実施効率改善の難しさ]

ただその一方で、ここで述べた「仮想環境の活用」「非有識者による再テストの実施」「UI テストの自動化」などは、実際の現場で実施されていることは非常に少なく、また「全社視点での非互換検証の最適化」などは、大企業であれば大企業であるほどやりにくいケースが多いのも実際だと思います。

下図は、「開発時にやっておくべきこと」と「スムーズなアプリ互換性検証の実施に必要なこと」の対応関係を示したものですが、この図からわかるように、場当たり的な開発やテストが行われてきた場合、後付けでアプリ互換性検証の効率化を進めることには限界があります。このため、既存レガシーアプリに対しては、① テストケース割愛や、② 見逃しリスクへの対応、を行うのが精いっぱいであり、③ 更なるテストの実施効率化の施策が打てないことがよくあります。このような場合には、敢えて現行システムに対しては施策を打たず、次期大規模改修の際に『テストしやすいように』アプリ開発を行うようにしていくのが現実的でしょう。

image

このように、現実的な既存レガシー業務システムでは、「短期的な対応策」と「中長期的な対応策」とにわけて考えていくことが重要です。今一度、アプリ互換性検証の効率化の大方針を再掲しますが、直近でどこまでやるのか、長期的にはどこを目指すのか、その両方を考えるようにしてください。


Comments (0)

Skip to main content