Tableauのテスト戦略
Tableauで開発したダッシュボードをみなさんはどのようにテストしていますか？
普通のシステム開発であれば、設計→開発→テストの工程がありますが、Tableauでダッシュボードを作成した際にテストはどうすればいいかが難しいです。
今までもリリースしてから何カ月もしてから、数値の異常が発見されるケースを私自身みてきました。大抵は、多くのパターンでは正常に表示されるが、ある特定の場合に数値がずれるというケースです。
そこでバグをださないために、Tableau開発で私が心がけていることやテスト戦略をまとめたいと思います。
BIのテストは難しいので、作りをシンプルにする
BIのテストは、通常は画面を見ながら見た目や数値チェックをすると思います。このテスト方法では、たくさんのパターンのテストは難しいです。そのため網羅的なテストができず、冒頭で書かせていただいた特定の場合に数値がずれるケースが見逃されてしまいます。
Tableauでのテスト手法は後ほど記載しますが、それでもテストは難しいのでTableauの作りこみを極力シンプルにして、前処理側でできる限り作りこむようにしています。というのも、データソースのテストの方が網羅的にできるため、レアケースでもバグを発見しやすいです。
IFやCASE文の多用やLOD表現の複雑な使用は極力避けて、シンプルに作ることを心掛けることがまずは大事かと思います。
TableauのAPIを活用したテスト方法
ダッシュボードをTableauServerなどに公開する場合は、Tableau Server REST APIを利用することができます。こちらを利用すると効率よくテスト行うことが可能です。
多くのフィルターパターンで画面キャプチャーをとる
Tableau Server REST APIでは、各種フィルターやパラメータをURLのパラメータとして渡して、その画面を画像として保存することができます。これによりいろいろなパターンのテストが可能になります。
画面上の操作では限られたパターンでしかテストしないケースが多いですが、プログラムで実行すると大量のパターンのテストが可能です。後でキャプチャだけみて、表示がおかしい部分がないかをチェックすればよく、データが表示されないパターンやイレギュラーなパターンのテストができます。
一度テストケースを作ってしまえば、ワークブック修正後に同じテストを繰り返しできるので、
効果的にテストを実施することが可能です。
ワークブックのCSVをダウンロードして、データと突き合わせる
Tableau Server REST APIでは、CSVもダウンロードできます。ただし、ダッシュボードに対して行うとうまくできないので、ダッシュボードを構成している個々のワークシートも一旦サーバにアップして、ワークシート単位でAPIを実行することでCSVをダウンロードすることができます。
特定のフィルター条件の場合のCSVを取得して、途中の計算フィールドの値を確認したり、データソースと突合してチェックしたりと画面で値をチェックするより細かなテストが可能です。
UIでやろうとすると画面でチェックした後、データのダウンロードしなければならず手間がかかるので、いろいろなケースでやることは難しいと思います。
APIを行うテストの注意点
Tableau Server REST APIを利用するには簡単なスクリプトを書かなければならず、一度書けばある程度使いまわせるのですが、テストパターンの準備にも時間がかかります。
さらにアクションフィルターを使っている場合は、URLパラメータでの指定ができないと思いますので、その場合は画面で地道にテストするしかないかと思います。
まとめ
Tableauの品質を保つためにテストは重要です。そのためにも、Tableauでいっぱい作りこむのではなくデータソースを工夫して、Tableau側はシンプルな作りにすべきです。これは、ぱふぉーマンスの観点からもメンテナンス性の観点からもメリットがあります。
その上で、複雑な作りをしなければならない場合は画面上でのテストをしっかり行う必要があります。
画面上で大量なテストケースを実施するのは難しいので、Tableau Server REST APIを使うアイデアを紹介しました。
最後に、Tableauのダッシュボード作成もシステム開発と同じかと思います。Tableauのスキルレベルが上がってくると、より高度で複雑なダッシュボードを作れるようになるので、その際にはこのテストはどうやってやるのかも意識しておくことが重要かと思います。
Discussion