2023.7.10

カスタムAppで顧客側の受け入れテスト(UAT)を実施する際の注意点

ご相談に無償回答したお問い合わせの中から、シェアする価値のあるものをご紹介するケーススタディ企画。

今回は、VR関係の事業を営まれている非上場企業様からの問い合わせとなります。カスタムAppを顧客企業に提供する時のテスト設計についてのご相談。実は、ケースとしては前回と似ているのですが「テスト」にフォーカスがあたった話になります。

(研修資料より。自社製品のカスタマイズバージョンをカスタムAppとして他社提供するパターン)

以下が目次です。順番に見ていきましょう。

• 質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？
• 回答 : TestFlight内部テストを使います
• 解説1 : カスタムAppの受け入れテストに「王道」はない
• 解説2 : ADPのAdHocを受け入れテストに使うのは悪手
• 解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

 

質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？

Q. 当社はVR関連の自社ソリューション(アプリ)を開発・販売している企業です。個人向けにAppStore公開アプリの提供をする一方で、顧客企業に非公開のカスタマイズ版を開発し、当該顧客ADEP契約のInHouseで署名して提供してきました。

現在、顧客からADP(カスタムApp)への移行を依頼されており、あわせてテストの手順策定を求められていますが、カスタムAppでどのように顧客側の受け入れテスト(UAT : User Acceptance Test)を進めていくのかが分かりません。

ADEPの時はInHouse配布をすれば良かったので余り悩むことがなく、検証用アプリと本番用アプリを分けてビルド・配布して受け入れテストと実配布を行っていました。カスタムAppではどのように顧客の受け入れテストを設計すれば良いのでしょうか？

 

回答 : TestFlight内部テストを使います

A. 仰る通りADPではADEPのようにはいかないため、顧客の受け入れテスト(UAT)の要件に合ったテスト設計を適宜行う必要があります。具体的に回答するには、エンドユーザ企業様のテスト要件ヒアリングが必要です。が、今回それはできないとのことですので、残念ながら抽象的な回答となります。

カスタムAppでは、原則 TestFlight の内部テストを使います。ですので TestFlight をよく調査し、顧客要件にあったテストを設計して下さい。基本的には以上です。

調査用に設計のコツをキーワードでお知らせすると、内部グループをうまく使い分けること、ビルドのコンプライアンス設定方針を考えること、の2点でしょうか。

一点、テストの考え方について補足いたします。

検証用アプリと本番用アプリを分けるのは余り良い方法ではありません。時折見られる手法ですが、そもそも実行バイナリとして別物を使って動作確認するのは、本当に「検証」と言えるのでしょうか？

TestFlight は AppStore アプリのために用意されており、「同一バイナリ」をテスト用と本番用とに配信し分けて、真の「検証」と実稼働を共存できる仕組みになっています。カスタムApp は AppStore アプリですから、テストも TestFlight の考え方や仕様に合わせるのが最善です。

我流を通そうとすると必ずどこかで進めにくさや違和感・無駄が発生することになります。特別な事情がない限り原則アプリは1つとし、検証と本番の切り替えは実装側で吸収することをお勧めします。

 

解説1 : カスタムAppの受け入れテストに「王道」はない

テストをどう行うか？は、カスタムAppを開発・テスト・配布まで自社完結できないケースで必ずぶち当たる壁です。

ADEP(InHouse)では好きに配布すれば良かったので課題にならなかったのですが、ADP(カスタムApp)では Apple の用意するテストツールである TestFlight を使って、自社なりの、アプリなりの、「テスト設計」が必要になります。

(学習教材としてTestFlightの公式ドキュメントがある。これをよく読み実際に試すことが推奨される)

App Store Review ガイドラインのような指針は特に与えられていませんから、TestFlight を十分に理解した上で、個々事情を考慮したテストの段取りを作り上げないといけません。これを誤ると開発がうまく進まなかったり、開発体制をスケールさせにくくなったりします。

また TestFlight は App Store Connect と無縁ではいられません。App Store Connect の仕様変更に影響を受ける場合もありますので、「テスト手順を策定する」といったミッションは、意外に難しかったりします。

(WWDC2021の動画から。カスタムApp では App Store , App Store Connect, TestFlight の全てを理解する必要がある)

ソフトウェア開発全般に言える事ですが良いソフトウェアの影には必ず良いテスト設計が存在します。カスタムApp化には、エンドユーザ側にも開発会社側にも TestFlight の理解が必要不可欠です。

弊社では、カスタムApp移行を御支援する際に「この方法なら概ね大丈夫」というパターンをベースにして、企業ごとの要件で調整してご提案することが多いです。

 

