AndroidアプリQAテスターが職場でやってよかった取り組み(2019年3Q)
2019年7月〜9月の間にぼっちQA teamとして職場でやってよかったっぽい取り組みについて書く。
テスト用Googleアカウントの作成
いつかやらなきゃいけないけど勝手にやっていいのか？と思っていたタスクについて、許可を取り付けて進めた。
テスト用デバイスが増え続けている割に、テスト用Googleアカウントは少数を使いまわしている状態だったので増やした。
今後アカウントを作る人によってレギュレーションが変わるのをどうにかしようという話になったので、多分大体の国で通じそうで連続性のある、必要数より項目数多めのリストを作成した。
連絡先のインポート作業
地味なんだけど新しく作ったGoogleアカウントそれぞれに社内テスト用SIMカードの電話番号をインポートした。一気にやると後々手間が省けるので……
ドキュメント共有のための取り組み
現在ドキュメントをGitHub Wikiで管理しているんだけど、それをミラーリングできないかと画策していた。
結局「できそうだけど作業コストが見合わなそう」と見送ったものや途中のものもあるけど、これまで書いたことのない言語・ツールを使う機会ができてよかった。いつか使うかもしれないし。
*.mdファイルをHTMLファイルにしてGoogleドライブで共有する
Go言語を使ってサクッと変換からアップロードまで実行できそうだったんだけど、Googleドライブだとハイパーリンクの管理が大変だということでこの方法はやめる。[[こういう形式]]のリンクだと大変というだけなので[こういう形式](https://example.com)のリンクしかないファイルであれば使いまわせそうな気がする。
GitHub Actionsのgollumイベントでミラーリングする
GitHub Wikiが更新されたタイミングで何かしたいときに、GitHub Actionsでgollumイベントを取ってあれこれできるらしいので自分のアカウントで試していた。
最終的にストアで配布できるものを作りたかったんだけど、リポジトリの公開範囲(private/public)とかOrganizationアカウントかどうかとかまだ未検証な部分が多い。
社外イベントに参加する
DeNA QA Night #3に参加した。色々考えることがあって行ってよかったけど、名刺があったらもっと他社の人と話しやすかっただろうなと思った。
前Qまでのエントリ
近況
待望の名刺ができたので技術イベントの度に会場入り口で運転免許証見せなくてもよくなったのが地味にうれしい。新旧どっちの姓で申し込んでるのか忘れていることも多いので
CLIでMarkdownファイルをHTMLに変換してGoogle Driveにアップロードした
これは何か
コマンドラインツールでMarkdownファイルをHTMLファイルに変換してGoogle Driveにアップロードした。
GitHub Wiki向けに*.md形式で記述しているファイルをGoogle Driveにミラーリングして拠点越えてドキュメントをシェアできるかという実験だったけど、結果は「Wiki内のハイパーリンクを解決しないとあんまり意味がない」だった。
やる(やった)こと
実行環境: MacOS 10.14.6, Homebrew 2.1.11
- Goをインストールする
- gdrive-org/gdriveでGoogle Driveを触れるようにする
- russross/blackfriday-toolで
*.mdを*.htmlに変換する *.htmlファイルをアップロードする
Goをインストールする
HomebrewでGoをインストールする。
$ brew install go $ go version
これだけだとgo getしたパッケージを実行できなかったのでGOPATHを通す。
export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin
参考:
gdrive-org/gdriveでGoogle Driveを触れるようにする
$ brew install gdrive $ gdrive list
gdrive listすると認証用のURLが提示されるのでそれをブラウザ上で開く。認証用のkeyが返ってくるのでそれをコピペする。
特定のディレクトリにファイルをアップロードする場合は以下の画像の白線部分で隠したIDを--parentで指定する。
$ gdrive upload --parent XXXXXXXXXXX sample.txt
参考:
russross/blackfriday-toolで*.mdを*.htmlに変換する
$ go get -v github.com/russross/blackfriday-tool $ blackfriday-tool help $ blackfriday-tool -page -xhtml=false myrepo.wiki/_Sidebar.md > myrepo.wiki.mirror/_Sidebar.html
参考:
*.htmlファイルをgdriveで(mime指定なしで)アップロードするとGoogle Drive上ではGoogle Docsで開けるファイルになる。
ただ予想はしていたけど画像のように[[こういう]]Wikiのリンクは何かしらの方法でGoogle DriveのIDに変換しなければいけないのでだったらWebサイトとしてディレクトリ構成そのままアップロードできるようにした方がよくない？と思った。
いつかの自分にやってもらうメモ
gollumあたりを調べてください
【追記あり】JSTQB Foundation Level試験を受けてきたメモ
これは何か
JSTQB認定テスト技術者資格 Foundation Level試験(以下、JSTQB-FL)の8月試験を受験した。申し込みから試験対策、試験当日までの受験者視点の情報を書いた比較的新しいブログ記事が少ないと感じたためメモを残す。
結果はまだ出ていないので合格したかどうかはわからない。
受験申し込みについて
開催実績を見る限り、JSTQB-FLは毎年3月と8月の第3土曜日あたりに実施されている。日程開示と受験受付開始(個人)の日程は、JSTQB-FL第27回のケースでは以下の通りだった。
- 試験日程開示: 2019年4月24日
- 受験受付開始: 2019年5月8日〜6月25日
- 試験実施: 2019年8月24日
- 合格発表: 2019年10月16日【2019/10/17 12:55追記】
試験勉強について
教材
公式シラバス・用語集
公式サイトからそれぞれ無料でダウンロードできる(PDF形式)。シラバス、用語集の他にアジャイルテスト向けのシラバスのExtensionもあるけどこっちはテスト範囲ではない。
ちなみに今年(第27回)までは2011年版のシラバスが試験の下地になっていたが、来年(第28回)からは2018年版が基準になる。
『ソフトウェアテスト教科書 JSTQB Foundation』(翔泳社)
知り合いの検証系部門にいる人はだいたい持っている青い鈍器。たまたま家に遊びに来た職業を知らない友人まで持っていたので社内で借りたりもらったりできるかもしれない。Kindleで買ってもいい。
ただ今から買うなら前述の通り2018年版シラバスを元にした改訂版(第4版)が出るのを待ったほうがいいかもしれない。
技術系文書特有の読みにくさはシラバスとそんなに変わらない気がするけど、章に応じた練習問題や用語集、模試が含まれている。
ソフトウェアテスト教科書 JSTQB Foundation 第3版
- 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
- 出版社/メーカー: 翔泳社
- 発売日: 2011/11/12
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 85回
- この商品を含むブログ (12件) を見る
2019/09/02 14:15追記
第4版は2019年09月17日発売だそうです(@shoeisha_booksさんより)
練習問題
公式サンプル問題
公式サイトにサンプル問題がある。ただ
- 問題文
- 正解の選択肢
- 間違った選択肢
- 解説
という記述順序になっているので全く役に立たないとは言わないけど、それこそ自分でランダム出題するアプリケーションを作りでもしないと使いにくいと思った。
『ソフトウェア教科書』の練習問題・模試
前掲の教科書の中に練習問題と模試がある。私は本文を読むのがしんどかったので問題を解いてから当該する本文箇所を読んでいた。
無料de試験(Web)
id:dentakurou さんの「無料de試験」には直前にお世話になった。WebアプリケーションだけどスマホとPCでUIと出題数が変わる。出題はランダム。スマホでやるのがおすすめ。
テス友(Android, iOS)
Qbookが出しているスマホアプリ。アカウント登録が必要で、仮URLを送るメールが届かないと思っていたらおそらく迷惑メールフォルダに入っていた。アカウント登録時の入力項目がやたらと多いので使わなかったが紹介しておく。
試験当日について
私はTOC有明の会場だった(東京)。試験会場に時計がなかったらつらいと思って隣のTFTの中の100円ショップでアナログ時計を買ったけど、会場内に基準時計があったので別になくてもよかった。
あと受験票に写真の貼り付けが必要。スマホで送った画像を200円でコンビニでプリントアウトしてくれるサービスがあるからそれを使った。
試験開始から30分経つと問題用紙、回答用紙、アンケート用紙を提出して帰ってもいい。
試験結果の発表について
試験結果は試験後3ヶ月以内に発表されるらしい。当日配布される注意事項を記載したプリントに個々の受験番号も印刷されているのでそれをなくさないようにすること。
【2019/10/17 12:55追記】
昨日(10月16日)合格者の受験番号が発表された。私の見間違いでなければ受かっているっぽい。
おまけ
直前になってCacooで図表をガリガリ描いてはTwitterに投げるという勉強をしていたんだけど嘘をついている画像があるかもしれない。
何もわからん pic.twitter.com/mJZT37BM39
— wifeofvillon🚢 (@wifeofvillon) August 23, 2019
複数のGoogleアカウントに同じ連絡先をインポートする方法
これは何か
複数のGoogleアカウントのContactsに同じ連絡先をインポートするときたぶん手軽だと思う方法のメモ
前提
- PCでやる
- Google Chromeが使える
- 連絡先をインポートしたいGoogleアカウントをChromeに追加してもいい
Steps
アカウントについて
使用するアカウントを以下のように扱う。
- アカウントA: 今Google Chromeにログインしているアカウント
- アカウントX, Y: 連絡先をインポートしたいGoogleアカウント
上はGoogle ChromeでGoogle コンタクトを開いたときのページヘッダのスクリーンショットで、右上のユーザアイコンをクリックすると別のGoogleアカウントを追加したり切り替えたりできる。
実際にやること
- アカウントAとしてGoogle Chromeで[Google コンタクト]を開き、連絡先情報を登録する
- [エクスポート] > [Google CSV]でCSVファイル(以下
contacts.csv)を取得する - アカウントXを追加する
- アカウントXとしてログインし[Google コンタクト]を開く
- アカウントXとして[インポート]をクリックし
contacts.csvをアップロードする - アカウントYを追加する(以下略)
公式ドキュメント
- エクスポートする方法: 連絡先のエクスポートとバックアップ - パソコン - 連絡先 ヘルプ
- インポートする方法: 連絡先の追加、移動、読み込み - パソコン - 連絡先 ヘルプ > [ファイルから読み込む場合]
AndroidアプリQAテスターが職場でやってよかった取り組み(2019年2Q)
2019年4月〜6月の間にぼっちQA teamとして職場でやってよかったっぽい取り組みについて書く。
Android端末とSIMカードが増えた
前QのエントリでAndroid端末の管理について書いたけどそこからさらに端末が増えた。多分10台くらい増えた。SIMカードもこれまで複数のサービスを利用していたが、国内用SIMはひとつのサービスに一本化した。
Android端末・SIMカード受け入れ時にやることリストの作成
最近は新しい端末やSIMカードが届くととりあえず私の席に積まれるようになってきたので、普段私がやっている受け入れ時の作業を明文化した。
これで私がやらなくても誰かがやれるようになっただけでなく、とりあえず開けて使ってみたかったメンバーがGoogle Docsのドキュメントを開いて「2-aまでやってある」みたいに伝えてくれるようになった。
Android端末の物理管理状況向上
端末数が増えたので物理的に管理しきれなくなったというか「これは1台でもバッテリーが発火したらやばいな」という状態になっていたので、アプリ開発に携わらない事務担当のメンバーに「こういうことができたらな〜」と言ったらサクッと100円ショップのアイテムと既存のACアダプタでいい感じのドックを作ってくれた。
かなり快適になったので、いろんな意味でメンバーを巻き込んでよかったと思っている。
RTL言語を意識してやっていく
すでにサポートしているRTL言語（アラビア語・ヘブライ語）をもうちょっと手厚くテストしていきたいな〜という話を新大久保の焼肉屋でランチのハラミを焼きながらしたような気がする。
音声入力
前Qで英語の発音がアレすぎるのをサポートするMac用shellを書いたけどそれのアラビア語版を作った。
RTL言語でテストするとわりと思ってもない初歩的な実装漏れが見つかる印象がある。
参考: Macのsayコマンドを使ってアラビア語・ヘブライ語を読み上げる - びよーんのつま。
各種ドキュメントをSlackのカスタムレスポンスに登録する
前QでSlackにopen sesameって打ったらTrelloのカードテンプレを呼べるようにしたって書いたけど、ついでに他にもいくつか登録しておいた。デバイス＆SIMの管理リストを呼ぶコマンドは他のメンバーにも定着しつつあるような気がする。
前Qのエントリ
これはLEAP motionのチュートリアルで遊んでた画像 pic.twitter.com/Hd29xqnT4K
— wifeofvillon (@wifeofvillon) April 9, 2019
試験端末にインストールされているアプリを一気にアップデートしなければならず読書しながら床でストレッチをする生首（体付き）のイラスト pic.twitter.com/p6EiXL5mW8
— wifeofvillon (@wifeofvillon) April 19, 2019
いつもの森はめっちゃ紫陽花が良いです pic.twitter.com/Ag7GzMudco
— wifeofvillon (@wifeofvillon) June 17, 2019
そんな感じで私は多分元気です。
SOYJOY全部入りパックをおやつリストに入れてみたけどアーモンドチョコが一番好きだな
大塚製薬 ソイジョイ アーモンド&チョコレート 30g×12個
- 出版社/メーカー: 大塚製薬
- 発売日: 2014/04/21
- メディア: 食品&飲料
- この商品を含むブログ (1件) を見る
Macのsayコマンドを使ってアラビア語・ヘブライ語を読み上げる
概要
MacOSの「say」コマンドを使ってアラビア語・ヘブライ語の合成音声読み上げを行う方法のメモ。
(V)UIテストでの音声入力にMacの合成音声を使う話は以下の記事でも書いた。
sayコマンドについて
say -v ${voice} ${text}
${voice}に音声の名前(人名)、${text}に読み上げてもらいたいテキストを入力する。
say -c Alex "Hello"
Terminalを立ち上げて上のコマンドをコピペすると男性の声で「ハロー」と読み上げられるはず。
このとき${voice}で使える音声(キャラクター？)は/System/Library/Speech/Voices/下にあるものである。
このキャラクター名は「システム環境設定」＞「アクセシビリティ」＞「スピーチ」の「システムの声」の中にリストされているものと同じなので、ここであたりをつけておくといい。
アラビア語・ヘブライ語の音声指定
sayコマンドでアラビア語を使うときはLaila、Maged、Tarikあたり、ヘブライ語を使うときはCarmitを使うっぽい。
say -v Maged "سلام" #アラビア語 say -v Carmit "שלום" #ヘブライ語
「ぽい」というのはアラビア語にバリエーションがありすぎてどれが何準拠なのかわからないからである。
tl;dr
音声入力で操作する画面のUIテストを無理矢理アラビア語でやるためのshellを書いてたんだけど、コード中にアラビア文字が表れると入力カーソルがどっちに動くのかわからないのでドキドキする
アプリケーションに新しい機能を追加したときUIテストで気をつけていること
概要
新機能を実装したり、既存機能をマイナーチェンジしたりするときに拾うUIのバグというか考慮漏れ？にある程度パターンがある気がするので注意して確認するようにしている箇所について書く。
現職で主に扱うのがAndroidアプリなのでAndroidアプリベースで書いているけどtoC/toBのWebでもあ〜あったな〜こういうの〜みたいな気分で書いているのですごくRTLサポートの話以外は特殊な話はしていないと思う。
前提
- 既存の画面Aに画面部品Bを追加する
- 画面部品Bをタップすると新しく実装した画面Cが表示される
という仕様を想定して動作確認するときに、個人的にどこを注視しているかを書く。なお、数値、文字列、画像など表示に用いるデータ自体は正しいものとする。
画面部品を追加したときに注視するところ
既存の部品とレイアウトが揃っているか
特にカードやリストの一部などコレクションにアイテムを追加したとき、既存部品とレイアウトは揃っているか。
- テキストの文字揃え(*1)
- テキストの文字サイズ
- テキストのフォント
- アイコンの位置(*2)
- アイコンのサイズ
- 背景・テキスト・アイコンの色(*3)
- 画像アイコンの形
- シャドウの有無
- 枠線の有無
- 効果音設定(*4)
1)と2)についてはRTL向けレイアウトをサポートしている場合はそこも見る。
3)についてはカラーテーマをユーザが変更出来る場合、それも考慮する。
4)についてはタップ・スワイプにリアクション音をがっつりつけているアプリだと、耳が慣れすぎて気づかないことがあるので注意しないとなーと最近思った。
単位表記がローカライズによって崩れないか
最近あった例でいうと、上のカウンターが実装されたときに「km」「mi」が「キロ」「マイル」のように翻訳されてレイアウトが崩れた。
このケースはユーザーがどちらの単位を使うか選ぶことができるので気がついたけど、そうでなかったら「km」表記で決め打ちになっていると思い込んでいたかもしれない。「users」と「人」のように短くなるケースも文字揃えが指定されていなくてズレることがありそう。
画面を追加したときに注視するところ
ナビゲーション部品の配置が既存画面と揃っているか
戻る・閉じる・メニューを開くといったグローバルなボタンの位置や向きは他の画面と揃っていて欲しい。最近あった例でいうと戻るボタンをLTRで「←」のアイコンで表しているとき、RTLでは逆向きにしてあげないといけない。
あんまり起こらないケースだけど、デザインを他の画面とは違うテイストで新しく作ったときには要件レビューの時点で気づけるとみんな幸せに過ごせると思う。
既存画面とレイアウトが揃っているか
画面部品のレイアウトの話に加えて、いわゆるトンマナ1に沿ったデザインであるかも確認したい。
カラールールをどこまで厳格にするかはプロジェクトや企業によると思うけど、今の職場は割と決まった色の中でやろうとする傾向がある。特にデザイナーに画像を作ってもらわないといけない箇所は手戻りが大きいので、これも要件レビューの時点で気づいておきたい。
導線が複雑な場合「戻る」の挙動はどうするか
既存画面Aからも新画面Cからも画面Eに行ける場合、「戻る」ボタンの戻り先はどこなのか。ありそうなケースは
- アプリの設定画面の下に新しい項目を追加する
- アプリのホーム画面に「新機能！」カードを表示する
- ↑をタップすると設定画面の新項目を直接開く
みたいなやつ2。この例えの場合「新機能！」をタップしてきた人が「戻る」を押した場合遷移先は設定画面なのかホーム画面なのかが明文化されていないケースはエンジニアやデザイナーに確認する。
まとめ
仕様書の粒度はプラットフォームにもよるしデザイン体制にもよると思うけど、部品の追加だけならともかく、画面追加や画面遷移の変更を伴うアップデートの考慮漏れは先に確認しておいた方がテスト担当は安心できる。
仕様書が文書じゃなくてAdobe XDとかSketchとかで作ったプロトタイプの場合も戻り先がわかるようになっているとありがたい。
![ノンデザイナーズ・デザインブック [第4版]](https://images-fe.ssl-images-amazon.com/images/I/51HKaOqL-RL._SL160_.jpg "ノンデザイナーズ・デザインブック [第4版]")
- 作者: Robin Williams,小原司,米谷テツヤ,吉川典秀
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/06/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
マンガで分かる！ Fate/Grand Order(2) (カドカワデジタルコミックス)
- 作者: リヨ
- 出版社/メーカー: KADOKAWA
- 発売日: 2019/05/25
- メディア: Kindle版
- この商品を含むブログを見る
