AndroidアプリのQAで、毎回すべてを自動化する必要はありません。まず必要なのは、ビルド後に重要な画面が開くか、主要な操作パスが完了するか、期待した状態が画面に表示されるかを確認する短いスモークテストです。

この確認は、実際にはかなり視覚的です。ボタンが表示されているか、検索結果が読み込まれたか、翻訳されたラベルがはみ出していないか、権限ダイアログが次の操作を邪魔していないか。こうした状態は、コードのテストだけではなく、画面の証跡として確認したいことがあります。

まず画面を見える状態にする

AndroidのQAフローを作る前に、PCやMacから画面を見て操作できる状態が必要です。たとえば Android画面をPCとMacにミラーリングできれば、QA担当者は現在の画面状態を確認し、どの手順をFlow化すべきか判断しやすくなります。

自動化は、画面が見えない状態でいきなり始めるよりも、観察できる状態から作ったほうが運用しやすくなります。

スモークテストは小さく設計する

最初のFlowは短いほうが安定します。例として、次のようなチェックがあります。

これは複雑なテストではありません。しかし、ビルド、言語、端末、エミュレータが増えると、手作業では時間を使います。

AI Android automation tool としてのLaiCai Flowは、タップ、スワイプ、入力、待機、スクリーンショット、OCR、画像チェック、条件分岐、ログ、停止条件を組み合わせられます。

ポイントは、AIに全部任せることではありません。AIやLLMはFlowのドラフト作成を助けることができますが、最終的には人がGraph Viewでノードを確認し、待機時間を調整し、OCRの対象を見直し、どこで止めるべきかを決めます。

悪い自動化は、画面がすでに間違っていてもクリックを続けます。そうすると、失敗の原因が見えにくくなります。

QA向けのFlowでは、次のような場合に止まるべきです。

停止は失敗ではなく、レビューしやすい証拠を残すための品質ゲートです。

エミュレータは、Flowの作成や待機時間の調整、ビルドごとの繰り返し確認に向いています。一方で、Android実機はメーカーUI、権限、通知、カメラ、性能、画面サイズ、ハードウェア差分を確認するために重要です。

実務では、まずエミュレータでFlowを安定させ、次に代表的なAndroid端末で確認するのが現実的です。

LaiCai Flowは、Unit Test、Instrumentation Test、UI Automator、Appium、CIを置き換えるものではありません。むしろ、まだ人が手動で確認している短い画面パスを、証跡つきで繰り返しやすくするレイヤーです。

設定手順は LaiCai Flow guide にまとめています。元記事は AI Android QA Smoke Tests with LaiCai Flow です。

自動化するのは、繰り返しのAndroid操作です。判断、許可、レビュー、最終決定は人が持つ。この線引きが、QA向けFlowを安全に使うための基本です。