こんにちは、しょくぱんです。ナビタイムジャパンでバスロケーションシステムの開発・運用を担当しています。

今回はバスロケーションシステム開発で新しく導入したテストについてお話できればと思います。

バスロケーションシステムとは

バスロケーションシステムは、バスが今どこを走っているか、定刻に対して何分遅れているか、リアルタイムに確認できるシステムです。バスロケーションシステムのデータは主に二種類あります。一つは静的データと呼ばれ、路線や時刻表など運行計画されたデータを表します。もう一つは動的データと呼ばれ、現在運行しているバス位置や到着予想時刻などリアルタイムに変化するデータを表します。バスロケーションシステムは、その二種類のデータをもとにバスの遅れ時間や位置情報などを提供します。

バスは他の公共交通機関と異なり、道路の混雑状況等によって日常的に遅延が発生します。そのため、バスの遅延や位置などのリアルタイム情報はバス利用者にとって極めて重要な情報となります。これまで、リアルタイム情報はバス事業者とバスロケーション機器のメーカーの間でデータ仕様などが決められ、特定の事業者のみ利用できるものでした。しかし昨今は、その情報をより多くの利用者に提供できるように、共通フォーマットとして GTFS / GTFS-RT が普及し、オープンデータとして公開されるようになりました。

そのため当社も、より多くのユーザーに重要な情報を提供するべく、バスロケーションシステム開発専門のチームが発足しました。

チーム発足時の課題

現在、私の所属するチームでは、バスロケーションシステムの開発と静的データと動的データの取得及び運用を行っています。しかし専門のチームが発足する前は、システムとデータは別々のチームで開発していました。そのため、データとシステムを通したテストは行っておらず、実施していたのはシステムのリグレッションテストのみでした。そのような状況では安定したシステムの提供は難しくなります。

バスロケーションシステムはリアルタイムにバス情報が確認できるため、不具合が起きて誤った情報が出た場合、利用者への影響は大きくなります。そのため、まずはテストについて整備することにしました。

テストがなかった理由

なぜあまりテストをしていなかったのでしょうか。
理由は大きく二つありました。

1. データがリアルタイムに変化する

一つ目は動的データがリアルタイムに変化することです。
早朝や深夜はバスが運行していません。そのため、バスが運行している時間帯でしかテストが出来ません。またデバッグ中にデータが変わってしまい、事象の再現が出来なくなる問題もありました。

2. データの特徴が異なる

二つ目は会社によってデータの特徴が異なることです。
前述の通り、GTFS / GTFS-RT がバスデータの共通フォーマットとして普及していますが、独自フォーマットの会社も存在します。またひとえに GTFS といっても会社ごとに様々な特徴があります。そのため同じフォーマットのデータだからと、同じ処理やテストを実装しても上手くいかないことがありました。

導入したテスト

上記二点の理由を考慮して、バスロケーションシステムの開発に当たり、新しく導入したテストは三つです。

1. データテスト

一つ目はデータに関するテストです。
データテストではデータ間の整合性や欠損、期待値について確認をしています。前述の通り、データは会社ごとに様々な特徴があることが課題でしたが、地道に全ての会社に対してデータの特徴やパターンを洗い出しました。
例えば、運行中のバスを特定する時、バスの便 ID を使う会社とバスの路線 ID と始発時刻を使う会社があります。便 ID を使う会社は便のデータを追加してテストする必要があり、路線 ID と始発時刻を使う会社は路線と時刻のデータを追加してテストする必要があります。
このように、会社ごとに必要なデータが異なってくるため、会社ごとに観点の異なるテストを実装しました。また以前はシステムを通してデータの問題を検知していましたが、システムを通さずにデータの確認ができ、問題の早期発見と修正が可能となりました。

2. システムの単体テスト

二つ目はシステムの単体テストです。
単体テストではシステムの実装について確認しています。テストで使用する動的データはリアルタイムに変化することが課題でした。

しかし、動的データを運行ログとして圧縮、保存しておき、そのデータを参照できるように整備しました。これによりテストをしたい時間帯などの過去の事象の再現も容易にできるようになりました。また以前は特定の便や区間が運行している時間帯を待って、システムの確認をしていたため、開発に時間がかかっていましたが、時間帯を気にすることなくテストが出来るようになり、開発速度の向上にもつながりました。

3. API テスト

三つ目は API テストです。
システムとデータ間のテストとして、実施しています。API テストは Postmanで実装しており CI で実行可能です。

API テストはシステムやデータをリリースする時に Jenkins で実行しています。このテストでシステムとデータ間に問題がないか最終確認をしてリリースを行っています。

以上、三つのテストを導入したことで、データやシステムに問題があってもリリース前の検知が可能となり、バスのリアルタイムな情報をより安定した状態で提供できるようになりました。

おわりに

以上、当社で実施しているバスロケーションシステム開発のテストの話でした。テストの実装はひと手間かかりますが、その分、不具合を減らすことができ、安定したサービスの提供につながると改めて感じました。今後も品質を保ちつつ、バスロケーションシステムの開発や機能拡張を進めて、より使いやすいサービスを提供してまいります。

最後までお読みいただきありがとうございました。