私のチームは、Cognos を使用して SaaS/マルチテナント アプリケーション用の分析ダッシュボードを構築しています。私が直面している問題は、テストの正しい戦略です。
現在、開始日フィルターと終了日フィルター (月/年形式)、1 つのディメンション フィルター、およびメジャーを選択するための 2 つのコントロールを使用して 1 つのレポートをテストしています (合計または個別のカウントとして表すことができる 7 つのメジャーがあります)。
さらに、ユーザーは結果レポートのポイントをドリルスルーして、詳細なトランザクション データを表示できます。
また、あるテナントのレポートが別のテナントのデータを表示しないことも暗示的です。
では、ここで問題です。この単純なレポートのテストには 2 週間かかり、フィルターとメジャーの膨大な組み合わせに対する何百ものテストが必要です。それは私にはひどくやり過ぎのように思えます。
検索スペースを確実に削減し、過度に反復的なテストを回避するために使用できる「戦略」はありますか?
良い質問！通常、SSAS キューブにヒットする Tableau に基づく新しいレポートを公開する (または公開したい) 場合、通常、特定のグループの人々にスーパー ユーザー グループとして行動して、本番環境の場合と同じようにレポートを使用するように依頼します。これには一定の期間はかからないかもしれませんが、テストするのに 2 日間しか与えられていないとしますが、数週間にわたって続けます。それまでの間、バグの修正や変更を行って、この同じグループに再配布することができます。時間をかけてテスターを停止し、修正を待ってから続行する必要はありません。
誤解しないでほしいのですが、締め切りの開始日を設定することは依然として理想的ですが、レポートを実際に小さなグループ内で配布することで、各パラメータ テスト ケースを実行するよりも迅速に物事を進めることができます。
レポートを使用できる「すべての可能な組み合わせ」をテストしようとしているようです。典型的なレポートまたは重要なレポートを最もよく表すいくつかの選択されたレポートに対してそれを行うのが賢明かもしれません. これは、設計、アーキテクチャ、または実装の重大な欠陥を洗い流すのに役立ちます。
しかし、すべてのバグを見つけることを期待して、すべてのレポートについて考えられるすべての組み合わせをテストしようとすることは不可能です。アジュダムの提案は理にかなっていて、必要な「妥協」の典型です。時間、リソース、そして状況に最も適した方法がすべてです。
したがって、この 2 つのハイブリッドをお勧めします (ごく少数のレポートを選んで大規模なテストを行いますが、他のレポートと共有される可能性のあるバグを見つけることに重点を置いていることを確認してください)。次に、ajdams などの手法を使用して個々のレポートをテストします。
テストが速度と信頼性に追いつくのに本当に役立つのは、レポートの必要な機能を構成するテスト スクリプトを実際に準備することです。前に提案したように、ユーザーのベータ グループは、ベータ テスト中にバグや設計上の欠陥に追いつくのに役立ちます。