アプリのテストは、完成後に画面を触って不具合を探す工程ではありません。
要件を受け入れ条件へ変え、コード、連携、端末、業務、公開の各段階で確認方法を用意する活動です。
失敗したときに「どの条件を満たさなかったか」まで戻れるよう、要件IDとテスト結果を結び付けてください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| テストの層 | 主な対象 | 見つけたい問題 |
|---|---|---|
| 単体 | 関数、クラス、計算規則 | 境界値、条件分岐、計算誤り |
| 結合 | API、DB、外部サービス | 入出力、認証、再試行、整合性 |
| システム | アプリ全体と端末 | 主要動線、権限、性能、復旧 |
| 受け入れ | 要件と実際の業務 | 目的を満たすか |
| リリース | 署名、設定、ストア情報 | 本番構成と配布の不備 |
テストの種類を対象と失敗範囲で使い分ける
単体テストは、小さな処理を速く繰り返し確認するのに向きます。
結合テストは、正しい関数同士でも発生する認証、通信、データ形式の食い違いを確認します。
| 種類 | 入力の例 | 期待結果 | 失敗時の主な調査先 |
|---|---|---|---|
| 単体 | 金額0円、上限値 | 計算規則どおり | 関数と条件分岐 |
| API結合 | 正常、期限切れトークン | 状態とエラー形式 | 認証と通信 |
| 画面動線 | 登録から完了まで | 遷移と保存が一致 | UI、状態、DB |
| 障害試験 | 通信断、外部API停止 | 再試行と案内 | 例外処理と運用 |
| 受け入れ | 実際の業務シナリオ | 合意した成果 | 要件と設計 |
公開工程にもテストがある点に注意してください。
Androidの公開準備は、リリース設定、署名、テスト、配布を分けて扱っています。
App Review Guidelinesも、クラッシュや不完全な機能を含む提出を避けるための一次情報です。
V字モデルとして整理する場合は、要件と受け入れ、全体設計とシステム試験、詳細設計と結合、実装と単体を対応させます。
名称を覚えるより、各設計判断に確認方法があるかを見てください。
要件から実行結果までを六段階でつなぐ
テストケースを画面一覧から量産せず、要件の理由とリスクから作ります。
- 要件ごとに正常、境界、例外、権限違いを洗い出す
- 単体、結合、システム、受け入れの担当範囲を決める
- 前提、入力、操作、期待結果、証跡を書く
- 自動化する反復試験と人が見る操作品質を分ける
- 失敗を重要度と再現性で分類し、修正後に再試験する
- リリース構成で主要動線とロールバック手順を確認する
安全性のテストは最後の診断だけでは足りません。
NIST Secure Software Development Frameworkは、安全な開発の準備、成果物の保護、安全な生成、脆弱性対応を工程全体の活動として扱っています。
テストデータには個人情報を無断で複製せず、架空データか適切に匿名化したデータを使います。
本番と異なるデータでも、文字数、件数、権限、例外の特徴は再現してください。
四権限と五操作の組み合わせを数える計算例
次の数字は、権限試験の漏れを見つけるための仮定です。
未ログイン、一般利用者、管理者、停止中利用者の4権限で、閲覧、登録、変更、削除、出力の5操作を確認するとします。
基本の組み合わせは4権限×5操作で20件です。
許可される操作だけでなく、拒否される操作でデータが変わらないことも期待結果へ含めてください。
| 権限 | 操作数 | 基本ケース |
|---|---|---|
| 未ログイン | 5 | 5 |
| 一般利用者 | 5 | 5 |
| 管理者 | 5 | 5 |
| 停止中利用者 | 5 | 5 |
| 合計 | 4権限×5操作 | 20 |
すべてを同じ深さで試すのではなく、個人情報の閲覧、削除、出力を高リスクとして優先します。
低リスクの表示差と高リスクの権限漏れを、単純なケース数だけで同列に扱わないことが重要です。
自動テストと人によるレビューの役割を分ける
自動テストは、同じ入力と期待結果を繰り返す処理に向くでしょう。
計算、変換、API契約、回帰確認を自動化し、文言の分かりやすさや操作の迷いは人が観察します。
コードレビューはテストの代わりではありませんが、変更意図、影響範囲、足りないケースを実行前に見つけられます。
GitHubのPull Requestレビュー資料で、コメント、承認、変更要求を差分へ結び付ける仕組みを確認できます。
レビュー依頼には、変更理由、確認方法、実行結果、未確認事項、画面変更の画像を添えます。
「動作確認済み」だけでなく、どの端末とデータで何を確認したかを書いてください。
不具合を件数ではなく利用者への影響で扱う
不具合票には、再現手順、期待結果、実際の結果、環境、頻度、証跡を入れます。
重要度は、個人情報、決済、データ消失、主要機能停止、回避手段の有無から判断します。
安全性の確認項目を作る際は、OWASP ASVSのような検証要件を参照し、認証、セッション、入力、アクセス制御など該当部分をテストへ変換してください。
モバイル固有の確認にはOWASP MASVSを使い、保存、暗号、通信、プラットフォーム連携などの範囲を照合します。
修正後は失敗したケースだけでなく、その周辺と過去の主要動線も再試験します。
直した一行が別機能へ与える影響を、変更差分と設計の依存関係から選びます。
アプリ開発のテスト工程でよくある質問
テストはいつから始めますか？
要件定義で受け入れ条件を作る時点から始まります。
実装前に確認方法を決めると、測定できない「速い」「使いやすい」といった曖昧な条件を具体化できます。
自動テストだけで公開できますか？
計算や回帰には有効ですが、実機権限、通知、カメラ、操作の迷い、ストア情報まで完全には代替しません。
公開前はAndroidの公式公開準備のようなOS別手順も照合し、署名済みのリリース構成で確認します。
テスト担当者は開発者と別にしますか？
独立した視点は役立ちますが、人数が少なくても設計者、実装者、利用者役の観点を分けられます。
重要な変更は差分レビューを通し、作った本人以外が主要ケースを再現してください。
要件と失敗結果を結び付けてテストを終える
テスト完了は、未実行件数がゼロになったことだけでは判断できません。
高リスクの条件が検証され、残る不具合の影響と回避策が合意され、リリース構成を戻せることが必要です。
- 単体、結合、システム、受け入れ、リリースで異なる確認対象
- 要件IDから前提、入力、操作、期待結果、証跡までの追跡
- ケース数より優先する個人情報、決済、データ消失、主要機能停止
- 自動化へ向く反復判定と人が観察する操作品質の分担
安全性の高いケースをさらに具体化するには、アプリ開発のセキュリティ対策で脅威、権限、保存、通信をテスト項目へ落とせます。
