Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ
という記事を読み、「最初から Google Spreadsheets を使えばいいのに」と思った。
実際 Quipper では一年以上前からテスト仕様書として Google Spreadsheets を使っていて、それなりにうまくまわっている。
サービスごとにテストケースは異なるので、こういうスプレッドシートが複数ある（インドネシア・フィリピン・メキシコで展開している Quipper Video / Quipper School 用がそれぞれと、日本で展開しているスタディサプリ用が一つ）これは Quipper Video 用で、 Quipper Video は利用者数の関係からインドネシア向けのアプリケーションに対してテストを実施するので、テストシナリオは英語で書かれているがところどころインドネシア語が混じっている（「学習スケジュール」というボタンをクリックしろ、というシナリオだとすると、「学習スケジュール」という文言がインドネシア語で書かれており大半のスタッフには読めないのでテストシナリオ内に英訳が必要）
一番左のシートがテスト仕様書のマスターで、プロダクション環境へのリリースに備えてテストを実施するタイミングでシートをコピーする。テストケースは上から順番に実施していくとスムーズにこなせるようなストーリー仕立てになっているので、テスト担当者は指定されたOS・ブラウザ・デバイスを使って上から順にテストをしていき、うまくいったら 1 を、うまくいかなかったら 0 をセルに入れていく。全部終わって致命的なバグが無ければリリース（しばしば hotfix をあてて該当箇所を再テスト→リリース、としたりする）これをいまは週に一回やっている。当然テストケースは常時アップデートしていく。
Google Spreadsheets を使うと、冒頭の記事にある「Excel によるテスト仕様書の悪いところ」がほとんど解決できると思う。
- Microsoft Office 不要。ブラウザがあればよい（さすがに Google Apps for Work は会社で利用してるよね、という前提）
- 変更履歴が残るので Git 等でバージョン管理不要（あんまり強力ではないけど！）マスターシートから毎回コピーして過去のテスト実施分のシートはそのまま残すので、そっちでも履歴を担保できる
- リアルタイムに複数人で共同編集可能
- テストケースのレビューはスプレッドシート上では確かにやりづらい！（ここは Quipper でまだちゃんと取り組めてない部分）
- ↑変更履歴のところに書いたとおり、マスターシートのテストケースが変更されても過去にテストを実施したときのシートは当時のまま残るので履歴は残る。経緯はマスターシートのセルへのコメントなどで残せる
おそらく Markdown で書くことよりも Git によるバージョン管理下におけること（つまり GitHub に置けること）を重視したのだと思うが、頻繁に変更したくなるドキュメントを Git で管理するのはあまりおすすめしない。実は Quipper では過去に技術的なメモを同じように Markdown で書き GitHub リポジトリで管理していたのだが（まさに Pull Request でレビューしたいという理由で）、当時は GitHub の Web サイト上でファイルを直接編集できなかったこともあり、ちょっとした変更を気軽にできず、結局すたれてしまった。その後それらのドキュメントを GitHub Wiki に移動したところ、以前よりはメンテナンスされるようになった。
テストケースのレビューについては、現状 Quipper には QA を専門に行う部隊がおらず、テストケースのメンテナンスはプロダクトの仕様に明るい数名の開発者とプロダクトマネージャが仕事の合間に行っている（あとは、テストの実施は開発者・プロダクトマネージャ・一部のセールス担当らが交代で行っているが、最新のアプリケーション仕様に追随できていないテストケースを見つけたらその都度テストケースの方を更新している）このように、正式なチームによる公式なレビューを行えるような体制がまだできていない、いわば「ボランティアベース」なやり方なので、メンテナにとってやりやすい形に最適化されすぎている面は否めない。いままさに QA チームを発足させて体制を整えたりする仕事に取り組もうとしているところだ。
個人的にはオフィスツール、特にスプレッドシートは大嫌いで、 Markdown はもちろん大好きだけど、テストケースの管理においてはスプレッドシートの柔軟さや一覧性の高さがプレインテキストの移植性に勝ると思う。
