Testing For Dwh
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Testing For Dwh as PDF for free.
More details
- Words: 1,847
- Pages: 6
Testing for DW/BI Current State and a Peep into the Future Just as with any other software application involving different technologies (such as the mainframe, Java or Microsoft), testing is a very crucial phase in the software development lifecycle for data warehouse/ business intelligence (DW/BI) projects. Testing for DW/BI carries unique challenges and requires specialized approaches. However, the testing function for this highly dynamic technology area is at a very nascent stage of maturity. This article discusses the various aspects associated with testing for DW/BI.
Testing for DW/BI Why and how is testing for DW/BI different from testing for other technologies? Part of the answer lies in definition of what constitutes DW/BI. BI may be defined as "the result of indepth analysis of detailed business data; includes database and application technologies as well as analysis practices."1 BI is a broad category of application programs and technologies for gathering, storing, analyzing and providing access to data to help enterprise users make better business decisions. A DW is a collection of data designed to support management decisionmaking. According to Bill Inmon, a DW is a "subjectoriented, integrated, timevariant, nonvolatile collection of data in support of decisionmaking." DWs tend to have these distinguishing features: •
Use a subjectoriented dimensional data model,
•
Contain publishable data from potentially multiple sources, and
•
Contain integrated reporting tools.
A typical DW/BI project can be viewed as comprising two broad components: constructing the DW using extract, transform, load (ETL) technologies and presenting of the same for analysis purposes with online analytical processing (OLAP) technologies.
Figure 1: DW/BI Project Components The success of a DW/BI program lies in meeting its key objective of ensuring data accuracy (DW construction) and providing a single version of the truth through flexibility in analysis/reporting (presentation). This presentation layer is often extended by features such as flexibility and enhanced visualization.
It is a common best practice for any DW/BI initiative to define the level of data accuracy expected (also known as tolerance level) from the DW; needless to say, this varies from application to application. For example, in a DW for sales analysis, accuracy of approximately 95 percent is acceptable; whereas, in the case of a DW for fraud analysis in a stock exchange, the accuracy levels expected could be higher than 99 percent. It is pertinent to note here that any testing activity has to be focused on the program's key objective and ensuring that this objective is met by the application. In order to achieve these critical success factors (e.g., data accuracy and consistency in reporting/analysis), data in a typical DW architecture passes through several steps of consolidation.
Figure 2: Data Consolidation in a DW Architecture Data passes through several processes of churning across the various layers depicted in Figure 2. The root cause for data inconsistency and/or inaccuracy can occur in any of these layers, resulting in an adverse impact to the program's primary objective. Examples of data errors include: •
Large volume of duplicate data or incomplete data extracted from source systems
•
Incorrect cleansing (e.g., use of incorrect codes)
•
Incorrect aggregation techniques resulting either in the Cartesian product or data being dropped due to incorrect join conditions
•
Incorrect mapping of dimensions in the cube
•
Combination of any or all of the above.
Unlike other applications where testing is focused on user interfaces, due to the criticality of data, multiple phases of data transformation and potential areas for introduction of data consistency or accuracy issues, testing for DW/BI has to be more detailoriented; moreover, it calls for a thorough understanding of ETL and OLAP concepts and the underlying technologies on the part of the testers.
Challenges There are many challenges to the development of the specialized skills required for DW/BI testing:
•
Unwillingness on the part of DW developers. Any IT professional planning to build a career in this exciting field aims to be an expert ETL developer, OLAP specialist, dimensional data
modeler or DW architect; DW tester doesn't even make the list of desirable roles. This is true, by and large, of professionals across the globe and not necessarily a local factor applicable only to certain countries. The general perception that only such roles carry premium rates in the job/consulting market (and worse, sometimes a perception that only such roles get to face the technical challenges associated with a DW/BI project), has left the DW/BI project team with very few takers for the challenging and critical role of tester.
•
Lack of awareness. As a general practice, testers plan their career in such a way that they specialize and equip themselves with technical skills for the tools involved in test execution (e.g., Winrunner, SilkTest) and/or test management (e.g., QualityCenter), with very little endeavor to develop skills in the underlying technology. A good understanding of ETL/OLAP tools and technologies is an essential skill for DW/BI testing and, so far, testers have not developed a keen interest in this skill.
•
Absence of tools. The DW/BI marketplace is flooded with many tools and vendors, each attempting to replace the other in the three layers of DW/BI: database, ETL and OLAP. There are no popular ETL/OLAP testing tools in the market that offer features for automated testing or functional testing. In the absence of such tools, it is highly impractical to achieve toolbased requirements traceability throughout the lifecycle or impact analysis. Of course, some of the advanced ETL tools offer addon products that provide insights into their metadata (e.g., Metastage) and provide impact analysis within the ETL function, but their usability for traceability is yet to be explored.
•
Lack of standard approach/methodology. While standard methodologies exist for testing as a whole, there seems to be no industrywide view on the suggested approach and/or methodology for DW/BI testing. An ideal methodology should include a test strategy, a test plan and test cases that cover thorough testing of the various phases of data movement (see Figure 2.) Creating test cases and test data that provide adequate coverage to each of the phases is very critical for ensuring a comprehensive quality assurance (QA) of the DW. A sample/suggested template to track data as it progresses through the phases is given in Figure 3.
Figure 3: Test Case Tracking Template
Expectations from the IT Industry Listed below are some initiatives that can provide the muchneeded boost to this critical function.
•
Promote awareness within the DW community that DW/BI testing is a challenging proposition requiring highly valued skills, thereby encouraging ETL and BI developers to assume these roles. Moreover, leading IT players with extensive experience in the DW/BI area should promote welldefined career options and career progression plans to the ETL/OLAP developers and conventional testers.
•
Invest in research to formalize methodologies covering the entire spectrum of DW/BI testing in full detail.
•
Invest in building assets, tools and job aids to strengthen this function and provide productivity gains.
•
Develop training courses and course content to crosstrain ETL/OLAP developers in testing nuances and testers in DW and ETL/OLAP tools and technology concepts.
•
Build strong testing teams with complimentary skills.
Suggested Framework It is essential to define a framework that carries the extent, scope and approach to DW/BI testing. Figure 4 depicts a suggested framework.
Figure 4: A DW/BI Testing Framework
The Figure 4 framework would be comprised of assets/job aids that facilitate efficient planning and execution of DW/BI testing, such as: •
SQL queries against source and target databases (varying)
•
SQL queries to compare data at each stage of transformation (varying)
•
Custombuilt, reusable test utilities (e.g., Excel macros) to populate data from source systems and reports, automate comparison and flash data errors. Such utilities have the following advantages: •
Reduction in human errors of omission in identifying data mismatches.
•
Productivity enhancement
•
Reusability across different stages and objects
•
Templates to track defects/test results (sample given in Figure 3)
•
Test artifacts test strategy, test plan and test cases; a common and largely reusable templates of these documents can prove handy in gaining speed in initiating testing for new functional areas/reports/projects.
Future Expectations In its current state, the DW/BI landscape is flooded with many small, medium and large tool vendors, each claiming to provide the best technology and/or solution for endtoend DW/BI implementation. With a few exceptions (e.g., SAS in analytics, Abinitio in ETL), tool vendors lack sight of the need for specialization in the three specific layers of DW/BI (e.g., database, ETL and OLAP). As a result, every vendor is trying a combination of strategies mergers and acquisitions or expanding into other territories, to gain space into every spectrum of DW/BI. Coupled with this, there is a sheer lack of standards and interchangeability in the use of metadata, underlying ETL code or OLAP definitions. The common warehouse metamodel (CWM) is a specification that describes metadata interchange among data warehousing, business intelligence, knowledge management and portal technologies.2 However, the CWM is far from adoption, in the real and true sense, by any of the popular tool vendors. Use of an industrystandard metadata format and its exchange across different architectural layers is extremely restricted; it is best achieved only within the specific family of tools from the same vendor. The above challenges have also contributed to factors such as: •
Absence of any independent tool vendor venturing to build and offer DW testing tools.
•
Lack of standards (metadata exchange) that do not encourage leading testing tool vendors (e.g., Mercury Interactive) to foray into this space.
•
Even the existing pure ETL/BI tool vendors have been focused only on consolidation and/or entry into either of the areas, without focusing on the need to build testing tools.
However, the market is expected to witness, in the next couple of years, a large consolidation exercise likely to leave a handful of large technology players offering endtoend technical solutions. Such a consolidation is expected to facilitate adoption of metadata standards and also bring about the muchneeded focus on developing complementary tools and technologies, the most critical of them being tools for DW/BI testing, independent of the vendor/ETL/OLAP tools. Such development is also likely to spin off parallel intellectual thoughts among the IT services providers; large
IT services firms are expected to focus their innovation in evolving DW/BI testing methodologies and best practices, leveraging the use of these tools. In summary, the criticality and importance of DW/BI testing can never be overemphasized. Testing for DW/BI is a niche skill that demands a good blend of ETL/OLAP technical skills (or the least a good understanding of them) and thorough testing skills. Unlike other technologies, there are no tools currently available that can be used for DW/BI testing. In the absence of such tools, it is essential to define and develop a framework for DW/BI testing that comprehensively covers the various layers and stages of data transformation. IT services firms need to encourage their work force to adopt this as a preferred skill and promote ways to advance these skills. Consolidation of ETL/OLAP tool vendors could prove to be the beginning for development of DW/BI testing tools.
Testing for DW/BI Why and how is testing for DW/BI different from testing for other technologies? Part of the answer lies in definition of what constitutes DW/BI. BI may be defined as "the result of indepth analysis of detailed business data; includes database and application technologies as well as analysis practices."1 BI is a broad category of application programs and technologies for gathering, storing, analyzing and providing access to data to help enterprise users make better business decisions. A DW is a collection of data designed to support management decisionmaking. According to Bill Inmon, a DW is a "subjectoriented, integrated, timevariant, nonvolatile collection of data in support of decisionmaking." DWs tend to have these distinguishing features: •
Use a subjectoriented dimensional data model,
•
Contain publishable data from potentially multiple sources, and
•
Contain integrated reporting tools.
A typical DW/BI project can be viewed as comprising two broad components: constructing the DW using extract, transform, load (ETL) technologies and presenting of the same for analysis purposes with online analytical processing (OLAP) technologies.
Figure 1: DW/BI Project Components The success of a DW/BI program lies in meeting its key objective of ensuring data accuracy (DW construction) and providing a single version of the truth through flexibility in analysis/reporting (presentation). This presentation layer is often extended by features such as flexibility and enhanced visualization.
It is a common best practice for any DW/BI initiative to define the level of data accuracy expected (also known as tolerance level) from the DW; needless to say, this varies from application to application. For example, in a DW for sales analysis, accuracy of approximately 95 percent is acceptable; whereas, in the case of a DW for fraud analysis in a stock exchange, the accuracy levels expected could be higher than 99 percent. It is pertinent to note here that any testing activity has to be focused on the program's key objective and ensuring that this objective is met by the application. In order to achieve these critical success factors (e.g., data accuracy and consistency in reporting/analysis), data in a typical DW architecture passes through several steps of consolidation.
Figure 2: Data Consolidation in a DW Architecture Data passes through several processes of churning across the various layers depicted in Figure 2. The root cause for data inconsistency and/or inaccuracy can occur in any of these layers, resulting in an adverse impact to the program's primary objective. Examples of data errors include: •
Large volume of duplicate data or incomplete data extracted from source systems
•
Incorrect cleansing (e.g., use of incorrect codes)
•
Incorrect aggregation techniques resulting either in the Cartesian product or data being dropped due to incorrect join conditions
•
Incorrect mapping of dimensions in the cube
•
Combination of any or all of the above.
Unlike other applications where testing is focused on user interfaces, due to the criticality of data, multiple phases of data transformation and potential areas for introduction of data consistency or accuracy issues, testing for DW/BI has to be more detailoriented; moreover, it calls for a thorough understanding of ETL and OLAP concepts and the underlying technologies on the part of the testers.
Challenges There are many challenges to the development of the specialized skills required for DW/BI testing:
•
Unwillingness on the part of DW developers. Any IT professional planning to build a career in this exciting field aims to be an expert ETL developer, OLAP specialist, dimensional data
modeler or DW architect; DW tester doesn't even make the list of desirable roles. This is true, by and large, of professionals across the globe and not necessarily a local factor applicable only to certain countries. The general perception that only such roles carry premium rates in the job/consulting market (and worse, sometimes a perception that only such roles get to face the technical challenges associated with a DW/BI project), has left the DW/BI project team with very few takers for the challenging and critical role of tester.
•
Lack of awareness. As a general practice, testers plan their career in such a way that they specialize and equip themselves with technical skills for the tools involved in test execution (e.g., Winrunner, SilkTest) and/or test management (e.g., QualityCenter), with very little endeavor to develop skills in the underlying technology. A good understanding of ETL/OLAP tools and technologies is an essential skill for DW/BI testing and, so far, testers have not developed a keen interest in this skill.
•
Absence of tools. The DW/BI marketplace is flooded with many tools and vendors, each attempting to replace the other in the three layers of DW/BI: database, ETL and OLAP. There are no popular ETL/OLAP testing tools in the market that offer features for automated testing or functional testing. In the absence of such tools, it is highly impractical to achieve toolbased requirements traceability throughout the lifecycle or impact analysis. Of course, some of the advanced ETL tools offer addon products that provide insights into their metadata (e.g., Metastage) and provide impact analysis within the ETL function, but their usability for traceability is yet to be explored.
•
Lack of standard approach/methodology. While standard methodologies exist for testing as a whole, there seems to be no industrywide view on the suggested approach and/or methodology for DW/BI testing. An ideal methodology should include a test strategy, a test plan and test cases that cover thorough testing of the various phases of data movement (see Figure 2.) Creating test cases and test data that provide adequate coverage to each of the phases is very critical for ensuring a comprehensive quality assurance (QA) of the DW. A sample/suggested template to track data as it progresses through the phases is given in Figure 3.
Figure 3: Test Case Tracking Template
Expectations from the IT Industry Listed below are some initiatives that can provide the muchneeded boost to this critical function.
•
Promote awareness within the DW community that DW/BI testing is a challenging proposition requiring highly valued skills, thereby encouraging ETL and BI developers to assume these roles. Moreover, leading IT players with extensive experience in the DW/BI area should promote welldefined career options and career progression plans to the ETL/OLAP developers and conventional testers.
•
Invest in research to formalize methodologies covering the entire spectrum of DW/BI testing in full detail.
•
Invest in building assets, tools and job aids to strengthen this function and provide productivity gains.
•
Develop training courses and course content to crosstrain ETL/OLAP developers in testing nuances and testers in DW and ETL/OLAP tools and technology concepts.
•
Build strong testing teams with complimentary skills.
Suggested Framework It is essential to define a framework that carries the extent, scope and approach to DW/BI testing. Figure 4 depicts a suggested framework.
Figure 4: A DW/BI Testing Framework
The Figure 4 framework would be comprised of assets/job aids that facilitate efficient planning and execution of DW/BI testing, such as: •
SQL queries against source and target databases (varying)
•
SQL queries to compare data at each stage of transformation (varying)
•
Custombuilt, reusable test utilities (e.g., Excel macros) to populate data from source systems and reports, automate comparison and flash data errors. Such utilities have the following advantages: •
Reduction in human errors of omission in identifying data mismatches.
•
Productivity enhancement
•
Reusability across different stages and objects
•
Templates to track defects/test results (sample given in Figure 3)
•
Test artifacts test strategy, test plan and test cases; a common and largely reusable templates of these documents can prove handy in gaining speed in initiating testing for new functional areas/reports/projects.
Future Expectations In its current state, the DW/BI landscape is flooded with many small, medium and large tool vendors, each claiming to provide the best technology and/or solution for endtoend DW/BI implementation. With a few exceptions (e.g., SAS in analytics, Abinitio in ETL), tool vendors lack sight of the need for specialization in the three specific layers of DW/BI (e.g., database, ETL and OLAP). As a result, every vendor is trying a combination of strategies mergers and acquisitions or expanding into other territories, to gain space into every spectrum of DW/BI. Coupled with this, there is a sheer lack of standards and interchangeability in the use of metadata, underlying ETL code or OLAP definitions. The common warehouse metamodel (CWM) is a specification that describes metadata interchange among data warehousing, business intelligence, knowledge management and portal technologies.2 However, the CWM is far from adoption, in the real and true sense, by any of the popular tool vendors. Use of an industrystandard metadata format and its exchange across different architectural layers is extremely restricted; it is best achieved only within the specific family of tools from the same vendor. The above challenges have also contributed to factors such as: •
Absence of any independent tool vendor venturing to build and offer DW testing tools.
•
Lack of standards (metadata exchange) that do not encourage leading testing tool vendors (e.g., Mercury Interactive) to foray into this space.
•
Even the existing pure ETL/BI tool vendors have been focused only on consolidation and/or entry into either of the areas, without focusing on the need to build testing tools.
However, the market is expected to witness, in the next couple of years, a large consolidation exercise likely to leave a handful of large technology players offering endtoend technical solutions. Such a consolidation is expected to facilitate adoption of metadata standards and also bring about the muchneeded focus on developing complementary tools and technologies, the most critical of them being tools for DW/BI testing, independent of the vendor/ETL/OLAP tools. Such development is also likely to spin off parallel intellectual thoughts among the IT services providers; large
IT services firms are expected to focus their innovation in evolving DW/BI testing methodologies and best practices, leveraging the use of these tools. In summary, the criticality and importance of DW/BI testing can never be overemphasized. Testing for DW/BI is a niche skill that demands a good blend of ETL/OLAP technical skills (or the least a good understanding of them) and thorough testing skills. Unlike other technologies, there are no tools currently available that can be used for DW/BI testing. In the absence of such tools, it is essential to define and develop a framework for DW/BI testing that comprehensively covers the various layers and stages of data transformation. IT services firms need to encourage their work force to adopt this as a preferred skill and promote ways to advance these skills. Consolidation of ETL/OLAP tool vendors could prove to be the beginning for development of DW/BI testing tools.
Related Documents
Testing For Dwh
May 2020 2
Dwh Testing
May 2020 4
Dwh Testing
May 2020 14
Dwh
July 2020 7
Satyam Dwh
May 2020 1