Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話

こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。

初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。

見直しのきっかけ

トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。

製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。

入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいちから見直すことにしました。

当時の問題点

当時、トレタのテスト仕様書は Excel で管理されていました。 Excel は閲覧性が高くテスト仕様書の管理ツールとしても一般的ですが、テストケース管理という意味では不便を感じることがあります。たとえば、こんなところです。

そもそも手元に Office が無いとテストケースの閲覧・メンテナンスができない
バイナリファイルなので git などでバージョン管理しにくい
複数人で共同編集しにくい
テストケースのレビューがしにくい
テストケースの変更履歴や変更の経緯を残しにくい

今後テストケース数も関わる人も増えていく予定だったので、メンテナンスしやすく継続しやすい管理方法を検討することにしました。

Excel から Markdown へ

もろもろ検討した結果、Excel ではなく Markdown (GFM) 形式で記述して、プロダクトのコードと同じように GitHub 上で管理してみることにしました。そうすることで、

テキストエディタでどこでも気軽に編集できる
テキストファイルなので GitHub でバージョン管理・変更管理がしやすい
複数人で同じファイルを編集しても git がよしなにマージしてくれる
Pull Request を使ってテストケースのレビューを行える
プロダクトの Issue/PR とテストケース変更の Issue/PR を紐付けておくことで、テストケース変更の経緯を後から git blame で追いかけることができる

といった効果が狙えます。記述ルールは、GitHub のプレビュー上でもそれっぽく見えるように下記のようにしてみました。

記述ルール

大項目(画面名) : h2
中項目(機能名) : h3
テスト内容: li
確認内容 : checkbox

書き方の例

## ログイン画面

### ログイン機能
- 正しいメールアドレスとパスワードを入力してログインボタンをタップする
  - [ ] ホーム画面に遷移する

GitHub での表示

f:id:dreamagicjp:20160705014751p:plain

テスト実行時は Spreadsheet で

テストケースを管理する際は Markdown の方が扱いやすいですが、いざテストを実行する時は Excel 的な形式の方が一覧して見やすく、テスト時に気付いたことをメモとして残したりもできて、何かと便利なことがあります。そこで、Markdown 形式のテストケースを Google Spreadsheet に変換するための仕組みも準備しました。

具体的には、テストケースを GitHub に push したときに CircleCI で構文をチェックしつつ OK だったら、 google_drive gem で Google Spreadsheet に展開するようにしています。こんな流れです。

デプロイの流れ

f:id:dreamagicjp:20160705021057p:plain