こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。
初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。
Spreadsheet 上の表示
たかがテストケース管理だけのためには少々大げさかもしれませんが、これによってひとつのテストケースを Markdown 形式でも Spreadsheet 形式でも参照できるようになり、テストの編集時と実行時とで形式を使い分けることができるようになりました。
見直しのきっかけ
トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいちから見直すことにしました。当時の問題点
当時、トレタのテスト仕様書は 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 での表示
テスト実行時は Spreadsheet で
テストケースを管理する際は Markdown の方が扱いやすいですが、いざテストを実行する時は Excel 的な形式の方が一覧して見やすく、テスト時に気付いたことをメモとして残したりもできて、何かと便利なことがあります。そこで、Markdown 形式のテストケースを Google Spreadsheet に変換するための仕組みも準備しました。 具体的には、テストケースを GitHub に push したときに CircleCI で構文をチェックしつつOKだったら、 google_drive gem で Google Spreadsheet に展開するようにしています。こんな流れです。 デプロイの流れ
Spreadsheet 上の表示
たかがテストケース管理だけのためには少々大げさかもしれませんが、これによってひとつのテストケースを Markdown 形式でも Spreadsheet 形式でも参照できるようになり、テストの編集時と実行時とで形式を使い分けることができるようになりました。
