TestRailと連携させテストケースをGitHubで管理してみた

みなさんはテストケースをどう管理されていますか？ Excel、スプレッドシートはよく聞きますし、最近だとテスト管理ツールを活用されているところも多いようです。

JapanTaxiでは、今年になって初めてQAエンジニアがチームに加わりました。これまでも様々なテストが、さまざまな役割の人によって行われていましたが、より専門的で高度なテスト体制が組めるように、QAエンジニアを中心に、急速にテストフェーズの構築と展開を進めています。

（図）アプリごとのテストフェーズ展開図。まずはテストフェーズの横展開を進めながら、要件参加へとシフトレフトしています。

このフェーズをどう短縮していくか？ 効率化していくか？ は別記事「SETチームが取り組む魅力的品質へのチャレンジ」などをご参考ください。今後も自動化に対する取り組み等を発信させて頂く予定です。

テストが社内に広がっていくと同時に問題となってくるのが「テストケースをどう管理していくか？」です。これまで利用されてきたテストだけでなく、環境の整備によりどんどんテストが生まれてくるため、どう管理するかが大切になってきます。

まずはテストを整理してみよう

（図）JapanTaxi内でのテストを整理した図。どこからどう手を付けるか検討しながら進めています。

まず、「Android/iOSアプリのテストの区分戦略」を参考に簡単にテストケースを仕分けし、それぞれにどういう意味をもたせるかを整理しました。まずは大きなテストから進めているため、小さなテストはスコープ外になっています。

話はズレますが、自動化の進捗もこの表で確認できます。リグレッションのケース数が膨大になってきたため、その中からスモークテスト的なとても重要なシナリオだけを集め、リリース前に行うテストとして抜き出しています。

リリース前のテストは自動化がほぼ完了しており（進捗が100％にならないのは、自動化できないテストもあるから）、この運用結果を見て、リグレッション自動化に進むか否かを見極めているところです。

整理したテストを管理する

（図）整理したテストの運用・管理方法も整理

次に、それぞれのテストの管理方法を整理しました。基本はTestRailというオンラインツールを活用し、そこにケースと実行結果データを蓄積していこうとしています。

管理の際に求められるのは大きくふたつあり、「テストケース自体の管理」と「テスト結果の管理」です。特に、テストの自動化やシステム・アプリ本体の改善を促進するためには、テスト結果データの管理がとても重要です。

E2Eテストの不安定さを見える化してみたでも紹介させていただいたように、結果データから不安定なテストを特定し、システムやアプリ改善のヒントにつなげていくことで、より効率的・効果的なテスト（自動テストを含む）が可能になります。

TestRailはAPIも公開されているので、テスト自動化との相性も良く、両方の管理が簡単に行えます。

GitHubとTestRailを連携させる

リリース前のテストは、GitHubでの管理を検討しています。これは以下のような課題があったからです。従来、テストケースが追加・更新・削除された場合、以下のような流れになっていました。

• QAエンジニアが、TestRail上のテストケースを更新する
• SETが、その内容を確認し、自動化されている場合はテストコードを修正する

逆に、テスト対象が更新され、自動テストに変更が必要になったときに以下のような流れになります。

• SETが対応策を検討。シナリオ変更で対応できる場合はテストケースとコードを修正
• QAエンジニアがその内容をレビューし確認

今はまだ少人数だからこのフローでも問題ありませんが、QAとSETの調整コストが高くなるのは避けたいものです。さらに、同期がうまくとれず「テストケースとコードで差分ができちゃってる！」となると、せっかくのテストの意味がなくなってしまう場合もあります。

（図）Gharkin記法で記述したテストコード

JapanTaxiでは幸い、JapanTaxiのE2EテストコードはGharkin記法で記述されており、非エンジニアでも理解できます。そして、TestRailにはAPIがあるので、テストコードを正とし、読み込んでTestRailに反映すれば、差分が生まれる問題は防げます。

（図）テストコードをTestRailに反映

簡単なスクリプトを書いて、Gharkin形式のテストコードをTestRailに反映させると上記のようになります。こうやってみると、通常のテストシナリオと違いがあまりないのがわかると思います。

今回のテスト管理フローを整理してみましょう。ケースが増えた場合の流れです。

1. QAエンジニアやSETが、テストケースをGharkin形式で作成。PRをメンバーに送ります
2. メンバー内でレビュープロセスを走らせます。問題なければマージします
3. マージに反応して、GitHubのコードをTestRailに反映させるスクリプトを実行します

QAエンジニアもGharkin記法を学べば、QAエンジニアが直接テストコードを修正できるようになります。しかもGitHubを使うのでプルリクエスト（PR）の仕組みも利用できます。

さらに、QAとSETがコードを共に所有するため、エクストリーム・プログラミングの「ソースコードの共同所有」というプラクティスが機能します。分担と調整がなくなり、テストケース設計やテストコード設計を、共に学びつづけられるようになってきました。

いかがでしたでしょうか？ この取組みはまだはじめたばかりですが、ケースが整備され、自動テストも安定してきたため、リグレッションテストにも広げられそうです。

supported by daipresents

Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください！