iOSアプリ開発体験記(6) - 気が済むまでテストする
はじめに
テストは得てして面倒なものです。ですが、手抜きをしてしまうと必ずアプリの精度やクオリティーに悪影響を与えてしまいますので、妥協せず面倒がらず、直感が「OK」を出すまでテストを続けましょう。
私の経験でも、「そんなたいした改修じゃないから、特定の箇所だけ動かせばよいだろう」と思っていましたが、いざ蓋を開けてみると、確かに改修箇所は正常に動きましたが、思いもしなかったところに影響が出て、別のViewでバグが発生していたことがあります。
それ以来、自分なりのテスト仕様を決めました。
テストのタイミング
バグを残したまま次へ進んで、結局すべて作り直しになる無駄を抑えるため、私は以下のタイミングでテストを行っていました。
- コーディング中
- コーディングが一段落した時やViewが完成した時点
- アプリが完成した時点
1と2はいわゆる単体テストと呼ばれるもので、直前の作業が想定通りに実装できているか確認するためのものです。
xcodeではprint関数を使って各種データをDebug Areaに表示することができますので、変更箇所のデータを出力してみて、想定している値が入っているかどうかを確認すると安心です。
問題は「3.アプリが完成した時点」でのテストです。
私はこの段階のテストを「徹底テスト」と読んでいました。
アプリに限らずWEBシステムでも、この段階のテストで手を抜いてしまうと、大抵痛い目に会います。
バグが出た後に上司から「テストの時に出なかった？」と聞かれ、「そこはテストしてませんでした」と応えようものなら、「テストの意味ないじゃん」となります。
そんなトラウマを抱えないように、少しでも気になる項目をデバッグシートにまとめて、たとえバグっている可能性がゼロに近くても、指差し確認と同じ原理で動作確認をすると、後々安心できます。
では、アプリが完成した想定で、私が実施したテストの流れを紹介します。
【準備編1】デバッグシート作成
効率的なテストの段取りを策定するため、デバッグシート記憶を作成します。
私はGoogleスプレッドシートで作りました。
これが正解がどうかはわかりませんが、ひとまず必要だと思う項目を書き出していきました。
記憶を頼りに思いつきで行き当たりばったりのテストをせずに、面倒でもデバッグシートを作成すると、テストの精度が向上しました。
また、作成の際は以下の２点に注意を払いました。
デバッグシートは第三者目線が大切
デバッグシートは第三者が作業する前提で作成することが望ましいです。
デバッグ項目は思いつくままに書くのではなく、ユーザー視点でアプリのダウンロードからの流れを想定して、その順序通りに項目を作っていくと、とても効率的なデバッグシートになります。
アプリ開発者は仕様を知っているので、必要なことが抜けてしまう可能性があります。
そこで、アプリのことを全く知らない人が、上から順番に操作していくと、アプリ全体の使い方を把握できる、という内容で作り上げるのが理想的です。
効率的なデバッグ手順を心がける
また、その第三者はデバッグシート全体を読み込んだ後で、改めてテストを始める、ということはしません。いきなりシートの上から順番に作業をします。
そのため、作業順も重要になります。
例えば、「ikitell Alarm」の場合は、見守り機能を利用する際にアカウント登録が必要ですが、アカウント登録処理のテストの後でアカウント削除処理を行い、その後アカウントのログイン状態のテストをしたりすると、「アカウント削除は最後でいいやん」となったりしますので、テストの効率も考えた手順を考えましょう。
【準備編2】テストするOSのバージョンを選定する
xcodeに付属するシミュレーターでは、必要に応じて複数のOSで起動することができます。
最新版のOSが出た後でも、数日後にはxcodeがアップデートされ、最新バージョンのシミュレーターを使用することができるようになります。
そこで、アプリが対象としている最低バージョンと、現在利用可能な最新バージョンの２つ、それ以外にも複数の画面解像度を持つシミュレーターでテストすることをおすすめします。
本記事執筆時点での最新はiOS18.3ですが、アプリのMinimum Deployment（ターゲットOSの最小バージョン）がiOS16.2なので、間をとって17.0と18.0を含めた4つのバージョンを対象としました。
また、iphone16とiPhone16Maxでは解像度（画面の面積）が異なりますので、同じアプリ画面でもレイアウトが変わる場合があります。
なるべくアプリの状態を把握するためにも、複数のOSや端末でテストする方が安心できます。
そこで、今回選定したテスト機は以下の通りです。
| 機種名 | OS | 種別 |
|---|---|---|
| iPhone 8 Plus | 16.2 | シミュレーター |
| iPhone 11 Pro Max | 17.5 | シミュレーター |
| iPhone 14 | 18.3 | 実機 |
| iPhone 15 | 18.0 | シミュレーター |
| iPhone 16 | 18.1 | シミュレーター |
【準備編３】テスト用アカウントの作成（必要なら）
「ikitell Alarm」ではWEB側の見守りシステムと連携するため、APIの認証用としてアカウントが必要になります。
このアカウントのステータスによって、アプリの表示が変わります。例えばアカウント登録直後でメールアドレスの認証が終わってない場合、見守り相手のメール認証が終わってない場合、お試し期間中などのステータスです。
このステータスをテストするために、都度アカウントを作っていたのでは効率が悪いので、あらかじめWEB側にアカウントを作成しておきます。
また認証方法はメールアドレスなので、通信できるメールアカウントも用意します。
「ikitell Alarm」の場合は合計５つのテストアカウントを用意して、それぞれのステータスを簡単にテストできるようにしました。
【実施編1】動作テストの進め方
ではテストフェーズに入ります。
ここではコーディング中の単体テストではなく、想定した要件がすべて実装できた後の、リリースに向けた動作テストを想定しています。
テストのルーティンは以下の通りです。
1. シミュレーターでのテスト
実機以外のOSバージョンについては、シミュレーターを使用します。
アプリ内課金を使用している場合、シミュレーターだと、app store connnectで作成できるsandbox用のアカウントにログインできなかったので、ローカルのconfigrationを使用してテストをします。
※アプリ内課金についての詳細は、別の記事で紹介予定です。
2. SandBoxを利用した実機テスト
シミュレーターでも大抵のテストはできるようですが、やはり実機で確認した方がよい場合もあります。
特にアプリ内課金を行う場合は、sandbox用のアカウントを作成することで、「App Store Connect API」が利用できます。
「App Store Connect API」はアプリでテストした課金情報をアップルのAPI経由で自分のWEBシステムに送信できますので、メンバーシップの取り扱いなどをテストする時には必須になります。
シミュレーターでもapple accountのログインダイアログが表示されるのですが、私のやり方がまずかったのか、なぜかsandbox用アカウントではログインできませんでした。
なんにせよ、やはり実機で自分のアプリが動くとテンション上がります。
※「Sandbox」や「App Store Connect API」についての詳細は、別の記事で紹介予定です。
【実施編2】バグを見つけた時のフィックス方法
デバッグシートにスクショ込みで書き込めば忘れることはないので、可能ならばそのまま最後までテスト続けます。
ただし、フィックスすることで以降のテストに影響が出る場合、もしくはそもそもバグのままだとテストできない場合は、一旦テストを止めてフィックス作業を行わなければなりません。
その際に注意しなければならないのは、フィックス後のテストをどうするかということです。
私はよほどの理由がない限り、デバッグシートの先頭に戻ってテストをやり直します。
理由はひとえに確信を得るためです。
バグフィックスの影響が他の箇所に影響を及ぼさないと１００％言い切れません。
実際、安易な変数型の変更やstateとbinding（変数の値を他画面で参照するかどうか）の設定変更が、他画面に影響を及ぼして、一見すると全然関係ない箇所に不具合が発生した、という事例があるためです。
その点、デバッグシートの項目はアプリの挙動について重要な点を押さえているので、すべての項目でパスすることは、アプリの完成度を高めます。
【実施編３】スクリーンショットのススメ
デバッグシートに従って動作テストを行いますが、その際に重要なのがスクリーンショットです。
個別のテストであれば都度スクショを取ることはしませんが、徹底テストの際は画面の変化がある度にスクショを取りました。
それもシミュレーターの種類別に。こんな↓具合に(笑
まぁ、やり過ぎ感が微塵もないわけでないのですが、ここで妥協して隠れバグが残ったという経験もありますので、iOSアプリ開発未経験者という自覚をもって、できることは時間が許す限り実行しました。
ただ、明らかな効能もありまして、テストで発見したバグをフィックスした後に再度スクショを撮って、バグ発生時点のスクショと見比べ、全体的な状況を確認することができます。
iOSはViewのコードの書き方によってレイアウトが崩れたりしてしまうことがありますので、意図しない変更が発生していないか確認する際はわかりやすかったです。
【実施編4】TEST FLIGHTでの動作テスト
sandboxでも一通りテストが完了した後は、アプリのソースをTEST FLIGHTに登録することで、通常のApple accountが利用できます。
また、TEST FLIGHTのテストユーザーとして既存のApple accountを登録すると、第三者の端末にリリース前のアプリをインストールすることができます。
私は友人に協力を仰いでTEST FLIGHTのテスター登録を行い、ヒアリングのためにアプリを使ってもらいました。
友人から得たフィードバックを元に、さらなる改善を行うことができました。
その点においても、TEST FLIGHTはとても有益なテスト環境です。
※TEST FLIGHTについての詳細は、別の記事で紹介予定です。
【完了編】徹底テストだからこそ得られる安心感
シミュレーター→実機→sandbox→TEST FLIGHTと、複数の環境でテストを行うことで、思いもかけなかった挙動を洗い出すことができ、アプリの完成度が飛躍的に上がりました。
また、この後に控える最大の関門「アプリ審査」においても、無駄なリジェクトを防ぐことができます。
私はアプリ審査に通るまでは常に不安に苛まれていました。
「本当にリリースできるのか？」「リリースできたとして、酷評されるんじゃないか？」など、明確な根拠がないにもかかわらず、マグマに吹き上がる泡のように、何かしらの不安が頭をよぎりました。
そこで、覚悟を決めて徹底的なテストを行うことで、その不安が少しは和らぎます。
妥協の産物として後悔がつきまとうよりは、多少面倒で時間がかかっても、自分が納得できる完成度を目指すことは悪いことではないと思います。
私の場合もテストを重ねることで新たな気づきを得た結果、アプリのブラッシュアップにつなげることができましたので、テストの重要性を再確認することができました。
以上です。
次回はいよいよ「アプリ審査」の経験をお話します。
Discussion