4Hえんぴつ｜React＋TypeScriptでWeb RPGを作る
第7章「テストと品質管理」
第40回：Chromiumだけで終わらせない――WebKit・iPhone・A11yまで確認する
1. 今回のテーマ
前回は、PlaywrightのE2Eで、
画面操作が成功する
+
console warning/error 0
+
pageerror 0
まで確認する方法を扱いました。
しかし、Webアプリにはもう一つ大きな問題があります。
ブラウザが違えば、同じコードでも挙動が違うことがある
という点です。
今回のWeb RPGは、
スマートフォン縦持ちを主対象
にしています。
そのため、
Chromiumで動いた
だけでは、
公開品質として十分とは考えませんでした。
今回は、
Chromiumだけでなく、WebKit・iPhone・実機・レスポンシブ・A11yまで、どこまで確認したか
を整理します。
2. ChromiumでPASSしても安心しすぎない
Webアプリ開発では、Chrome系ブラウザで確認することが多くなります。
実際、PlaywrightでもChromiumは使いやすく、
Chromium
↓
E2E PASS
まで確認できれば、一見十分に思えます。
しかし、
Safari系はWebKitを使います。
ブラウザエンジンが違えば、
レイアウト
入力
フォーカス
スクロール
Storage
イベント処理
などで差が出る可能性があります。
3. ブラウザ差はUIだけとは限らない
ブラウザ差というと、
ボタンの見た目が少し違う
程度を想像しがちです。
しかし、実際には、
クリックできない
フォーカスが移らない
画面下部が重なる
スクロール位置がおかしい
保存後の再読み込みで挙動が違う
といった問題につながることもあります。
そのため、
ゲームとして最後まで操作できるか
をブラウザごとに確認します。
4. ChromiumとWebKitを分けて確認する
正式公開前の受入では、
Chromiumだけでなく、
WebKit
も確認対象にしました。
最終結果は、
Chromium
15 / 15 PASS
WebKit + iPhone emulation
7 / 7 PASS
です。
つまり、
「Chrome系で動いたからSafariもたぶん動く」
ではなく、
Safari系に近いエンジンでも確認する
ようにしました。
5. すべてのE2Eをそのまま複製する必要はない
Chromiumで15ケース、
WebKit＋iPhone emulationで7ケース、
という結果からも分かるように、
すべてのテストを完全に同じ数だけ流す必要はありません。
例えば、
Chromiumでは、
全体的な回帰確認
細かな機能確認
Recovery
future schema
まで広く見る。
一方でWebKitでは、
主要導線
スマートフォン操作
保存・再開
重要な画面遷移
を重点的に見る、
という分け方ができます。
6. ブラウザごとに「何を守るか」を決める
テストを増やす目的は、
数を揃えることではありません。
重要なのは、
このブラウザで壊れたら
ユーザーが困る機能は何か
です。
今回なら、
スマートフォン利用を前提にしているため、
タイトル
キャラクター作成
町
セーブ
ロード
再読み込み
といった主要操作を優先します。
7. iPhone emulationも使う
WebKitだけでは、
画面サイズや操作感まで、
スマートフォンに近い条件にはなりません。
そこで、
iPhone emulation
も使います。
以下は考え方を説明するため、実装を簡略化しています。
import { devices } from "@playwright/test";
const iphone = devices["iPhone 13"];
このように、
モバイル端末に近いviewportやuser agentで確認できます。
8. emulationは実機そのものではない
ただし、
ここは重要です。
iPhone emulationでPASSしても、
iPhone実機で完全に同じ
とは限りません。
emulationは、
画面サイズ
ブラウザ設定
入力条件
を近づけるためのものです。
実際のSafari、
実際のタッチ操作、
実際の端末UI、
OSとの組み合わせまでは完全には再現できません。
9. だから物理iPhone Safariでも確認する
正式公開前には、
物理iPhone Safari
でも主要操作を確認しています。
結果はPASSでした。
つまり、
Playwright WebKit
↓
iPhone emulation
↓
物理iPhone Safari
と、
確認の層を増やしています。
10. Androidは「実機確認済み」とは書かない
一方、Androidは、
Android Chrome Emulator
で確認しています。
正式資料でも、
Androidについては、
Android実機確認済み
とは扱っていません。
記録としては、
Android Chrome EmulatorでPASS
です。
テスト結果を書くときは、
実際に確認した範囲を正確に分けます。
11. 端末受入では画面幅も確認する
スマートフォン縦持ちでは、
小さい画面幅でレイアウトが崩れないことが重要です。
今回の受入では、
概ね、
320～430pxクラス
を意識しています。
例えば、
320px
375px
390px
412px
430px
のような幅で、
操作不能にならないか確認します。
12. 「表示できる」だけでは足りない
画面が収まっているように見えても、
実際には、
横スクロールが発生している
ことがあります。
スマートフォンでは、
意図しない横スクロールは操作性を大きく落とします。
そのため、
横overflowも確認します。
正式受入ではAndroid viewportで、
scrollWidth = 412
clientWidth = 412
となり、横overflowなしを確認しています。
13. 横overflowはE2Eでも確認できる
以下は考え方を説明するため、実装を簡略化しています。
const size = await page.evaluate(() => ({
scrollWidth: document.documentElement.scrollWidth,
clientWidth: document.documentElement.clientWidth,
}));
expect(size.scrollWidth).toBe(size.clientWidth);
これなら、
目視だけでは見落としやすい横overflowも、
自動で検出できます。
14. タップできる大きさも見る
スマートフォンでは、
PCのマウス操作とは違い、
指で操作します。
そのため、
ボタンやリンクが小さすぎると、
正確に押しづらくなります。
今回の受入では、
おおむね44px程度のタッチターゲット
を意識しています。
特に、
主要ボタン
保存
ロード
戻る
進む
といった操作は、
押しやすさを確認します。
15. 画面下部固定UIも注意する
スマートフォンでは、
画面下部に固定した操作領域を使うことがあります。
この場合、
ブラウザUI
外部バッジ
safe area
などとの干渉が起こることがあります。
実際、正式公開版では、
Netlifyが挿入するバッジが、
スマートフォン画面下部の固定操作領域右側へ重なる既知課題が確認されています。
16. 既知課題でも公開可能な場合がある
この問題は、
操作領域が完全に使えない
状態ではありませんでした。
実際には、
操作可能領域は残る
ゲーム進行に影響なし
保存・ロードに影響なし
console/pageerrorに影響なし
だったため、
Mediumの既知課題として継続管理し、
Blockerにはしませんでした。
17. A11yも公開前に確認する
スマートフォン対応と並行して、
アクセシビリティも確認します。
例えば、
フォーカスが見える
キーボードで移動できる
aria属性が適切
コントラストが確保されている
といった点です。
A11yは、
特定ユーザーだけのための追加対応ではなく、
UIが正しく作られているかを確認する品質指標
としても役立ちます。
18. roleベースのE2EとA11yは相性がよい
第38回では、
Playwrightで、
page.getByRole("button", { name: "つづきから" })
のような指定を紹介しました。
この書き方は、
DOMの位置ではなく、
UIの意味
を使っています。
つまり、
アクセシビリティツリーが適切に構成されていることが、
E2Eの安定性にもつながります。
19. aria-labelだけに頼らない
A11y対応で、
何でもaria-labelを付ければよいわけではありません。
可能なら、
button
label
heading
link
など、
HTML本来の意味を使います。
そのうえで、
必要な場合にaria属性を補います。
テストしやすいUIと、
利用しやすいUIは、
意外と近いところにあります。
20. キーボード操作も確認する
Webアプリでは、
マウスやタッチだけでなく、
キーボード操作も確認します。
例えば、
Tabでフォーカス移動できる
EnterやSpaceでボタン操作できる
フォーカスが見失われない
といった点です。
スマートフォン向けゲームでも、
Webアプリとして公開する以上、
基本的な操作性は確認しておく価値があります。
21. focusが見えることも大切
キーボード操作できても、
どこにフォーカスがあるか見えなければ、
操作しづらくなります。
そのため、
フォーカス可能
+
フォーカス位置が視覚的に分かる
まで確認します。
これは、
CSS変更の影響を受けやすい部分でもあります。
22. コントラストもUI品質の一部
ゲームUIでは、
雰囲気を優先して、
文字色と背景色が近くなりすぎることがあります。
しかし、
読みにくい
状態では、
ゲーム体験そのものが落ちます。
そのため、
文字、
ボタン、
状態表示、
などのコントラストも確認します。
23. ブラウザテストと実機確認は役割が違う
整理すると、
Playwrightでは、
同じ操作を
何度も
再現可能に確認する
のが得意です。
一方、実機確認では、
指で押した感覚
画面の見え方
スクロール感
端末UIとの干渉
など、
実際の利用感を確認できます。
どちらか一方だけではなく、
役割を分けます。
24. Android Emulatorも別の役割を持つ
Android Chrome Emulatorでは、
Android系Chromeで、
レイアウト
スクロール
タップ対象
画面幅
などを確認できます。
正式受入では、
Pixel 7 / Android 15 / API 35 / Chrome 124系の条件でPASSしています。
25. IndexedDBの保持も端末で確認する
スマートフォンでは、
画面が動くだけでなく、
保存が保持されること
も重要です。
正式公開URLで、
保存
↓
上書き
↓
ロード
↓
再読み込み
を行い、
IndexedDBが保持されることも確認しています。
26. UIテストと保存テストを分断しない
例えば、
スマホ表示OK
でも、
保存後に再読み込みすると消えるなら、
Web RPGとしては困ります。
そのため、
端末受入でも、
UI
+
Storage
+
Reload
を組み合わせて確認します。
27. direct URLもスマホで問題になり得る
SPAでは、
/town
/saves
/character
などへ直接アクセスした場合も考える必要があります。
正式公開版では、
直URLと再読み込みもproduction環境で確認済みです。
モバイルブラウザでも、
URL共有や再読み込みは普通に起こります。
28. ブラウザ差・端末差・公開環境差を分ける
確認対象を整理すると、
Chromium
↓
ブラウザ回帰
WebKit
↓
Safari系差異
iPhone emulation
↓
モバイル条件
物理iPhone Safari
↓
実機確認
Android Chrome Emulator
↓
Android系確認
production URL
↓
公開環境確認
となります。
一つのテストで全部を代用しません。
29. 「何台確認したか」だけを目標にしない
端末テストは、
数を増やそうと思えば、
際限なく増えます。
しかし、
すべての端末を確認することはできません。
そこで、
主要ブラウザエンジン
主要画面幅
主対象端末
実機1系統
エミュレーター
のように、
代表的な条件を選びます。
30. 主対象を明確にするとテスト範囲を決めやすい
今回のWeb RPGでは、
スマートフォン縦持ち
を主対象にしています。
そのため、
PCの超ワイド画面を細かく検証するより、
320～430px
縦持ち
タッチ操作
Safari
Chrome
を優先します。
製品の主対象が、
テストの優先順位にもつながります。
31. すべてPASSでなくても公開判断できる場合がある
品質管理では、
問題が1件でもあれば、
必ず公開禁止、
というわけではありません。
重要なのは、
Blocker
High
Medium
Low
のように、
影響度を判断することです。
今回も、
Netlifyバッジ重なりはMediumとして残りました。
32. Blocker / Highがないことを確認する
正式リリース判定では、
新規Blocker / Highは0件
でした。
つまり、
既知課題が0件だから公開したのではありません。
既知課題を把握し
影響を評価し
公開を妨げるものがない
ことを確認して公開しています。
33. 「動く」と「公開できる」は違う
開発環境で、
Chromiumを使って、
ゲームが遊べた。
これは重要です。
しかし、公開品質では、
さらに、
別ブラウザ
スマートフォン
実機
レスポンシブ
A11y
Storage
再読み込み
まで確認します。
この差が、
動くWebアプリから、公開できるWebアプリへ進む
部分だと考えています。
34. 正式公開版の端末受入結果
最終的には、
正式公開版で、
Chromium
15 / 15 PASS
WebKit + iPhone emulation
7 / 7 PASS
物理iPhone Safari
PASS
Android Chrome Emulator
PASS
横overflow
PASS
IndexedDB保持
PASS
まで確認しています。
35. 今回のポイント
今回のポイントは3つです。
- ChromiumだけでなくWebKitも使い、ブラウザエンジン差を確認する
- iPhone emulationだけで終わらせず、物理iPhone SafariやAndroid Emulatorも使ってスマートフォン条件を確認する
- レスポンシブだけでなく、横overflow・タッチターゲット・フォーカス・キーボード操作・aria・コントラスト・IndexedDB保持まで受入対象にする
整理すると、
Desktop Browser
↓
Chromium
Safari系
↓
WebKit
Mobile
↓
iPhone emulation
Real Device
↓
iPhone Safari
Android
↓
Chrome Emulator
UI Quality
↓
Responsive + A11y
Persistence
↓
IndexedDB + Reload
です。
今回の結論は、
「自分のブラウザで動いた」ではなく、「主対象の利用環境で遊び続けられる」ことを確認する
です。
36. 次回
次回から、
第8章「Web公開・互換性・永続化」
へ進みます。
第41回は、
IndexedDBを直接扱わない――Dexie.jsでセーブRepositoryを組む
です。
第33回では、
localStorage
↓
IndexedDB
への移行を扱いました。
次回はさらに、
React / Game Logic
↓
Repository
↓
Dexie.js
↓
IndexedDB
という形で、
IndexedDBの詳細をゲームロジックから切り離す設計
を掘り下げます。
この記事を最後まで読んでいただき、ありがとうございます。
「いいね」を押していただけるとうれしいです。これからの記事づくりの励みになります。
もし気に入っていただけましたら、フォローもよろしくお願いします。
前の記事
第39回 console warning／pageerrorもE2Eの失敗条件にする
次の記事
第41回 IndexedDBを直接扱わない――Dexie.jsでセーブRepositoryを組む
連載トップ
第0回 React＋TypeScriptで異世界RPGを作る――連載の目的と開発ロードマップ
note関連記事
スマートフォン実機で、縦持ちUIを確かめる #23
noteでは、スマートフォン縦持ちを主対象として、実機iPhone Safari、Android Chrome Emulator、画面幅、タッチ操作、A11yなどを確認した背景を制作側の視点から書いています。