ゆうふの研究室
テスト更新日 2026.10.04

Reppalの実機テストケースを93件作った記録

食事・体重記録アプリ『Reppal』のクローズドテストに向けて、認証、食事記録、AI機能、体重記録、セキュリティなどの実機テストケースを93件に整理した方法と、作成中に見つけた改善点を紹介します。

食事・体重記録アプリ「Reppal」は、食事や体重の記録だけでなく、AIによる食事入力や栄養相談、グラフ、レシピなど、複数の機能を持つアプリです。

開発中は、自分が普段使う操作を中心に確認していました。しかし、Google Playでの公開を見据えると、正常に操作できることだけでは十分ではありません。

未入力、通信失敗、連続タップ、別ユーザーへの切り替えなど、普段とは異なる操作でも安全に利用できるか確認する必要があります。

そこで、クローズドテストに向けてReppalの実機テストケースを整理しました。最終的に作成したテストケースは、TC-001 から TC-093 までの93件です。

この記事では、テスト項目をどのように分けたのか、正常系以外に何を確認するのか、テストケースを作る途中で見つかった改善点をまとめます。

テストケースを作ろうと思った理由

開発者自身が動作確認をすると、無意識に「正しい操作」を選びやすくなります。

例えば、体重入力画面では、想定している範囲の数値を入力し、保存ボタンを一度だけ押します。通信が安定した開発端末を使用し、同じアカウントで確認することも多くなります。

一方、実際の利用環境では次のような操作が発生します。

  • 必須項目を入力せずに次へ進む
  • 数値欄へ0や負数を入力する
  • 保存ボタンを短時間に何度も押す
  • 通信中に機内モードへ切り替える
  • アプリをバックグラウンドへ移動する
  • 小さな画面でキーボードを表示する
  • ログアウト後に別のユーザーでログインする

こうした状況を思いついた順番で確認すると、テスト漏れや重複が生まれます。

そこで、機能、優先度、テストの種類、事前条件、操作手順、期待結果を1件ずつ記録する形にしました。

テストケースに記録した項目

各テストケースには、主に次の情報を持たせています。

テストID
機能分類
対象画面
テスト項目
優先度
テスト種別
対象OS
事前条件
操作手順
期待結果
実施状況
実際結果
判定
気になった部分

操作手順だけでなく、事前条件と期待結果を分けて書くことを意識しました。

「ログインを確認する」という項目だけでは、登録済みユーザーを使うのか、ログアウト済みなのか、成功後にどの画面を表示すべきなのかが分かりません。

条件と結果を具体的にすることで、別の端末や別の人が確認した場合でも、同じ観点で判定しやすくなります。

93件を機能ごとに分けた

テストケースは、画面の順番だけではなく、利用者がアプリを使う流れを意識して分類しました。

  • 認証と会員登録
  • オンボーディング
  • ホーム画面と栄養集計
  • 食事の手動登録、履歴、編集、削除
  • AIを使った食事入力
  • AIチャット
  • 体重記録と推移グラフ
  • レシピの検索、詳細、投稿、管理
  • プロフィール、目標、規約、ログアウト、退会
  • 課金状態と広告表示
  • ナビゲーション、通信、バックグラウンド復帰
  • ユーザーごとのデータ保護

大きな機能だけを確認するのではなく、機能と機能の境界も対象にしました。

例えば、食事を登録できたとしても、ホーム画面のカロリー・PFC集計、食事履歴、日付別表示が同じ内容に更新されなければ、アプリ全体としては正しく動いていません。

正常系だけでは不足する

テストケースには、正常系のほかに、異常系、境界値、状態遷移、通信異常、多重操作、セキュリティなどの観点を加えました。

未入力や不正な入力

会員登録では、正しい情報で登録できることに加えて、次のケースも用意しました。

  • 必須項目が空欄
  • メールアドレスの形式が不正
  • パスワードが7文字
  • 利用規約へ同意していない
  • 登録済みのメールアドレスを使用する

体重記録では、Reppalで扱う範囲を 20.0kg から 500.0kg とし、境界値の内側と外側を分けています。

20.0kg   保存できる
500.0kg  保存できる
19.9kg   保存できない
500.1kg  保存できない

通常の値だけを試すよりも、入力制限が正しく実装されているか判断しやすくなります。

連続タップと二重登録

スマートフォンでは、処理が始まったか分からず、利用者が保存ボタンをもう一度押すことがあります。

そのため、食事の手動登録とAI解析後の保存には、ボタンを素早く2回押すケースを追加しました。

期待する結果は、履歴に同じ食事が2件登録されることではなく、1件だけ登録されることです。

この観点は食事登録だけでなく、フィードバック送信や新規登録など、通信を伴うボタンにも必要だと感じました。

通信エラーから復帰できるか

Reppalでは、SupabaseやAI機能など外部サービスとの通信が発生します。

