This first in this series of articles describe foundational steps that enable agile data warehouse development \u2013 something that has been a challenge in enterprise data management for years.\u00a0 My prior articles published thus far describe how to develop a business conceptual model as a starting point, building a \u201cgrass roots\u201d (at a minimum) data governance capability, and developing a high level data flow architecture.\n\nThe next focus for setting yourself up for a best in class agile data warehouse environment is to develop a solid testing approach and tools before actual development begins.\n\nWhy test? \n\nThe data warehouse will be a strategic enterprise resource and heavily relied upon.\n\nOne of the weaknesses we have in the data community is testing, which helps to explain the data quality challenges we continue to suffer in production data warehouses.\n\nGartner predicts that by 2017, 33 percent of Fortune 100 companies will experience information crises due to their inability to adequately value, govern and trust their enterprise information. A robust testing approach can help avert (or at least minimize) such a crisis.\n\nDeveloping a well-planned and executed end to end data warehouse testing process can help you avoid serious data related risks. When moving to agile development, we have the opportunity to do significantly more testing than what typically occurs in traditional projects. \n\nWe can do:\n\n\u2026 and we do this with every user story, or every logical grouping of user stories.\n\nAs we move into agile data warehouse development, we create a certain rhythm of activities:\n\nThe QA tests are created in development, then move to the QA\/UAT environment, then move to the prod environment. As a result, we have a robust automated regression testing capability within each environment. Test cases can also run nightly in production for continuous quality monitoring. This will then feed into our data quality capabilities, since the testing can be run on a frequent basis to ensure consistent quality.\n\nTo ensure that a strong test practice is followed, we would put a standard set of tasks into most user stories:\n\nThe automated data validation tool we implemented can use the same tests for unit testing, integration testing, regression testing and ongoing data quality monitoring in production.\n\nThe testing developed during development in parallel facilitates agile development, since development and testing can be completed in a single sprint. By running both ETL and test cases in parallel, mismatches in results can point to an ETL code defect, a test case code defect, or a defect in our source to target specs.\n\nImplementing a robust testing capability was a lesson learned for my team as we started data warehouse development. Initially, our QA team manually tested each user story after the two week sprint, and after development \/ unit testing was complete. There were several challenges with this approach.\n\nOnce we started parallel development and testing in a single sprint, we were able to focus on the same set of user stories, and also develop re-usable testing capabilities.\n\nHowever, it took us a long time to recover from this oversight. We had a long list of user stories that did not have re-usable tests developed. We took the time to develop these over the course of several months. We also made the commitment to parallel develop all future user stories so that we didn\u2019t accumulate technical debt in this area in the future. Once we made that commitment, we found that we were able to move into a very efficient, and agile, development cycle.\n\nAdditional steps in building this foundational approach to agile data warehouse development include: \n\nI will cover these remaining steps in the next few upcoming articles.