CLIでMarkdownファイルをHTMLに変換してGoogle Driveにアップロードした

これは何か

コマンドラインツールでMarkdownファイルをHTMLファイルに変換してGoogle Driveにアップロードした。

GitHub Wiki向けに*.md形式で記述しているファイルをGoogle Driveにミラーリングして拠点越えてドキュメントをシェアできるかという実験だったけど、結果は「Wiki内のハイパーリンクを解決しないとあんまり意味がない」だった。

やる(やった)こと

実行環境: MacOS 10.14.6, Homebrew 2.1.11

1. Goをインストールする
2. gdrive-org/gdriveでGoogle Driveを触れるようにする
3. russross/blackfriday-toolで*.mdを*.htmlに変換する
4. *.htmlファイルをアップロードする

Goをインストールする

HomebrewでGoをインストールする。

$ brew install go
$ go version

これだけだとgo getしたパッケージを実行できなかったのでGOPATHを通す。

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

参考:

• GO言語をMacで使ってみる インストール - Qiita
• GOPATH は適当に決めて問題ない - Qiita
• 他言語から来た人がGoを使い始めてすぐハマったこととその答え - Qiita

gdrive-org/gdriveでGoogle Driveを触れるようにする

github.com

$ brew install gdrive
$ gdrive list

gdrive listすると認証用のURLが提示されるのでそれをブラウザ上で開く。認証用のkeyが返ってくるのでそれをコピペする。

特定のディレクトリにファイルをアップロードする場合は以下の画像の白線部分で隠したIDを--parentで指定する。

$ gdrive upload --parent XXXXXXXXXXX sample.txt

参考:

• gdrive help 日本語訳 - Qiita

russross/blackfriday-toolで*.mdを*.htmlに変換する

github.com

$ 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

参考:

• Markdown テキスト変換ツールの物色 — しっぽのさきっちょ | text.Baldanders.info

*.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日

jstqb.jp

www.juse.or.jp

試験勉強について

教材

公式シラバス・用語集

公式サイトからそれぞれ無料でダウンロードできる(PDF形式)。シラバス、用語集の他にアジャイルテスト向けのシラバスのExtensionもあるけどこっちはテスト範囲ではない。

ちなみに今年(第27回)までは2011年版のシラバスが試験の下地になっていたが、来年(第28回)からは2018年版が基準になる。

jstqb.jp

『ソフトウェアテスト教科書 JSTQB Foundation』(翔泳社)

知り合いの検証系部門にいる人はだいたい持っている青い鈍器。たまたま家に遊びに来た職業を知らない友人まで持っていたので社内で借りたりもらったりできるかもしれない。Kindleで買ってもいい。

ただ今から買うなら前述の通り2018年版シラバスを元にした改訂版(第4版)が出るのを待ったほうがいいかもしれない。

技術系文書特有の読みにくさはシラバスとそんなに変わらない気がするけど、章に応じた練習問題や用語集、模試が含まれている。

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

2019/09/02 14:15追記

第4版は2019年09月17日発売だそうです(@shoeisha_booksさんより)

www.shoeisha.co.jp

練習問題

公式サンプル問題

公式サイトにサンプル問題がある。ただ

1. 問題文
2. 正解の選択肢
3. 間違った選択肢
4. 解説

という記述順序になっているので全く役に立たないとは言わないけど、それこそ自分でランダム出題するアプリケーションを作りでもしないと使いにくいと思った。

『ソフトウェア教科書』の練習問題・模試

前掲の教科書の中に練習問題と模試がある。私は本文を読むのがしんどかったので問題を解いてから当該する本文箇所を読んでいた。

無料de試験(Web)

id:dentakurou さんの「無料de試験」には直前にお世話になった。WebアプリケーションだけどスマホとPCでUIと出題数が変わる。出題はランダム。スマホでやるのがおすすめ。

hp.vector.co.jp

テス友(Android, iOS)

Qbookが出しているスマホアプリ。アカウント登録が必要で、仮URLを送るメールが届かないと思っていたらおそらく迷惑メールフォルダに入っていた。アカウント登録時の入力項目がやたらと多いので使わなかったが紹介しておく。

play.google.com

JSTQB試験（FL）完全攻略 テスト技術者の友

• VALTES CO.,LTD.
• 教育
• 無料
• 

