Arrange, Act, Assert - The Strategy for BI and Data Warehouse Testing
Newsletter
Join our blog
Join other Azure, Power Platform and SQL Server pros by subscribing to our blog.


-1.png)
Start with the FREE community plan and get your lifetime access to 20+ courses. Get Instant Access Now!
Need help? Talk to an expert: (904) 638-5743
Private Classes
Private deliveries of courses for groups
On-Demand Learning
Beginner to advanced classes taught by Microsoft MVPs and Authors.
Bootcamps
In-depth boot camps take you from a novice to mastery in less than a week.
Season Learning Pass
Get access to our very best training offerings for successful up-skilling.
Stream Pro Plus
Combine On-Demand Learning platform with face-to-face Virtual Mentoring.
Certification Training
Prepare and ace your next certification with CertXP.
Cheat Sheets
Quick references for when you need a little guidance.
Prag Guides
Explore our knowledge base for quick tips on syntax, functions, and more!
Downloads
Digital goodies - code samples, student files, and other must have files.
Blog
Stay up-to-date on all things Power BI, Power Apps, Microsoft 365 and Azure.
Community Discord Server
Start here for technology questions to get answers from the community.
Career Guides
Breaking into the field? Let these guides help get you started with a plan.
Nerd Guides
Summaries developed in conjunction with our Learn with the Nerds sessions.
Quickstarts
Hands-on training with expert-led collaborative development.
Private Training
Personalized approach for your specific training requirements
Hackathons
Use your own data to take your team's skills to the next level.
Virtual mentoring
Get there faster with your personal trainer.
Enablement
Comprehensive enterprise enablement training for your team.
Admin Hackathon
Tame your power platform environment.
There's a lot of talk about the need for BI and data warehouse testing to identify and fix bad data out there. What is the real purpose of BI and data warehouse testing? The purpose of data testing is to identify defects, which will add the new challenge of remediating the error. Who in your organization should be responsible for this?
In this installment of our Real-World Data Testing series, I discussed this issue with our consultant, Jessica Dzurek. Data testing can be a double-edged sword – you implement a test that performs as expected by finding a failure in your result, but now you must dig in and find out why it failed.
In a previous video/blog in this series, consultant Brad Gall pointed out that when companies begin to do BI and data warehouse testing, a crucial step is the need to plan for the time required to remediate found defects.
Here, we discuss how to create a process or plan for failures and defects.
Documentation is also key. A method that Jessica uses on-site is the defect process of reviewing, assessing and assigning.
1. Review – When a failure occurs, you want to review it, identify the problem, and check to ensure there’s enough information from the tester, so the developer can understand what the problem is.
2. Assess – Dive into the failure and troubleshoot to determine if the problem is masking an underlying problem. Investigate and collect information to prepare for a root cause analysis later.
3. Assignment – Meet with people from the development team, your QA group, architect and a business stakeholder to talk through the defect found. Be sure they understand the failure and establish severity and priority of the failure.
This process gives you a definitive plan, but will likely add time to your development cycle. Some failures may take hours to understand the root cause. To manage this, you also need to have a resource plan in place. Define the rules and responsibilities of your team so developers or QA engineers are clear of where their liability and responsibility role ends.
You may want to set up a Time Box for more time-consuming scenarios. For example, define that a QA engineer will spend up to four hours doing an initial assessment/investigation of a test failure. They will document their findings and pass them on at a defect meeting with developers, business stakeholders and architects to determine the next steps.
It's also important to have a clear level of severity defined—"this is something we can live with" vs. "there’s no moving forward until it’s fixed". A final thought, documentation and communication is key. Errors that make it into production are much more costly than those found in development.
So, data testing takes time and planning, but it’s time well spent as bad data affects all areas of your business. We have the tools, training and services available to help you integrate data testing. Join us on our mission to stop bad data.
ABOUT THE AUTHOR
Tim Moolic is the COO of Pragmatic Works. He has more than 20 years experience executing sales, marketing and alliance strategies for software and consulting companies. Tim founded his first software and consulting business in 1996 and has worked with a wide range of enterprise software solutions including systems management, automated testing, database and online collaboration tools.
Free Trial
private training
Newsletter
Join other Azure, Power Platform and SQL Server pros by subscribing to our blog.
Leave a comment