そこで、単に通信に成功することだけでなく、次の状態も確認対象にしました。

  • AIの応答がタイムアウトする
  • ホーム画面のAIフィードバック取得に失敗する
  • 機内モード中に操作する
  • 通信を戻したあとに再試行する
  • 無効な会話IDから復旧する

通信に失敗したとき、画面全体が停止したり、入力内容が失われたりしないことを期待結果としています。

AI機能では「回答が返る」以外も確認する

AIを使った食事入力では、自然文から食品名、量、単位、食事区分を取り出します。

具体的なテスト入力として、次の文章を用意しました。

朝にご飯150gと卵1個

期待する結果は、朝食として、ご飯150gと卵1個が確認画面へ渡されることです。

一方、「カレーを食べた」のように量や材料が曖昧な入力では、AIの推定結果をそのまま保存しないようにします。利用者が内容を確認し、必要に応じて量や単位を修正できることを確認します。

また、AIチャットでは、食事データを踏まえた回答だけでなく、医療診断や投薬指示を求められた際に断定的な回答をしないこともテスト項目へ含めました。

AI機能は通信に成功して文章が表示されればよいわけではありません。入力内容の確認、安全性、利用回数、失敗時の復帰まで含めて確認する必要があります。

データがほかのユーザーへ見えないことを確認する

個人データを扱うアプリでは、表示の崩れよりも優先して確認したい項目があります。

Reppalでは、ユーザーAとユーザーBを用意し、次のようなケースを作りました。

  1. ユーザーAで食事や体重を記録する
  2. ユーザーAからログアウトする
  3. ユーザーBでログインする
  4. ユーザーAの情報が表示されないことを確認する

履歴を開いたときだけでなく、ログイン直後に古いキャッシュが一瞬表示されないことも期待結果へ含めています。

課金状態についても同様です。ユーザーAが有料、ユーザーBが無料の場合、アカウントを切り替えたあとにAの有料状態がBへ引き継がれてはいけません。

テストケース作成中に見つかった改善点

テストを実施する前でも、操作手順と期待結果を書き出すことで、仕様や画面の問題に気づくことがありました。

表示名の文字数制限

新規会員登録について整理した際、表示名へ非常に長い文字列を入力すると登録できない可能性があることに気づきました。

データベース側で拒否されてからエラーを表示するよりも、入力画面で上限を示し、利用者が修正できるようにした方が分かりやすくなります。

身体情報の入力チェック位置

オンボーディングでは、身体情報を入力した次の画面で目標カロリーなどを計算します。

体重などへ不正な値を入力した場合、目標確認画面で初めてエラーにすると、利用者はひとつ前の画面へ戻らなければなりません。

そのため、身体情報を入力する画面で値を検証し、不正な状態では次へ進めない方が自然だと考えました。

キーボードによるボタンの隠れ

食事登録やレシピ投稿では、画面下部にも入力欄があります。

小さな端末でキーボードを開いたとき、保存ボタンや入力欄が隠れると操作できません。処理そのものが正しくても、実機では利用できない状態になります。

そのため、キーボード表示中に対象欄までスクロールできることを、独立したテスト項目にしました。

優先度を付けて確認する

93件を一度に同じ重さで確認すると、重要な不具合への対応が遅くなります。

そこで、利用不能やデータ保護に関わる項目を高優先度としました。

特に優先したいのは次の項目です。

  • 新規登録、ログイン、セッション維持
  • 食事と体重の保存、編集、削除
  • 栄養値と集計値の一致
  • ユーザー間のデータ分離
  • ログアウトと退会後のデータ保護
  • 多重操作による重複登録の防止
  • 通信失敗時にアプリが操作不能にならないこと

見た目の細かな違いも大切ですが、まずは記録したデータが正しく保存され、別の利用者へ表示されないことを優先します。

クローズドテストで確認したいこと

開発者の端末だけでは、すべての画面サイズや操作方法を確認できません。

クローズドテストでは、作成したテストケースによる確認に加えて、テスターの方から次の情報を集めたいと考えています。

  • インストールと初回起動ができたか
  • 新規登録とログインで迷わなかったか
  • 食事や体重を無理なく記録できたか
  • 文字やボタンが画面からはみ出していないか
  • 操作方法が分かりにくい画面はなかったか
  • エラーや強制終了が発生しなかったか

テストケースで仕様どおりの動作を確認し、自由な操作から使いにくさを見つける、この両方が必要だと思っています。

まとめ

Reppalの実機テストでは、93件のテストケースを作成しました。

ケースを整理したことで、正常な操作だけでなく、未入力、境界値、通信失敗、連続タップ、アカウント切り替えなど、見落としやすい状態も確認対象にできました。

また、テストケースを書く作業そのものから、表示名の文字数制限、身体情報を検証する画面、キーボード表示時の操作性といった改善点も見つかりました。

今後は、高優先度の項目からAndroid実機で確認し、発見した問題、修正内容、再テストの結果まで記録していく予定です。

テストは完成後に不具合を探すだけの作業ではなく、仕様や使い方を見直す機会にもなると感じています。