apps.apple.com

試験当日について

私はTOC有明の会場だった(東京)。試験会場に時計がなかったらつらいと思って隣のTFTの中の100円ショップでアナログ時計を買ったけど、会場内に基準時計があったので別になくてもよかった。

あと受験票に写真の貼り付けが必要。スマホで送った画像を200円でコンビニでプリントアウトしてくれるサービスがあるからそれを使った。

pic-chan.net

試験開始から30分経つと問題用紙、回答用紙、アンケート用紙を提出して帰ってもいい。

試験結果の発表について

試験結果は試験後3ヶ月以内に発表されるらしい。当日配布される注意事項を記載したプリントに個々の受験番号も印刷されているのでそれをなくさないようにすること。

おまけ

直前になって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アカウントを追加したり切り替えたりできる。

実際にやること

1. アカウントAとしてGoogle Chromeで[Google コンタクト]を開き、連絡先情報を登録する
2. [エクスポート] > [Google CSV]でCSVファイル(以下contacts.csv)を取得する
3. アカウントXを追加する
4. アカウントXとしてログインし[Google コンタクト]を開く
5. アカウントXとして[インポート]をクリックしcontacts.csvをアップロードする
6. アカウント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アダプタでいい感じのドックを作ってくれた。

ボックスの中に100円均一の皿立てを並べてある

かなり快適になったので、いろんな意味でメンバーを巻き込んでよかったと思っている。

RTL言語を意識してやっていく

すでにサポートしているRTL言語（アラビア語・ヘブライ語）をもうちょっと手厚くテストしていきたいな〜という話を新大久保の焼肉屋でランチのハラミを焼きながらしたような気がする。

音声入力

前Qで英語の発音がアレすぎるのをサポートするMac用shellを書いたけどそれのアラビア語版を作った。

RTL言語でテストするとわりと思ってもない初歩的な実装漏れが見つかる印象がある。

参考: Macのsayコマンドを使ってアラビア語・ヘブライ語を読み上げる - びよーんのつま。

各種ドキュメントをSlackのカスタムレスポンスに登録する

前QでSlackにopen sesameって打ったらTrelloのカードテンプレを呼べるようにしたって書いたけど、ついでに他にもいくつか登録しておいた。デバイス＆SIMの管理リストを呼ぶコマンドは他のメンバーにも定着しつつあるような気がする。

前Qのエントリ

wifeofvillon.hatenablog.com

---

これは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個

Macのsayコマンドを使ってアラビア語・ヘブライ語を読み上げる

概要

MacOSの「say」コマンドを使ってアラビア語・ヘブライ語の合成音声読み上げを行う方法のメモ。

(V)UIテストでの音声入力にMacの合成音声を使う話は以下の記事でも書いた。

wifeofvillon.hatenablog.com

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では逆向きにしてあげないといけない。

あんまり起こらないケースだけど、デザインを他の画面とは違うテイストで新しく作ったときには要件レビューの時点で気づけるとみんな幸せに過ごせると思う。

既存画面とレイアウトが揃っているか

画面部品のレイアウトの話に加えて、いわゆるトンマナ¹に沿ったデザインであるかも確認したい。

カラールールをどこまで厳格にするかはプロジェクトや企業によると思うけど、今の職場は割と決まった色の中でやろうとする傾向がある。特にデザイナーに画像を作ってもらわないといけない箇所は手戻りが大きいので、これも要件レビューの時点で気づいておきたい。

導線が複雑な場合「戻る」の挙動はどうするか

既存画面Aからも新画面Cからも画面Eに行ける場合、「戻る」ボタンの戻り先はどこなのか。ありそうなケースは

1. アプリの設定画面の下に新しい項目を追加する
2. アプリのホーム画面に「新機能！」カードを表示する
3. ↑をタップすると設定画面の新項目を直接開く

みたいなやつ²。この例えの場合「新機能！」をタップしてきた人が「戻る」を押した場合遷移先は設定画面なのかホーム画面なのかが明文化されていないケースはエンジニアやデザイナーに確認する。

まとめ

仕様書の粒度はプラットフォームにもよるしデザイン体制にもよると思うけど、部品の追加だけならともかく、画面追加や画面遷移の変更を伴うアップデートの考慮漏れは先に確認しておいた方がテスト担当は安心できる。