解説2 : ADPのAdHocを受け入れテストに使うのは悪手

テストにAdHoc配布を使えば良いのでは？という意見も一部にはありますが、弊社では推奨していません。大手企業では特に、アプリの数やiOS端末の利用部門が増えてくると「詰んで」しまうからですね。どういうことか。

AdHoc配布では、配信先の端末数が100台までという上限があります。

特に大手企業あるあるですが、部門別に色んなアプリを作り、外部委託先が何社もあって、しかも多段の商流を組んでいて関係者が多い…なんて状況では、すぐ上限を振り切ります。開発会社が開発側のテスト用に勝手に大量登録してしまった…なんてケースもありますね。

そして、あるタイミングで突然「テスト用端末を追加できない」と報告があがり「詰む」ことになります。「どの端末を消すか調整しよう」と動いたところで残念ながら手遅れで、詰んだ状態はすぐには解消しません。削除した端末数分をすぐ追加登録できるわけではないからです。ADP契約の更新日まで待たなければなりません。

(リセット日とはADPの契約更新日。削除した端末個数分を新たな追加枠として使うにはリセット日を待つ必要がある)

将来、アプリの数も関係者も増えない、と断定できるなら TestFlight を使わず AdHoc をテスト用途に使うのもありかも知れません。

いつ上限を超えるかコントロールできず、開発側の勝手な登録を禁止することもできない AdHoc は、外部委託が基本の大手企業においては特にテスト用途には不向きです。むしろ、稼働台数が数十台程度という制約付きで InHouse 配布と同じ運用ができる配布手段と捉えたほうが良いでしょう。詳しく以下をご覧下さい。

• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

弊社では、開発を外部委託している企業様のADPでは、AdHoc配布をテスト用途に使わないことを推奨しています。

 

解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

今回のご相談では「検証用」アプリと「本番用」アプリとが別アプリだということでした。実は時々ありますが、弊社では余り推奨していません。

AppStore アプリにおいては、検証と本番をアプリ実体で分けるものではありません。Apple が用意する仕組みを読み解けば、Appleは検証と本番はアプリではなく配信ルートで分けるべき、と考えていることが分かります。

(WWDC2021の動画から。開発したアプリ(ipa)はテストならTestFlight、本番はAppStoreへ。行き先が異なるだけ)

同じアプリの用途違いでアプリの実体を複数作るべきではないのです。

• 検証用アプリと本番用アプリが別々に存在する
• 検証用配信ルートとしてTestFlightが、本番用配信ルートとしてAppStore+ABM+MDMが存在する

これをうまく使い分けられるでしょうか。検証用のアプリを本番用途の App Store → ABM → MDM と流す意味は何でしょう？ただでさえ複雑なカスタムApp配信に、自ら複雑さを加えることはないと考えます。

少し話は変わりますが、その昔、一般消費者向けの有償アプリの世界でも似たようなことがありました。「機能制限つきのFree版アプリ」と「フル機能の有償版アプリ」と、2つの別物アプリを開発会社は作り分けていたのです。弊社もやっていました。懐かしいですね。

(初期のAppStoreで弊社アプリを一覧した画面。フル機能の有償アプリ(右)と無償のLITE版(左)を別アプリで提供していた)

このような手法でアプリ数が無駄に増えることをAppleは良しとせず、1つのアプリで両役割を持たせられるよう In App Purchase (アプリ内課金) の仕組みを用意しました。それが2009年のこと。その後 AppStore からは、1つのアプリでFree版/有償版の2種類存在するケースは無くなっていきます。

実は業務用でも一緒です。特別な理由がない限りアプリは原則1つとし、実装で工夫をして同じアプリを用途ごとに使い分けられるようにするのをお勧めします。MDMからの本番用配信でのみアプリの特別な設定値を有効にする Managed App Configuration も活用できるでしょう。以下もご覧下さい。

• iOSDC JAPAN 2021で Managed App Configuration について講演します
• iOSDC2021で Managed App Configuration について講演しました -YouTubeで動画公開されました-

 

以上、カスタムAppにおけるユーザ受け入れテスト(UAT)についての質問＆回答と解説でした。

カスタムAppへの移行ではハマりどころが幾つかありますが、テストはその中でも比較的大きめのハマりどころです。App Store Connect、App Store、TestFlight に加え、ABM や MDM も理解していないと、業務用アプリのライフサイクル全体を設計できないからですね。関係者が多く、事前に手順書等を規定しなければならない大手企業の場合は結構大変です。

繰り返しになりますが、TestFlight をよく調査研究することが推奨されます。今後、カスタムAppの観点からのTestFlightについても解説していこうと思います。