テストデータ作成ツールで、End-to-End自動テストやリグレッションテスト効率をあげる

以前の記事から４ヶ月、今回はSETグループでの取り組みの中のひとつ、テストツールによる効率改善についてご紹介します。

なぜ作るのか

テストやデバッグ・仕様調査のために特定の状態を作るためデータ作成作業は、程度の差こそあれ、テスターやエンジニアの業務の一部として発生する作業のひとつです。

ex) 特定の条件でタクシーを注文した後の履歴表示を確認するためには、事前に配車中の注文データを作りたいなど

テスト手順は社内情報共有ツール内で展開されてきていてとても良い状況にありますが、一部では情報が古かったり分散していたり、それぞれが手元で環境構築を行って実行する必要がありと、存在自体にはとても助かりながらも、自己完結の負荷が高く、楽に出来ない現実もありました。（個人スキルの差など）

そういった課題を改善出来るとテストが楽になり、テストに対する心理的負担や時間的効率が改善し、さらにはリグレッションテストの自動化も容易になり、今より良い状態を作れると思い作ることにしました。

これまでの課題

これまでの課題をまとめると

テストケースの前提条件の準備に時間がかかる
SQLやAPI、Unixコマンドなどの知識が必要で出来る人限られる
情報がまとまっているようで分散している（探すのに時間がかかる）
手順が多く手間がかかる
E2E自動化シナリオのステップを省いて実行スピードをあげたい
タクシーを呼びたい側と、注文を受ける運転手側のテストがあり、お互いの端末を操作する。普段の開発ではその辺りの手間も改善したい
テストに必要なデータが整った環境の用意・運用が難しい
開発環境でテスト用に追加したマスターデータが書き換わる

要するにあれ動作確認しなきゃって思った時に、「でもどうやればいいんだ？」っとならずにパパッとやりたいことが出来れば良いんです。

アプローチ方法

最初に、社内ドキュメントや個人からテスト・デバッグに関する情報を集めて、重要そうな機能からツールとして誰でも利用できる環境を提供することにしました。

その後は、マニュアルテスト実行者や自動テスト側の意見を定期的に取り入れながら、機能拡張をしていく運用サイクルを想定しています。

結果として、サービスに関わる人の作業効率化を図っていく流れです。

最初から大きく目指さず、小さく繰り返しながら。

実際に作った

６月２３日が初コミットで、最初に１〜２週間ほどで形になるものができました。

最初はテストが難しくデグレの頻度が多かったある状態を簡単に再現出来る機能だけです。

役割

テスト・デバッグに関わる作業の効率を改善しながら、属人化を防ぐこと。

提供価値

テストデータ作成を容易にする Webページを用意しソフトウェア開発経験が無い人でも利用できる
システムフレンドリー APIを用意し自動テストやサービス自体のデバッグ機能としてを組み込める

現在の構成

フロントエンド： React.js, TypeScript
APIサーバー：Ruby on Rails
バックエンド：Docker
その他
- ブラウザ依存の機能をAPIで隠蔽するため： Node.js (Puppeteer + Headless Chrome)
- APIドキュメントは Swagger で管理

当初は席に置いてあるMac miniで稼働していましたが、現在はSRE協力のもとAWS上で稼働しています。（参考記事：JapanTaxi Kubernetes Ecosystem）

得られた効果

前述した課題の多くを打ち取れた、または改善することができました。（テストに必要なデータが整った環境などのインフラ面の課題については未解決）

自己完結出来ることが増え、テスト方法に関する質問が飛び交う頻度が減った
構想を形にできたことで、あの作業もツール化すれば楽になるかも？というアイディア出しや議論が出来るようになった

今の課題はこれ

テストツールがエラーを吐いた時の原因がわかりにくい

テストツールのテストをテストツールで・・・（すみません）

どこに原因があるのか、調査に必要なデータをレスポンスに返すように改善。それでも現在のツール構成に課題が残っている部分があるため、恒久対応すべくSREと共に引き続き改善しています。

皆が開発出来る状態に

今後サポート範囲が増えるにつれて、情報のキャッチアップ速度やテストツール側への反映速度などがボトルネックになってきます。このツール自体が属人化するのは防ぐ必要があります。

APIやWebを提供するために広く浅く様々な技術を使って作られているため、高度で無くともフロントエンドやサーバーサイドの開発経験が必要です。社内で採用実績のある技術を選定していますが、より絞った方が良いと感じています。例えばAPIもWebもNode.js + TypeScript で統一することでより必要な言語を減らすこと。ただし言語が同じでもサーバーとフロントでは根本的に違うのでそこの知識が引き続き必要になります。

直接DBを書き換えている箇所がある

プロダクト側にテスト用APIエンドポイントを生やす。

今後の展望

だれでも機能追加が出来る環境を作る

イメージとしては社内OSS。 SETグループが面倒を見つつも今後の機能拡張の可能性を考えると自由に手を加えられる状態にしたいを考えています。既にインフラ面はSREグループに見てもらっていますし。ドキュメント整備やモブプロ・ペアプロを通してトラックナンバーを増やいけると良いと思います。

運用しやすいGraphQLモックサーバーを作る

これは今回のツール自体とは別の話ですが、主にアプリ開発者目線で、サーバーやDBの観点を抜くことでよりテスト可能な範囲を広げることができます。

以前特定の機能に限りモックサーバーを用意しましたが、時系列を考慮した動的なレスポンスパターンデータの管理コストが高く、サーバーの変更にキャッチアップしていけず廃れてしまったので、運用リソースをしっかり考えた上で再チャレンジしたいと考えています。うまく作用すれば運用リソースは十分元を取れると確信しています。