PS4のビデオキャプチャをUSBフラッシュメモリと母艦PC経由で他の部屋から見るまでにやったこと
PlayStation 4 (厳密にはPlayStation 4 Pro)で撮ったビデオキャプチャを
- USBフラッシュメモリにコピーして
- (PS4と同じ部屋にある)Mac miniに移して
- (同一ネットワーク上にある)MacBook Airで見る方法
のメモ
PlayStation 4 ドラゴンクエスト ロト エディション
- 出版社/メーカー: ソニー・インタラクティブエンタテインメント
- 発売日: 2017/07/29
- メディア: Video Game
- この商品を含むブログ (1件) を見る
PlayStation®4 Pro KINGDOM HEARTS III LIMITED EDITION【Amazon.co.jp限定】 オリジナルPS4用テーマ (Amazon) 配信
- 出版社/メーカー: ソニー・インタラクティブエンタテインメント
- 発売日: 2019/01/25
- メディア: Video Game
- この商品を含むブログを見る
TL;DR
本当に長いから本当に読まなくていい
回りくどい手順を踏んでいる理由
1TBとかの外付けHDDを買ってくれば一発で済むことをわざわざ回りくどい手順を踏んでいるのには以下のような理由があります。
- キャプチャデータを保存するつもりだった2TBの外付けHDDを拡張ストレージとしてフォーマットしてしまったため
- 手元にあってフォーマットしてもいいUSBストレージの中で最も容量が大きいものが64GBだったため
- プレイ中の画面をほぼずっとキャプチャしていて無駄な箇所が多くMac miniで動画編集をしたいため
- 家族がPS4を使っている間もキャプチャ動画を再生したいため
外付けHDDの拡張ストレージ化
1)については完全に人間は愚か1案件なんですけど、PS4に外付けHDDを繋いで拡張ストレージとしてフォーマットしてしまうとキャプチャやセーブデータの保存先に指定できません。
USBストレージ機器を拡張ストレージとしてフォーマットすることで、アプリケーションをインストールできます。また、PS4™の本体ストレージからアプリケーションを移動することもできます。
どっちみちキャプチャの保存先をUSBストレージに指定することはできないっぽいので、外付けHDDを使う場合でもファイルをコピーするステップは必要になるようです。
拡張ストレージにした外付けHDDをDLしたアプリケーションデータの保存先に指定したら「Marvel's Spider-Man」をはじめとしたやたら容量の大きい洋ゲーの分がごっそり空いたのでヨシ!
USB 2.0だとファイル転送がすごく遅い(気がする)
2)について、今回実際に使っているUSBフラッシュメモリはこれです。
シリコンパワー USB2.0 Ultima U05 Series 64GB スライド式 永久保証 ピンク SP064GBUF2U05V1H
- 出版社/メーカー: シリコンパワー
- 発売日: 2013/11/15
- メディア: Personal Computers
- この商品を含むブログを見る
上で挙げた公式ドキュメントの「拡張ストレージとして使えるUSBストレージ機器」の仕様に「USB 3.0」が含まれていてこれはUSB 2.0なんですけど、20GBくらいの動画データをコピーするのに一晩かかったりするのは多分そのせいだと思います。
PS Vitaでリモートプレイすればいいのでは?
PS4ストレージ内のキャプチャをリモートで確認するだけならPS VitaのPS4リンクを使えばいいんですけど2、2019年2月14日(これを書いている時点で明日)「キャサリン・フルボディ」が発売されるのでPS4を家族がほぼ占有するため、その間は何もできなくなります。
「ドラゴンクエストビルダーズ2 破壊神シドーとからっぽの島」の話
「ドラゴンクエストビルダーズ2 破壊神シドーとからっぽの島」の2周目をプレイしているんですけど、このゲーム、主人公と少年シドーの冒険が本編と見せかけて実質その後の終わらないものづくりのためのチュートリアルなので、PSアカウントひとつにつきセーブデータひとつという周回しづらい作りになっています。シナリオが面白いゲームはメインストーリーを周回したいタイプなので周回する度にPSアカウントを増やすのもあれなので過去の各島をやり直す機能を追加してほしい。アイテムを持ち込めない・持ち帰れない縛りで。
「DQB2」は前作に比べて戦闘の難易度が下がり3ブロックメイクの自由度が一気に向上していて、ストーリーも友情努力のち鬱そして勝利なので、アクション戦闘が苦手でSwitchかPS4を持っている人は是非体験版をやってください。前作や「DQ2」をやった人は絶対楽しいはず。
USBストレージ機器にPS4本体ストレージ上のキャプチャファイルをコピーする方法
- USBストレージ機器をPS4に接続する
- 拡張ストレージとしてフォーマットせずに、[設定] > [ストレージ] > [本体ストレージ管理] > [キャプチャー] を開く
- ゲームタイトル・ファイル種類・個別ファイルを選択して操作する(複数選択可能)
ファイルコピー中はPS4で遊べないので注意
USBフラッシュメモリのフォーマット
上の3)でUSBストレージ機器を使用できないというエラーが出た場合は以下の設定でフォーマットすると大丈夫だった
Mac本体上のディレクトリを同一ネットワーク内から参照する方法
USBフラッシュメモリからMac miniにキャプチャデータをコピーするとき、パブリックディレクトリ(~/Public
)をコピー先にすると手間が省ける
- [システム環境設定] > [共有] を開く
- [ファイル共有] にチェックを入れる
- [オプション] で共有設定を変更する
今回はSMBを使った
備考
ていうかPS Vitaでリモートプレイしながらビデオキャプチャ撮れたら最高じゃん……と思ってたら撮れるっぽい。
ドラゴンクエストビルダーズ2 破壊神シドーとからっぽの島 【Amazon.co.jp限定】 「紋章ブロック・太陽」のレシピを先行入手できるダウンロードコード 配信 - PS4
- 出版社/メーカー: スクウェア・エニックス
- 発売日: 2018/12/20
- メディア: Video Game
- この商品を含むブログを見る
ドラゴンクエストビルダーズ2 破壊神シドーとからっぽの島 【Amazon.co.jp限定】 「紋章ブロック・太陽」のレシピを先行入手できるダウンロードコード 配信 - Switch
- 出版社/メーカー: スクウェア・エニックス
- 発売日: 2018/12/20
- メディア: Video Game
- この商品を含むブログ (1件) を見る
Android端末に表示されているWebコンテンツをGoogle Chromeの開発者ツールでデバッグする方法
数ヶ月に一回くらい必要になるけどその度にやり方を忘れるので書く
NOTE: このエントリはHow to inspect web contents shown on Android devices with Google Chrome(en)を和訳したものです
試行環境
- macOS: macOS 10.14.2
- Google Chrome (mac): 71.0.3578.98 (64bit)
- Android OS: Android 8.0.0
- Google Chrome (Android): 72.0.3626.76
あらかじめやっておくこと
- [設定]> [システム]> [開発者]オプションで[USBデバッグ]を有効にする (Android)
- Windows PCの場合はGoogle USB Driverをインストールする
手順
- USBケーブルでAndroid端末をPCに接続する
- Android端末に「USBデバッグ接続」の通知が表示されることを確認する
- PCのブラウザでchrome://inspect/#devicesを開く
スクリーンショット
参考
- Android の Chrome で開発者ツールを使う方法 - Qiita
- 【CSS3】サイズがわからない画像の縦横比を維持したまま表示する方法【object-fit】 - Qiita
- Get Started with Remote Debugging Android Devices | Tools for Web Developers | Google Developers
- CSS object-fit Property
- 作者: 川口和也,喜多啓介,野田陽平,手島拓也,片山真也
- 出版社/メーカー: 技術評論社
- 発売日: 2018/09/22
- メディア: Kindle版
- この商品を含むブログを見る
TestRailに既存のテストケースをインポートするときのファイル仕様(CSV,XML)
TestRailに既存のテストケースをインポートするときのファイル仕様についてのメモ。なおテスト仕様書はGoogleスプレッドシートやExcelに記載してあるものとする。
公式サイトおよびドキュメント
- Test Case Management & Test Management Software Tool - TestRail
- Importing test cases and sections (Excel/CSV) [TestRail Documentation]
tl;dr
テスト管理ツールを使ってみたかったのでTestRailを1ヶ月間試してみることにした。ツール選択時の参考にした記事は以下。
とりあえず既存のテスト仕様書(約200ケース)をインポートしていつもより多めに(テストを)回してみようとしたらインポート用のファイルの作成に2〜3時間かかった。正直ド●ゴンクエストビ●ダーズ2で手が滑って山の上から溶岩を流して山ひとつと結構な面積の海が蒸発させてそのあと6時間かけて整地したときの気分に近いものがあった。
前提
やりたいこと
Googleスプレッドシートで作成された画像1のような構造のテスト仕様書を画像2のように階層化されたテストケースとしてインポートする。
インポート元となるテスト仕様書の構造
テスト仕様書(画像1)は部分抜粋なのでわかりにくいが、このテスト仕様書はリリースver.で確認するテストケースと、デバッグver.で確認するテストケースが両方記載されている。そのためview、flow / phaseの上にもうひとつセクション階層がある。
テスト仕様書の各テストケースが属するセクション階層は以下のようになる。
- UI/UX Tests with Production build > Onboarding
- UI/UX Tests with Production build > Onboarding > Installation
CSVファイルでインポートする場合
CSVファイルを使ったインポートは簡単だがサブセクションが多いテスト仕様書には向いていないっぽい。
CSVファイルをインポートするとき、例えば画像3のCSVファイルであればTitle、Section Depth、Section Hierarchyをそのまま指定したいが(画像4)、TestRailのCSVインポート機能はSectionまでしかサポートしていない(画像5)。
もちろん同じテストケースをTestRailに手動登録してからCSVをエクスポートしてみると、セクション階層に関するいずれの項目も出力されている。
なので次の画像6のようにサブセクションを持たないテスト仕様書をインポートするならそれほどファイル整形に労力はかからないはず。
XMLファイルでインポートする場合
どうしてもサブセクションを維持したい場合XMLでインポートすることになる。TestRailのインポート/エクスポートXML仕様は公式ドキュメントに記載されているため詳細はそちらを参照されたい。
以下は実際にインポートに用いたXMLファイルの一部の抜粋。
<section> <name>UI/UX Tests with Production build</name> <description>To check UI/UX with Production build by tester hands</description> <sections> <section> <name>Onboarding</name> <cases> <case> <title>app name on the toast is correct</title> </case> </cases> <sections> <section> <name>Installation</name> <cases> <case> <title>can open "License" view</title> </case> <case> <title>can open "Privacy Pollicy" view</title> </case> </cases> </section> </sections> </section> ... </sections> ... </section>
今回はSection Depthの異なるテストケースが混在していることがややこしくなる原因だった気がする。
今回はこのネストしまくったファイルをGASを使わずにSpreadcheet関数のみで生成するのはちょっとしんどいな〜と思ったのでサブセクションを全て手動登録してからXMLをエクスポート→テストケースを追記して再度インポートという手段を取った。
まとめ
サブセクションがないテスト仕様書はCSVでどーんとインポートすれば良さそう。大項目〜小項目までサブセクションで再現したい場合はXMLを生成してインポートしたら良さそう。
もちろんどちらの方法でもPriorityやEstimate、Stepsを含むカスタムフィールドも追加できるのでついでに追加するといいかもしれない。
ソフトウェアテスト教科書 JSTQB Foundation 第3版
- 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
- 出版社/メーカー: 翔泳社
- 発売日: 2011/11/12
- メディア: 単行本(ソフトカバー)
- 購入: 5人 クリック: 85回
- この商品を含むブログ (12件) を見る
【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践
- 作者: 石原一宏,田中英和,田中真史
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2012/01/28
- メディア: 単行本
- 購入: 2人 クリック: 12回
- この商品を含むブログ (9件) を見る
AndroidアプリQAテスターのおしごと(2018年)
今週(1月23日)でDrivemode Inc.の東京オフィスで働き始めてちょうど1年になるので、現状の整理として現在やっている業務と今後やっていきたいことについて書きます。
tl;dr
今の仕事をするようになってから「QAテスターの仕事とはなんぞや」と読んだり考えたりしたんですけど、とりあえず「QAエンジニア」や「テストエンジニア」「テスター」の業務範囲や待遇は会社やチームによって全く違うということを実感しました。
例えばテストコードを書いてCI/CD環境まで構築する開発者寄りの人から、ひたすらプロダクトを触り続けてバグを探す作業をする人もいるけど、「QAエンジニア」というときには前者、「テスター」というときには後者をイメージされることが多い気がします。
現在の職場ではテスト自動化を担当しているエンジニアは他にいて、私自身は手動のブラックボックステストを担当しているので後者に近いです。
上の画像は社内LTをしようとして作るだけ作ったスライドからの引用で、元々今のポジションの求人票の募集要件は
という感じでしたが、結果的にこれまでのソフトウェア開発・HTMLマークアップの経験を生かして仕事をさせてもらっているのでとてもありがたいと思っています1。
やっている業務
テスターっぽい業務
メインプロダクトの回帰テスト
週に1度のペースでテスト仕様書に沿って回帰テストをしています。ほとんど全部の画面・機能の正常系を網羅するように項目を組んでできるだけ色々なOSバージョンやデバイスを使うようにしています。
社内ではBasic Testと呼ばれているけどソフトウェアテスト的に正式な呼称はちょっとわからないですね……
最初は開発者が元々使っていたテスト仕様書をシェアしてもらって作業していましたが、秋に大きな仕様変更があったときに作業しやすいように書き直しました。
バグ修正や新機能の動作確認
バグ修正や新機能の追加があったときにはmasterにmergeする前に手で動作を確認しています。
社内ではQA-Testingと呼ばれているけどソフトウェアテスト的に(略
新しいプロダクトや大規模な仕様変更に伴うテスト仕様書の作成・更新
新しいプロダクトや大規模な仕様変更のリリース前は(Basic Testで使っているような)テスト仕様書がないため、要件書を元に動作確認をしながらテスト仕様書を書いています。要件書上では詰められていない細かい箇所についてはmasterの挙動が正しいのかどうかPOや開発者に確認しながら作業しています。
いわゆる探索的テストにあたるものだと思うんですけど(略
QA-Testingもそうですがテスターと一部の開発者しか知らない実装や挙動が見えてきてからは同時にドキュメントも書くようになりました。
プロダクト保守用ドキュメントの作成
先に書いたようにチーム内で「あの画面どうやって出すんだっけ」「どういう経緯でこの機能こうなってるんだっけ」みたいなことが最初の半年くらいでも結構あって、これまではTrelloやSlackのアーカイブを追ってなんとかしていたのを、GitHub Wikiを使ってドキュメントに残していくようにしています。
参考: Pixelaを使ってGitHub Wikiの芝を生やした - びよーんのつま。
業務全体を通していえることですが「ソースを読めばわかることでも、ブラックボックステストの前提を崩したくないのでできるだけソースを読みたくない」というお願いはかなり最初の方に話しました。
参考: 【QA】QAとして開発チームにお願いした4つのこと - びよーんのつま。
英語以外の言語での動作確認
メインプロダクトは英語を元にその他20弱の言語に翻訳されているので、月1くらいで日本語以外のRTL言語2や非ラテン文字言語3での動作確認をしています。
参考: 英語中心多言語対応アプリのテストにおける言語間差異に関するハック・Tips集 - びよーんのつま。
また、翻訳ファイルをインポートしたときに差分に不要なエスケープや文字化けが含まれないかチェックしています。
FAQの内容チェック
プライバシーポリシーや利用規約はPOや開発者が確認・更新しているので、後回しになりがちなFAQの内容のチェックと修正を担当することがあります。
テスト用ツールの作成
テストを楽にするための主にshellスクリプトを書くことがありますが多分中小SIerにいたときよりshellを書いてる気がする。
雑用っぽい業務
チーム内ドキュメントの作成
デバイスの管理用シートや手順書を作成して社内向けのGoogle Siteにまとめています。これもSlackやGoogle Drive内を探し回る必要がなくなったので続けていきたいです。
その他
Drive Day
数ヶ月に1回車で遠出して社内でバグバッシュ大会をする。遠足みたいで楽しい。
やっていきたいこと
他の会社のQAチームの人と仲良くなる
例えばAndroidアプリを開発している人同士、Ruby on Railsを使って開発している人同士の知り合いやすさに比べて、QAチーム同士が会社の規模関係なく知り合って情報交換する場は探しにくいと感じたので、発信することで引き寄せの法則が発動してくれないかなと思っています。
参考: Android Test Night中考えたり呟いていた内容の補足 #android_test_night - びよーんのつま。
JSTQB Foundation Levelを受ける
上で書いたこととも関係あるんですけど、今まで体系的にソフトウェアテストについて勉強したことがないのでしばしば「ソフトウェアテスト的に何ていうのかわからない」「日本語で何ていうのかわからんから英語に訳せない」という状態になるので、他社の人とも話せるようにちゃんと用語を知りたいという気持ちがあります。
英語の雑談力をつける
英語の雑談がとてもつらい。つらいというのは「やりたくない」ではなくて雑談ってめちゃくちゃ難易度高くないですかということです。喋る力は雑談しないとつかないと思うので聴く力とか語彙力を高めて戦っていきたい……
体力をつける
週4時短勤務でも休日は病院行脚してたり突然寝込んだりするので体力をつけたいです。生きたい……
ソフトウェアテスト教科書 JSTQB Foundation 第3版
- 作者: 湯本剛,大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,町田欣史,吉澤智美,中野直樹
- 出版社/メーカー: 翔泳社
- 発売日: 2013/10/30
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
MacでGoogle Chromeが繰り返しクラッシュするので力技で解決した
tl;dr
MacでGoogle Chromeが起動してすぐクラッシュするのを繰り返していたので、Chromeのアプリケーション設定をTerminalで削除→再ログイン・同期することで解決した。
事象
MacでChromeを起動するとすぐクラッシュし、エラーの詳細の冒頭は以下のようになっていた。
Process: Google Chrome [446] Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome Identifier: com.google.Chrome Version: 71.0.3578.98 (3578.98) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Google Chrome [446] User ID: 501 Date/Time: 2018-12-27 12:27:49.258 +0900 OS Version: Mac OS X 10.14.2 (18C54) Report Version: 12 Anonymous UUID: ■■■■■■■■■■■■■■■■■ Time Awake Since Boot: 180 seconds System Integrity Protection: enabled Crashed Thread: 46 Chrome_SyncThread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000
調査
Safariが無事だったのでChrome_SyncThread
で検索したところ、Chromeにログインしているアカウントの同期処理で問題が発生しているっぽかった。
「Google Chrome が予期しない理由で終了しました。」が表示され、ブラウザが利用できない - Google プロダクト フォーラム
実際に行った対処
Chromeにログインしているアカウントは全てオンライン同期済みである。(ちょっと古くて不安だったけど)この記事を参考にGoogle Chromeのアプリケーション設定ファイルをTerminalから初期化することにした。
以下コマンド
$ rm -r ~/Library/Application\ Support/Google/Chrome $ rm ~/Library/Preferences/com.google.Chrome.plist
あとは普通にChromeを起動してログインし直すと元に戻った。
余談
rm
コマンドを打つのが怖かったので気休めとしてplistだけバックアップをとった。セーフモードも試したけどあんまり意味がなかった。
立体! いらすとや トレーディングフィギュア01 ノンスケール PVC製 塗装済み完成品トレーディングフィギュア 6個入りBOX
- 出版社/メーカー: グッドスマイルカンパニー(GOOD SMILE COMPANY)
- 発売日: 2019/01/31
- メディア: おもちゃ&ホビー
- この商品を含むブログ (1件) を見る
英語中心多言語対応アプリのテストにおける言語間差異に関するハック・Tips集
これはソフトウェアテストアドベントカレンダー #2の20日目の記事です。
目次
TL;DR
英語を中心に多言語対応しているアプリをテストしていて使うようになった、主に言語間差異に関するハック・Tips集
前提
自己紹介
id:wifeofvillonです。Twitterその他もだいたい同じユーザー名です。
Drivemode Inc.という米スタートアップ企業の東京オフィスで、今年から週4のQAスタッフとして働いています。オフィスの1/3、社内の半分くらいが非日本語話者で、社内公用語は英語です。
現在のチームは自動テストを含んだCI環境が整っている(できるだけ整えるようにしている)ので
- メインプロダクトの正常系回帰テスト(手動)
- 追加機能・バグ修正箇所の動作確認(手動)
- 新規プロジェクトやデザイン変更時のUI/UXレビュー
- プロトタイプアプリのフィードバック
などを主業務として、開発・テスト用ドキュメントの作成・更新や手動検証環境の整理をしています。
BtoB/C系開発者→BtoC系HTMLコーダー→現職(QA)という経歴であること、これまでQAや検証担当者がいるチームに参加したことがないことから
- よその会社のチームでは機器管理とかテスト項目管理とかテスト実行結果評価とかテストチームの作業範囲の認識合わせとかどうしてるんだろう
- こういう👆話をしているコミュニティってどこかにはあるんだろうけど、実際どこにあるんだろう1
と思っていたので今回アドベントカレンダーに参加しました。何卒ご指導ご鞭撻のほどよろしくお願いします。
関わっているプロダクトについて
今働いているのは米国の企業です。メインプロダクトは運転中のドライバーをサポートするアプリですが、米国を中心に世界中のあちこちの大地をユーザーと共に走っています。そのため英語、特に米国内での機能実装を最優先とし、アクティブユーザーの比較的少ない日本語の優先度は低めになっています。
今回は英語メインの多言語対応アプリのテストをしたときに体験した、日本向けのサービス/ソフトウェア開発ではあまり意識していなかったテスト項目/Tips/ハックについてラフに書きます。
合成音声/音声入力に関するハック・Tips
ここからは特に注記がない場合、便宜上「日本語を母語とする日本語話者」を「日本人」、「日本語以外を母語とする英語話者」を「外国人」と呼称します。
TTSの英語が聞き取れないとき
メインプロダクトはTTS(text to speech)のウェイトがめちゃくちゃ大きく、ほぼ全ての画面で音声を確認する必要があります。
私の英語力はとても低いので、短い文ならまだしも2文以上の文章になってくると聞き取るのがかなりつらくなってきます。
現在システムがすごく長い文章を喋ることはほとんどないのですが、聞き慣れていないある程度長さのある自然な文字列を聞いて確認するテスト(例: メッセージ内に含まれるemojiを読み上げる)でちゃんと単語を聞き取りたいとき、私の場合は音声合成エンジンをEnglish(United States)
からEnglish(United Kingdom)
に変更すると単語が聞き取りやすくなります2。
聞き取りにくい単語
私だけかもしれないんですけど、GoogleのAndroidデバイスのPixelがTTS(EN-US)だと「ピッセル」に聞こえるしPixel XLのXLも「エッセール」に聞こえるのでもうTTS関係ないんですけど「外国人メンバーからXLを借りたつもりでいたら普通のPixelだった」みたいなことがあって……大変恥ずかしい思いを……3
TTSエンジンのない言語
TTSを多用するアプリでTTSエンジンがないときの挙動を確認したいときは言語設定をヘブライ語にするとほぼ確実にTTSエンジンが実装されていません。
ただ、ヘブライ語はRTL言語(後述)かつヘブライ文字なので設定を戻すのにめちゃくちゃ苦労するので気をつけてください。
自分の英語を聞き取ってもらえないとき
メインプロダクトは音声入力も多用します。2018年師走、スマートスピーカー関連などでVUIの実装・テストをしていてA……とかG……の「すみません、聞き取れませんでした」にストレスを溜めている人も多いと思います。
個人差はあると思いますが日本人が発音しにくい単語はわりとあるなと思ってて、私は「previous」「launch」がとても苦手です4。
ハックとしてよくやるのは
- 文章として成立させる(例:
reply
→reply to message
) - 合成音声を使う
の2通りで、後者についてはMacならターミナルで以下のように入力5すればいい感じに発音してくれます。他のOSでもいろいろやりようはあるっぽい6。
$ say -v Alex "previous"
Webでも無料の読み上げサービスがあるのでいろいろ(コンプライアンスに反しない程度で)試してみてください。
非英語圏の固有名詞を聞き取ってもらえないとき
昔から香港とか台湾の人がルーシーとかジェーンみたいな英語名名乗るの何でだろう、おしゃれだな〜と思ってたんですけどあれめちゃくちゃ実用的だったんだな〜と実感しました。
というのはいかにも日本語っぽい固有名詞を英語で入力しようとしても失敗することが多いからです7。
これを英語でやろうとするとsay
コマンドをもってしても失敗しがちなので
- アドレス帳の登録名を英語っぽい名前にする
- (和製)英語を使ってる地名・店名を使う
- 汎用的な単語で表せる場所にする(例: museum、park)
みたいなハックをしています。
私の職場でのニックネームは「Yukkie」なんですけどこれもめちゃくちゃ音声入力しづらいので、自分の電話番号は「Jerry」みたいに英語っぽい名前で登録しています。あと試験端末の一部に宇宙飛行士の名前+アメリカ/イギリスの空母・戦艦の名前をつけています。
固有地名では都内だと「東京スカイツリー」「東京ビッグサイト」みたいな東京+英語の文字列は入力しやすいです。
あと世界中どこにでもありそうなチェーン店(例: スターバックス、マクドナルド)と「皇居(Imperial Palace)」はちょーつよい。おすすめ。
汎用かつ比較的長い文字列で他に似たような施設が少ないものの代表で「神代植物公園(Jindai botanical garden)」もよく使います。
音声入力に成功していることを確かめる場合はこれで十分で、もちろん、音声解析エンジンそのものや検索APIそれ自体のテストをする場合はちゃんと日本語っぽい文字列を使った方がいいでしょう。
非アルファベット言語に関するハック・Tips
今世界で多く使われている文字ってすごくざっくり言うと漢字みたいな表音文字と表語文字があって、前者の中にアブジャド(アラビア文字やヘブライ文字はこれ)、アルファベット(キリル文字やギリシャ文字もこれ)、アブギダ(タイ語はこれ)、あとハングル文字みたいに分けられます。
あと日本語や中国語は縦書きのとき右から書きますが、アラビア語やヘブライ語は横書きでも右から左に書くRTL言語(Right-to-Left)なので標準UIの左右(TRUE/FALSEのボタン配置など)が逆になります。
文字溢れを起こしやすい言語
文字溢れによるレイアウト崩れが起こっていないかの確認はUIテストで避けては通れないものですが、同じ意味をさす言葉であっても日本語中国語では数文字なのに、別の表音文字言語ではめちゃくちゃ長い文字列になることがあります。
各言語をちゃんと学んでいる・意味がわかっている訳ではないので体感でしかないのですが、ロシア語・フランス語・スペイン語は英語に比べて文字列が長くなりレイアウト崩れを起こす印象があります。
RTL言語のレイアウト崩れ
上でRTL言語について触れましたが、システム言語設定がRTL言語になっているとAndroidの標準UIはLTR言語とは左右逆になります。それに合わせてレイアウトを直していく必要がある8ので、対応している場合テストケースに含めておいた方がいいと思います。
おわりに
本当は「TZを変える必要があるテスト」とか「Xperiaでのテストはそんなに重要じゃない代わりに絶対にGalaxyでテストしなきゃいけない」みたいな話題も書きたかったのですが長くなったのでまた機会があれば。
それでは皆さま良いお年を。
- 作者: Manoj Hans,太田健一郎,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/11/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
デザイニング・ボイスユーザーインターフェース ―音声で対話するサービスのためのデザイン原則
- 作者: Cathy Pearl,川本大功,高橋信夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/12/01
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Android Test Night中考えたり呟いていた内容の補足 #android_test_night
Android Test Night #5 - Androidテスト全書の回の聴講枠に当選したので参加してきました。
会の間考えたことにハッシュタグをつけて流していて、いくつかリアクションがあったものがあったので、今回はその補足をする記事です。
前回のこの↓記事同様エモーショナル強めの内容になってしまうのですが、テスト(あるいはチーム開発)どうしていくよ?という話題でもあるのでこちらのブログで書きます。
前提
- Android派のAndroid/iOSアプリテスター
- 週4勤務(10:30-18:00)のアルバイト
- 過去に業務系/Web/Androidアプリの開発とWeb/Androidアプリデザインの業務経験あり
- 自動テストやCI/CD環境は開発者がやってくれます
本題
QA側から「やるやら」を宣言しておく話
自分はホワイトボックステストをやらないと(理由も明確にして)宣言していて、絶対にパッケージングされたアプリでテストするぞと言っていると自分がアサインされる頃にはCI環境ができているか設計中とかでとてもいいです #android_test_night
— wifeofvillon (@wifeofvillon) November 30, 2018
前提に書いた通り今の職場にはバイトとして参加しているのですが、スキルセット的に本来開発者がすべき作業までやれてしまうことがあります。
スタートアップで人員も少ないのでそれ自体はいいことだと思うのですが、
- ブラックボックステストはパッケージングされたアプリですべきだと思う1
- コードを読んでしまうと2開発者に忖度してしまう
- 作業範囲が広がると体力がもたない3
などの理由から「ここまではやる」「ここからはよっぽどの非常時ならやる4」「これは絶対にやらない」をなぜそうしたい(したくない)のかも伝えた上で何卒よろしくと開発メンバーにお願い5しています。
各社の開発体制やQAの権限・待遇・スキルにもよるのですが、現在のプロジェクトでは今のところ開発メンバーからの納得も得られてい(ると思ってい)ます。
ドキュメント書くために開発が遅れるのは嫌だという話
昼間ちょうど「仕様の固まってない画面・フローのUIテストをどうするか」という話になって、開発者に仕様変更の都度カードにコメント=ドキュメントを書かせるのは時間がもったいないので、ある程度塊になってから渡してほしいという話を開発者としました
— wifeofvillon (@wifeofvillon) November 30, 2018
「QAがテストを書くことはないのか」という話題が出た時に呟いた内容です。QAがテストを書いて効果が上がるかは、繰り返しになりますが、開発体制とQAの権限・待遇・スキルにもよると思います。
そして開発体制次第では開発者からQAに仕様を伝えるのにめちゃくちゃコストがかかることがありうるとその日のちょうどこの日の昼間に思ったので開発者に伝えていました。
例えばユーザー登録のフローを画面ごとに分けて開発している場合、1画面できる度にこの画面はフローの中のこの部分でこれこれこういう動作をするからこれとこれを確認してね……というようなコメントをカードに書いてもらっていたら、開発者がコメント=ドキュメントを書く時間がトータルですごく長くなる6し、フローを細切れにした動作確認はそれこそ手動ブラックボックステストに不向きだと感じるので、この場合ならユーザー登録のフロー全部できたから、デザインがまだなのでそれ以外の動作を確認してね……くらいの大きさになってからmentionしてほしいと伝えています。
ということでQAがテストを書く話に戻すと、QAチームの中で例えばAppiumを使って正常系UIテストの一部を簡略化するのはスキルと待遇によってはアリだと思うんですけど、仕様が変わり続けている状態でかつ仕様を決める場にQAがいない場合、かえって効率が悪くなる可能性があるなと思います。
今のチームでは、QAへの仕様展開が不十分で手戻りが発生するの不健康だと思うなぁと伝えたところ理解を得られたので、最近は開発者に展開するときQAチーム(ぼっち)にも展開してもらえるようになったので完全にコミュニケーションの勝利です。
他所の手動テスト事情が知りたい
この前「テスターです」「自動化の人ですか?」「いえ手動です」って言ったら「つらいですね」って言われたんですけど他の会社のQAとかテスターの人がいたら話をきいてみたいです #android_test_night
— wifeofvillon (@wifeofvillon) November 30, 2018
今回書いたことについて「いや普通やろ」と思う人もいれば「スタートアップ&非正規雇用バイアスじゃん」と思う人もいるはずで、というか私の以前の職場やリアル知り合いにもソフトウェア検証や品質保証が主業務の人はけっこういるんですけど、手動テストのことを話す場って探しにくいというか、どう探したらいいのかわからん……しかし話を聞きたい……と数ヶ月くらい考えています。
おいしいものを食べつつ手動テストのことも話す会があったらぜひお誘いいただけると嬉しいです。
tl;dr
「は〜私開発よりQAの方が向いてる気がしてきた……テストやってる人の話が訊きたい……」と言い始めた頃に@usaganikkiさんから「君の場合外山さん @sumio_tym をフォローするといいよ」と言われて、今回も「は〜めっちゃ4章いいこと書いてあるな……」と思ってたんですけど、お話ししそびれたのでなんかこう強くなりたいなと思いました。
あとたまごサンドと唐揚げがめっちゃおいしくて貧血気味の体に染み渡りました。会場スタッフのみなさんもお疲れ様でした。
システムテスト自動化 標準ガイド CodeZine BOOKS
- 作者: Mark Fewster,Dorothy Graham
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/17
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
システムテスト自動化 標準ガイド (CodeZine BOOKS)
- 作者: Mark Fewster,Dorothy Graham,テスト自動化研究会,伊藤望,玉川紘子,長谷川孝二,きょん,鈴木一裕,太田健一郎,森龍二,近江久美子,永田敦,吉村好廣,板垣真太郎,浦山さつき,井芹洋輝,松木晋祐,長田学,早川隆治
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
-
会中もCI/CD環境込みでテストすべきっていう話がありましたがまさにそれです↩
-
あるいは「何故できないかを知ってしまうと」↩
-
タフな働き方ができないので今の働き方に落ち着いています↩
-
リリース直前なのにWerkerのキューが溜まりすぎて処理しきれていないときに、ローカルで未mergeのPRをビルドするケースなど↩
-
納得してもらうための材料は普段から集めるよう心がけています↩
-
今のチームのメインプロダクトは全体の最新仕様を網羅しているドキュメントがなかったので私が手のすいているときに書いています See more: Pixelaを使ってGitHub Wikiの芝を生やした - びよーんのつま。↩