TrelloでIssue Templateみたいにカードを作る

概要

バグやIssueをTrelloで管理するときにカードのDescriptionの体裁が揃ってると読みやすい。GitHubだとIssue Templateがあるけど、Trelloの場合はテンプレートとなるカードを作って置いて複製する運用が一般的っぽい。

ところで「trello 新しいカードを追加 url」で検索したらこんなページが出てきたので、これを利用してテンプレート文言を元に特定のボード・カラムに新しいカードを作成できるようにしてみた。

trello.com

公式ブックマークレット

https://trello.com/ja/add-cardにアクセスすると、開いているWebページを添付して新しいカードを作るブックマークレットが提供されている。
親切にも特定のボードやリストを指定してブックマークレットを作ることもできる。

f:id:wifeofvillon:20190214140357p:plain
公式ブックマークレットで特定のボードを指定している場合(ポップアップ形式)

パラメータについて

存在を確認したパラメータは以下の通り。valueは全てURLエンコードが必要。

key value example
source 表示中のWebページのwindow.local.host *1 wifeofvillon.hatenablog.com
url 表示中のWebページのURL *2 https://wifeofvillon.hatenablog.com/
idBoard ボードID *3 -
idList リストID *4 -
mode ポップアップ形式にするかどうか *5 popup
name カードの名前 create%20card
desc カードの詳細説明 *6 add%20description

*1については、このパラメータがあることで何の作用があるのかわからなかった。
*5はブックマークレットの時のみ有効。

URLを指定するとどうなるか

URLを指定すると表示中のWebページのURLをカードに添付してくれると同時に、そのページに<meta property="og:image" />など画像が指定されている場合1、それもカバー画像として添付してくれる。

f:id:wifeofvillon:20190214133737p:plain
このブログのトップページのカードを作成した場合

ボードID、リストIDをどうやって取得するか

*3および*4のボードIDやリストIDは、Trelloの画面上で普通に確認するのが難しいので、API keyを持っているのでなければ以下のような手段を講じる必要がある。

Markdown形式のテンプレートを詳細説明に含める

*6のカードの詳細説明はエンコードすれば長文のテンプレートを仕込める。

# Environment

<!-- not need to fill all item -->

Android OS version:
Device Name:
Email: 

# Steps

1. aaa
1. aaa
1. aaa

みたいな複数行にわたるテンプレートも

%23%20Environment%0d%0a%0d%0a%3c%21%2d%2d%20not%20need%20to%20fill%20all%20item%20%2d%2d%3e%0d%0a%0d%0aAndroid%20OS%20version%3a%0d%0aDevice%20Name%3a%0d%0aEmail%3a%20%0d%0a%0d%0a%23%20Steps%0d%0a%0d%0a1%2e%20aaa%0d%0a1%2e%20aaa%0d%0a1%2e%20aaa

みたいにURLエンコードしてしまえばパラメータに含めてしまうことができる。

f:id:wifeofvillon:20190214135635p:plain
https://trello.com/en/add-card での例

ただスクリーンショットで見てわかる通りスクロールバーが表示されずスクロールできることに気づかない可能性があるので、スクロールできることをアナウンスするか、テンプレート内に書いておいた方が親切な気がする。

TL;DR

もうすでにドキュメント化されてそうなのに検索してもスパッと出てこなかったので書いた。時間があったらそのうちテンプレート入りURL生成ツールを作ります。

あとURLのjaのところにenとかdeとかfrを入れても普通に使える。


  1. 具体的にどのタグを見ているのかは確認していない

PS4のビデオキャプチャをUSBフラッシュメモリと母艦PC経由で他の部屋から見るまでにやったこと

PlayStation 4 (厳密にはPlayStation 4 Pro)で撮ったビデオキャプチャ

  1. USBフラッシュメモリにコピーして
  2. (PS4と同じ部屋にある)Mac miniに移して
  3. (同一ネットワーク上にある)MacBook Airで見る方法

のメモ

TL;DR

本当に長いから本当に読まなくていい

回りくどい手順を踏んでいる理由

1TBとかの外付けHDDを買ってくれば一発で済むことをわざわざ回りくどい手順を踏んでいるのには以下のような理由があります。

  1. キャプチャデータを保存するつもりだった2TBの外付けHDDを拡張ストレージとしてフォーマットしてしまったため
  2. 手元にあってフォーマットしてもいいUSBストレージの中で最も容量が大きいものが64GBだったため
  3. プレイ中の画面をほぼずっとキャプチャしていて無駄な箇所が多くMac miniで動画編集をしたいため
  4. 家族がPS4を使っている間もキャプチャ動画を再生したいため

外付けHDDの拡張ストレージ化

