{"id":1716,"date":"2020-04-08T08:03:19","date_gmt":"2020-04-08T15:03:19","guid":{"rendered":"https:\/\/www.lightsondata.com\/?p=1716"},"modified":"2020-04-29T10:24:53","modified_gmt":"2020-04-29T17:24:53","slug":"regression-testing-on-dw-bi-projects","status":"publish","type":"post","link":"https:\/\/www.lightsondata.com\/regression-testing-on-dw-bi-projects\/","title":{"rendered":"What you need to know about regression testing on DW\/ BI projects"},"content":{"rendered":"

Regression testing on large data integration DW\/BI development projects is challenging. The number of test cases is often massive and many change impacts may be widely spread. For high-level integration regression testing, the retest-all approach is always time and resource consuming.<\/p>\n

To counter challenges with regression testing, this article proposes test scenarios based on changes to ETL logic and data. Selected test scenarios should be semi-formal representations of detailed system requirements with their test inputs, outputs, and conditions defined. By using test dependency information, the QA team can use a test slicing algorithm that identifies the scenarios that are affected and thus are candidates for regression testing.<\/p>\n

 <\/p>\n

What is regression testing?<\/h2>\n

Following are three ways of understanding regression testing:<\/p>\n

    \n
  1. Testing performed after developing functional improvements or repairs to data and BI reports. The purpose of those tests is to establish if changes haves regressed other attributes of data and reports.<\/li>\n
  2. A series of tests intended to show that the software\u2019s overall behavior is unchanged except as required by adjustments to the software or data.<\/li>\n
  3. Testing conducted for the purpose of evaluating whether specific changes to the system have introduced new failures.<\/li>\n<\/ol>\n

    Figure 1 shows domains of regression testing to be considered after changes to source data, DW data, ETL\u2019s, business logic, and business intelligence reports.<\/p>\n

    \"Common
    Figure 1: Common testing domains across the DW\/BI project lifecycle<\/figcaption><\/figure>\n

     <\/p>\n

    Common strategies for selecting regression test suites<\/h2>\n
      \n
    1. High priority and high-risk use cases.<\/strong> Choose baseline tests to rerun by risk heuristics – those with the most risk to data, reports, or dashboards when failing.<\/li>\n
    2. End-to-end operational profiles.<\/strong> Choose baseline tests to rerun by allocating time\/QA resources in proportion to operational profile risks (source extraction, data staging, data mart loads, etc.).<\/li>\n
    3. Business logic and\/or data changes.<\/strong> Choose baseline tests to rerun after assessing changes to code and data.<\/li>\n
    4. Select from existing test cases.<\/strong> Choose baseline tests for regression testing by analyzing dependencies and relationships with changed or added code.<\/li>\n<\/ol>\n

       <\/p>\n

      Recommended strategies for DW\/BI regression test planning<\/h2>\n

      Combine the four common strategies from above: Any one of the existing regression testing strategies above may be fine for your project, but in the real world, a combination of the four strategies, as described below, may be a better choice.It is assumed that first we test each change (fix) by running all related test cases. Then for regression testing:<\/p>\n

        \n
      1. 30% of regression tests:<\/strong> Tests representing the riskiest functions and data; in particular, those identified to be affected by changes. Among components for high priority, consider business risk and frequency of using the changed scenario by users.<\/li>\n
      2. 50% of regression tests:<\/strong> Run all tests planned for general regression testing.<\/li>\n
      3. 20% of regression tests:<\/strong> Exploratory Testing – Remember to properly document the results of exploratory testing. For those who not like the idea of \u2018exploratory testing\u2019, use the time in the schedule to improve your understanding of the requirements, the system, and your logical and architectural coverage of application by test cases then plan for exploratory testing.<\/li>\n<\/ol>\n

        Conventional allocations are 30%; 50% and 20%; other ratios of regression tests may work better for your project (see Figure 2).<\/p>\n

         <\/p>\n

        Percentage of regression tests<\/h3>\n

        Figure 2: Percentages of testing resources and time allocated to the three regression test strategies.<\/p>\n

        The selection of test cases for regression testing<\/h2>\n