仕様書が文書じゃなくてAdobe XDとかSketchとかで作ったプロトタイプの場合も戻り先がわかるようになっているとありがたい。

ノンデザイナーズ・デザインブック [第4版]

マンガで分かる！ Fate/Grand Order(2) (カドカワデジタルコミックス)

---

1. トンマナとは - Webマーケティング用語｜ferret [フェレット]↩

2. 先に思いついたのが某スマホゲームでキャラクターのレベルが上がってプロフィールが解放された後、ダイアログのボタンから直接プロフィール画面を開いて「戻る」を押すと開きっぱなしの「解放されました」ダイアログに戻るっていうやつだったんだけど、例として不適切な気がしたのでやめた。↩

定期実施しているリグレッションテストにテストマネジメントツールを試験導入してみた

今働いているチームでは、メインプロダクトの正常系処理を一通り手で触ってみるリグレッションテストを週に1回実施している。このテストにテストマネジメントツールを1ヶ月間試験導入してみたので、実際にやったこととやってみた感想を書く。

tl;dr

雰囲気だけでテストをしているのでテストマネジメントツールをお試しで使ってみたら現状の運用のよくないところが見えてきてよかった。

テストマネジメントツール試験導入の概要

テストマネジメントツールは英語・日本語共に使用レポ記事が多い印象を受けたTestRailを選択した。

www.gurock.com

スケジュール

日付	やったこと
1/22	TestRailのアカウント取得 テストケースのimport
1/24	実施計画提出
1/25 - 2/19	テスト実施(週2)
2/4	中間報告提出
2/19	最終報告提出 各データのexport

テストケースのimport/exportに関しては別のエントリで書いた。

wifeofvillon.hatenablog.com

試験導入期間はテスト実施回数を増やすため、毎週火・金曜日にテストを行った。その点についてメンバーに理解を求めるためなぜ、いつまで、なにをするかという実施計画をSlackに流した。

TestRailを触り始めて半月くらいで中間報告をレポートとして先の実施計画に追記してSlackに流した。最終報告は追記したものの中間報告でほとんど書いていたためそういえばSlackに流してないな……

実施計画・報告書の内容

このエントリは社内向けの実施計画/報告書を下敷きにして書いている。参考までに目次を貼る。

• Overview
  • History
• Why did I try the test management tool
  • How working on Basic Test and QA testing currently
  • What I expect the test management tool
  • How I try to use the test management tool
    • Trial schedules
• Interim Report
  • Steps to start to run Basic Test on TestRail
  • Good and Not-good points
  • Functions of TestRail which need to be followed in spreadsheet method
• Final Report
  • How I used main features
• Appendix: Screenshots of TestRail

テストマネジメントツールを使ってみた感想

「今やれていないこと」を可視化できる

現状ではGoogleスプレッドシートを使ってテストケースの登録からシナリオの作成、レポートの作成まで手動でやっている。

これは実施者が私ひとりであることに依存した運用なのでpreconditionが書かれておらず、stepsと期待結果が分離されておらず、本来独立した複数のテストケースとして扱われるべきフローをひとつのテストケースとして扱っていることがある。元々開発者から引き継いだテスト仕様書とはいえ、あまりいいことではないなと気づくことができた。

今回対象となったプロダクトは英語とそれ以外の言語設定でシナリオが異なるが、それもテスト実施中に私が吸収してしまっていてよくないなと思った。上で書いたことと合わせて属人化している要素が思った以上に多いようだった。

テスト的に正しいかどうかの判断材料となる

自分含めTwitterで「テストがわからん」と言っているテスターは割と見かける。「テストに関する情報はググれば出てくるが何が標準なのかわからん」という気持ちは常にある。

JSTQB(ISTQB)のシラバスを読むだけでも勉強になるが抽象的なのでなるほどわからんとなってしまった。今JSTQB-FLの教科書を買って読んでいるが、テストマネジメントツールが標準的な機能として何を備えているかを知っているかどうかでかなり読みやすさは違うと感じた。

備考: TestRailの使い勝手について

• SPAに慣れてしまったせいでRedmineの操作感に懐かしさを感じた
• 最低限の機能はともかくレポートなどは英語でテスト用語がわからないとつらい
• 当たり前だけどテストマネジメントツールを使いさえすれば完璧なテストができるという訳ではない

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

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