1)については完全に人間は愚か1案件なんですけど、PS4に外付けHDDを繋いで拡張ストレージとしてフォーマットしてしまうとキャプチャやセーブデータの保存先に指定できません。

USBストレージ機器を拡張ストレージとしてフォーマットすることで、アプリケーションをインストールできます。また、PS4™の本体ストレージからアプリケーションを移動することもできます。

拡張ストレージを使う | PlayStation®4 ユーザーズガイド

どっちみちキャプチャの保存先をUSBストレージに指定することはできないっぽいので、外付けHDDを使う場合でもファイルをコピーするステップは必要になるようです。
拡張ストレージにした外付けHDDをDLしたアプリケーションデータの保存先に指定したら「Marvel's Spider-Man」をはじめとしたやたら容量の大きい洋ゲーの分がごっそり空いたのでヨシ!

USB 2.0だとファイル転送がすごく遅い(気がする)

2)について、今回実際に使っているUSBフラッシュメモリはこれです。

シリコンパワー USB2.0 Ultima U05 Series 64GB スライド式 永久保証 ピンク SP064GBUF2U05V1H

シリコンパワー USB2.0 Ultima U05 Series 64GB スライド式 永久保証 ピンク SP064GBUF2U05V1H

上で挙げた公式ドキュメントの「拡張ストレージとして使える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本体ストレージ上のキャプチャファイルをコピーする方法

  1. USBストレージ機器をPS4に接続する
  2. 拡張ストレージとしてフォーマットせずに、[設定] > [ストレージ] > [本体ストレージ管理] > [キャプチャー] を開く
  3. ゲームタイトル・ファイル種類・個別ファイルを選択して操作する(複数選択可能)

ファイルコピー中はPS4で遊べないので注意

USBフラッシュメモリのフォーマット

上の3)でUSBストレージ機器を使用できないというエラーが出た場合は以下の設定でフォーマットすると大丈夫だった

f:id:wifeofvillon:20190213134427p:plain
[Launch Pad] > [その他] > [ディスクユーティリティ]

Mac本体上のディレクトリを同一ネットワーク内から参照する方法

USBフラッシュメモリからMac miniにキャプチャデータをコピーするとき、パブリックディレクトリ(~/Public)をコピー先にすると手間が省ける

  1. [システム環境設定] > [共有] を開く
  2. [ファイル共有] にチェックを入れる
  3. [オプション] で共有設定を変更する

今回はSMBを使った

f:id:wifeofvillon:20190213140640p:plainf:id:wifeofvillon:20190213140652p:plain
[システム環境設定] > [共有]

備考

ていうかPS Vitaでリモートプレイしながらビデオキャプチャ撮れたら最高じゃん……と思ってたら撮れるっぽい。

waniyamasan.com


  1. DWU ξ(Ծ‸Ծ)ξ (@D_W_Underground) | Twitter

  2. PS Vita で PS4 のリモートプレイをするには?

  3. 一部のステージとイベント戦闘以外はその気になればほぼNPCが戦ってくれるの意。全力で戦いたいという人はもちろん積極的に敵を殴れます。

Android端末に表示されているWebコンテンツをGoogle Chromeの開発者ツールでデバッグする方法

数ヶ月に一回くらい必要になるけどその度にやり方を忘れるので書く

NOTE: このエントリはHow to inspect web contents shown on Android devices with Google Chrome(en)を和訳したものです

試行環境

あらかじめやっておくこと

手順

  1. USBケーブルでAndroid端末をPCに接続する
  2. Android端末に「USBデバッグ接続」の通知が表示されることを確認する
  3. PCのブラウザでchrome://inspect/#devicesを開く

スクリーンショット

f:id:wifeofvillon:20190204143704p:plain
chrome://inspect/#devices

f:id:wifeofvillon:20190204143657p:plain
inspectをクリックして表示されるインスペクタ

f:id:wifeofvillon:20190204143645p:plainf:id:wifeofvillon:20190204143639p:plain
PC上での編集内容がAndroidにも反映される

参考

Vue.js入門 基礎から実践アプリケーション開発まで

Vue.js入門 基礎から実践アプリケーション開発まで

TestRailに既存のテストケースをインポートするときのファイル仕様(CSV,XML)

TestRailに既存のテストケースをインポートするときのファイル仕様についてのメモ。なおテスト仕様書はGoogleスプレッドシートExcelに記載してあるものとする。

公式サイトおよびドキュメント

tl;dr

テスト管理ツールを使ってみたかったのでTestRailを1ヶ月間試してみることにした。ツール選択時の参考にした記事は以下。

とりあえず既存のテスト仕様書(約200ケース)をインポートしていつもより多めに(テストを)回してみようとしたらインポート用のファイルの作成に2〜3時間かかった。正直ド●ゴンクエストビ●ダーズ2で手が滑って山の上から溶岩を流して山ひとつと結構な面積の海が蒸発させてそのあと6時間かけて整地したときの気分に近いものがあった。

