DataSpider Servistaのテスト

Avatar
dstn


みなさまこんにちは。アプレッソ開発部の東です。

今回のエントリーは、DataSpider Servistaのアダプタのテストについてです。
私はアプレッソのQAチームの立ち上げから関わり、どうやったら品質が向上するのか、日々悩んできました。

かつてアプレッソでは、開発者がそれぞれ独自にテストを作っていた時代がありましたが、それでは機能ごとの品質に統一感が取れず、観点もユーザー視点ではなく実装者の視点に偏りがちになってしまっていたため、テスト専門部隊であるQAチームを立ちあげることになったのです。 

そして試行錯誤の末、統一された指針を基にテストが作られ、リリースごとに一定の方針に従って実施されるようになりました。その甲斐あって、現在は安定した品質でのリリースが可能になったのでは、と思います。
今回は、そこまでに至る試行錯誤の流れを簡単ではありますが紹介させていただます。今回のエントリーがたとえば、SDKで作ったアダプタをテストする際の参考になれば幸いです。(ちなみに、以前こちらのエントリーでご紹介したガラポンアダプタもSDKで作成されたものです。)
 

「これだけは絶対に見ておく」項目を作る

QAチームが立ちあがることになり、まず初めにテスト技法の本をいくつか読んでみました。たくさんの種類の技法があって、どれから着手すれば良いか決めきれなかったので、ちょっと考え方を変えてみて、「どんな問題が発生したら困るか」という視点で考えてみることにしました。
たとえば、オペレーションをツールパレットからスクリプトキャンバスに配置した途端にエラーが発生したら…。これは全く使えないということですので、絶対に避けたいところです。同じように、配置後に実行したらどんな設定でもエラーになったり…。
実際のユーザーの使い方をイメージしながら、「最低限これだけは押さえておきたい」という事象をメンバー全員でディスカッションしながら挙げて行きました。
その内容を基に、「ある操作を行った場合に特定の事象が発生しないことを確認する」というような流れのテストを構築しました。
この「最低限これだけは押さえておきたい」という事象を検知するテストを、「これだけは絶対に見ておく」という最小限の構成として、フェーズの要所要所で実行するようなルールとしました。
 

仕様書を基に全機能を見てみる

最低限のテストは作れましたが、これだけでは全機能を触れていないのでまだまだ不安が残ります。そのため、次は「全機能を検証する」ことを目標にしました。
機能が正しく動作していることを確認するためには、「現在の動作」に対する「あるべき動作」が必要になります。その「あるべき動作」の根拠は、仕様書に求めることにしました。
仕様書には「こういう動作をすべき」という「あるべき動作」が記載されていますので、記載されている機能が正常に動作しているかどうか一通り確認する、という形が基本となります。
DataSpider Servistaは大きく分けてGUI部分と実行エンジン部分に分かれているので、テストもその2つのブロックに分けて、GUIのテストは各機能を単位としてExcelでテスト設計書を用意し、「あるべき姿」を期待する動作にしました。実行系のテストは、DataSpider Servistaのスクリプトで確認することにしました。
DataSpider Servistaのスクリプトを使えば、一度作成しておけば何度でも実行でき、手動時と比べてコストが大幅に削減できます。
また、コンポーネント間で受け渡されるデータも確認対象としたいので、アサーションアダプタ(ツールパレットの「基本」-「アサーション」)を使用しました。
001
アサーションアダプタには入力データをファイルで比較する「一致/不一致(ファイル比較)処理」とプロパティ項目に設定したXMLと比較する「一致/不一致(データ比較)処理」があります。データ比較の方が設定は楽で、可変の値(変数)も使える利点がありますが、変更する際にはスクリプトを開く必要があります。ファイル比較の方はその逆でアサート用のファイルを用意する必要がありますが、変更時にはスクリプトを開かずにファイルだけ直せばOKです。
これで、提供されている機能を一通り見ることができました。さらには、仕様書と実際の動作に差異がある場合の検知も可能となりました。
 

さらに深く見る

こうして作ったテストで何度かのリリースを経験し、チームが成長してきたため、より突っ込んだテストの検討を行いました。
データの網羅性を確認するとより信頼性向上に繋がるので、数値データであれば、境界値や文字列、nullなどを、文字列であればシングルバイトとマルチバイト、空文字とnullなどを確認するテストを追加することにしました。そして、ここで初めて「境界値テスト」「同値クラステスト」「デシジョンテーブルテスト」といった一般的なテスト技法を取り入れることにしました。
さらにこれまでは各プロパティ項目の組み合わせは見ていなかったため、それも取り入れることにしました。ただし、項目の組み合わせは項目数に依存してテスト数が増え、工数も飛躍的が増えてしまうため、すべての組み合わせを見るのではなく、ある程度範囲を絞って見ることにしました。そしてその範囲は、リリースごとに少しずつ広げて行くようにしました。
また、接続先が存在する場合に接続先の設定網羅も対象とするようにしましたが、接続先によっては非常に難易度が高いため、これも段階的に導入することにしました。
テストはやろうと思えばいくらでもできてしまうので、まず品質目標をどこに置くのかをしっかりと決めた上で、ユーザーの使用イメージや品質要求、工数、予算と合わせて総合的に判断していくことにしています。
そのために、テストは次も実施するという前提で作ることを徹底しました。過去には、一回だけだと思って必要なデータや手順を残さなかったために、次回実施する際に大変苦労してしまうこともあったためです。テストも大切な資産ですので、長期間に渡って使用できるように気配りをしています。
というわけで、簡単ですがアプレッソQAでのDataSpider Servistaのテストの成り立ちを駆け足で追ってみました。また機会があれば別の視点からも紹介させていただきたいと思います。

コメント

ログインしてコメントを残してください。

Powered by Zendesk