前提

やりたいこと

f:id:wifeofvillon:20190124120351p:plain
画像1. インポートするテスト仕様書(部分)

f:id:wifeofvillon:20190124120456p:plain
画像2. テストケースのインポートが完了したTestRailの画面

Googleスプレッドシートで作成された画像1のような構造のテスト仕様書を画像2のように階層化されたテストケースとしてインポートする。

インポート元となるテスト仕様書の構造

テスト仕様書(画像1)は部分抜粋なのでわかりにくいが、このテスト仕様書はリリースver.で確認するテストケースと、デバッグver.で確認するテストケースが両方記載されている。そのためviewflow / phaseの上にもうひとつセクション階層がある。

テスト仕様書の各テストケースが属するセクション階層は以下のようになる。

  • UI/UX Tests with Production build > Onboarding
  • UI/UX Tests with Production build > Onboarding > Installation

CSVファイルでインポートする場合

CSVファイルを使ったインポートは簡単だがサブセクションが多いテスト仕様書には向いていないっぽい。

f:id:wifeofvillon:20190124122522p:plain
画像3. インポート用に作成したCSVファイル(部分)

f:id:wifeofvillon:20190124122914p:plain
画像4. CSVインポート時に表示されるダイアログ

f:id:wifeofvillon:20190124123124p:plain
画像5. CSVインポート時に指定可能な項目

CSVファイルをインポートするとき、例えば画像3CSVファイルであればTitleSection DepthSection Hierarchyをそのまま指定したいが(画像4)、TestRailのCSVインポート機能はSectionまでしかサポートしていない(画像5)。

もちろん同じテストケースをTestRailに手動登録してからCSVをエクスポートしてみると、セクション階層に関するいずれの項目も出力されている。

なので次の画像6のようにサブセクションを持たないテスト仕様書をインポートするならそれほどファイル整形に労力はかからないはず。

f:id:wifeofvillon:20190124125344p:plain
画像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 &quot;License&quot; view</title>
                        </case>
                        <case>
                            <title>can open &quot;Privacy Pollicy&quot; view</title>
                        </case>
                    </cases>
                </section>
            </sections>
        </section>
        ...
    </sections>
    ...
</section>

今回はSection Depthの異なるテストケースが混在していることがややこしくなる原因だった気がする。

今回はこのネストしまくったファイルをGASを使わずにSpreadcheet関数のみで生成するのはちょっとしんどいな〜と思ったのでサブセクションを全て手動登録してからXMLをエクスポート→テストケースを追記して再度インポートという手段を取った。

まとめ

サブセクションがないテスト仕様書はCSVでどーんとインポートすれば良さそう。大項目〜小項目までサブセクションで再現したい場合はXMLを生成してインポートしたら良さそう。

もちろんどちらの方法でもPriorityEstimateStepsを含むカスタムフィールドも追加できるのでついでに追加するといいかもしれない。

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版

  • 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
  • 出版社/メーカー: 翔泳社
  • 発売日: 2011/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 5人 クリック: 85回
  • この商品を含むブログ (12件) を見る

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

AndroidアプリQAテスターのおしごと(2018年)

今週(1月23日)でDrivemode Inc.の東京オフィスで働き始めてちょうど1年になるので、現状の整理として現在やっている業務と今後やっていきたいことについて書きます。

tl;dr

今の仕事をするようになってから「QAテスターの仕事とはなんぞや」と読んだり考えたりしたんですけど、とりあえず「QAエンジニア」や「テストエンジニア」「テスター」の業務範囲や待遇は会社やチームによって全く違うということを実感しました。

例えばテストコードを書いてCI/CD環境まで構築する開発者寄りの人から、ひたすらプロダクトを触り続けてバグを探す作業をする人もいるけど、「QAエンジニア」というときには前者、「テスター」というときには後者をイメージされることが多い気がします。

現在の職場ではテスト自動化を担当しているエンジニアは他にいて、私自身は手動のブラックボックステストを担当しているので後者に近いです。

f:id:wifeofvillon:20181202102526j:plain

上の画像は社内LTをしようとして作るだけ作ったスライドからの引用で、元々今のポジションの求人票の募集要件は

  • Androidアプリの動作確認担当者
  • 基本的なPC作業ができること
  • 英語でドキュメントを読んだり不具合を報告したりできること
  • 運転免許を持ってるとなおよし
  • ソフトウェアテストの経験があるとなおよし

という感じでしたが、結果的にこれまでのソフトウェア開発・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回車で遠出して社内でバグバッシュ大会をする。遠足みたいで楽しい。

www.instagram.com

やっていきたいこと

他の会社のQAチームの人と仲良くなる

例えばAndroidアプリを開発している人同士、Ruby on Railsを使って開発している人同士の知り合いやすさに比べて、QAチーム同士が会社の規模関係なく知り合って情報交換する場は探しにくいと感じたので、発信することで引き寄せの法則が発動してくれないかなと思っています。

参考: Android Test Night中考えたり呟いていた内容の補足 #android_test_night - びよーんのつま。

JSTQB Foundation Levelを受ける

上で書いたこととも関係あるんですけど、今まで体系的にソフトウェアテストについて勉強したことがないのでしばしば「ソフトウェアテスト的に何ていうのかわからない」「日本語で何ていうのかわからんから英語に訳せない」という状態になるので、他社の人とも話せるようにちゃんと用語を知りたいという気持ちがあります。

jstqb.jp

英語の雑談力をつける

英語の雑談がとてもつらい。つらいというのは「やりたくない」ではなくて雑談ってめちゃくちゃ難易度高くないですかということです。喋る力は雑談しないとつかないと思うので聴く力とか語彙力を高めて戦っていきたい……

体力をつける

週4時短勤務でも休日は病院行脚してたり突然寝込んだりするので体力をつけたいです。生きたい……

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版


  1. 仕事が増えて業務内容が複雑になった分時給も上げてもらいました

  2. アラビア語ヘブライ語など

  3. ロシア語やタイ語、韓国語など

MacでGoogle Chromeが繰り返しクラッシュするので力技で解決した

tl;dr

MacGoogle Chromeが起動してすぐクラッシュするのを繰り返していたので、Chromeのアプリケーション設定をTerminalで削除→再ログイン・同期することで解決した。

f:id:wifeofvillon:20181227130926p:plain:w120

事象

MacChromeを起動するとすぐクラッシュし、エラーの詳細の冒頭は以下のようになっていた。

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から初期化することにした。

zakihaya.hatenablog.com

以下コマンド

$ rm -r ~/Library/Application\ Support/Google/Chrome
$ rm ~/Library/Preferences/com.google.Chrome.plist

あとは普通にChromeを起動してログインし直すと元に戻った。

余談

rmコマンドを打つのが怖かったので気休めとしてplistだけバックアップをとった。セーフモードも試したけどあんまり意味がなかった。

英語中心多言語対応アプリのテストにおける言語間差異に関するハック・Tips集

これはソフトウェアテストアドベントカレンダー #220日目の記事です。

qiita.com

目次

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

聞き取りにくい単語

私だけかもしれないんですけど、GoogleAndroidバイスPixelがTTS(EN-US)だと「ピッセル」に聞こえるしPixel XLのXLも「エッセ」に聞こえるのでもうTTS関係ないんですけど「外国人メンバーからXLを借りたつもりでいたら普通のPixelだった」みたいなことがあって……大変恥ずかしい思いを……3

TTSエンジンのない言語

TTSを多用するアプリでTTSエンジンがないときの挙動を確認したいときは言語設定をヘブライ語にするとほぼ確実にTTSエンジンが実装されていません。

ただ、ヘブライ語はRTL言語(後述)かつヘブライ文字なので設定を戻すのにめちゃくちゃ苦労するので気をつけてください。

自分の英語を聞き取ってもらえないとき

メインプロダクトは音声入力も多用します。2018年師走、スマートスピーカー関連などでVUIの実装・テストをしていてA……とかG……の「すみません、聞き取れませんでした」にストレスを溜めている人も多いと思います。

個人差はあると思いますが日本人が発音しにくい単語はわりとあるなと思ってて、私は「previous」「launch」がとても苦手です4

ハックとしてよくやるのは

  • 文章として成立させる(例: replyreply 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でテストしなきゃいけない」みたいな話題も書きたかったのですが長くなったのでまた機会があれば。

それでは皆さま良いお年を。

実践 Appium

実践 Appium


  1. Androidアプリ開発界隈にいると手動テストに関する話題をあんまり聞かない(テスト自動化はよく聞く)気がする

  2. 容認発音の方がそれぞれの単語が聞き取りやすい気がする。意味がわかるかどうかは置いておいてCNNとBBCを聴き比べてみるといいかもしれません

  3. そういえばNexus 6でもそういうことがあった気がする……

  4. 知り合いのエンジニアは「what」とか「when」みたいなWHから始まる単語が駄目らしいので本当個人差

  5. Macのsayコマンドの使い方 - Qiita

  6. macOS, Ubuntu, Windowsでの日本語テキスト読み上げ - Qiita

  7. 私が日本人だからかもしれないし、そもそも音声解析エンジンが日本語っぽい単語を解析するに至ってないのかもしれない

  8. C93 Android モダンプログラミングに RTL 対応の章を書きました - Infinito Nirone 7