So, you’ve got a green thumb. You’ve been growing houseplants your whole life. Now try to grow an orchid. What you’ve learned about houseplants has taught you very little about orchids.
- Put one in soil and you’ll kill it (orchids grow on rocks or bark).
- Orchids need about 20 degrees Fahrenheit difference between day and night.
- Orchids need wind and humidity to strive.
- Orchids need indirect sunlight. Lots of it. But put them in the sun and they’ll burn.
- Fading flowers does not mean your orchid is dying (orchids bloom in cycles).
So, you’re a skilled tester. You’ve been testing functional applications with user interfaces your whole career. Now try to test a data warehouse. What you’ve learned about functionality testing has taught you very little about data testing.
- “Acting like a user”, will not get you far. Efficient data testing does not involve a UI and depends little on other interfaces. There are no buttons to click or text boxes to interrogate during a massive data quality investigation.
- Lack of technical skills will kill you. Interacting with a DB requires DB Language skills (e.g., TSQL). Testing millions of lines of data requires coding skills to enlist the help of machine-aided-exploratory-testing.
- Checking the health of your data warehouse prior to deployments probably requires automated checks.
- For functional testing, executing shallow tests first to cover breadth, then deep tests later is normally a good approach. In data testing, the opposite may be true.
- If you are skilled at writing bug reports with detailed repro steps, this skill may hinder your effectiveness at communicating data warehouse bugs, where repro steps may not be important.
- If you are used to getting by as a tester, not reading books about the architecture or technology of your system-under-test, you may fail at data warehouse testing. In order to design valuable tests, a tester will need to study data warehouses until they grok concepts like Inferred Members, Junk Dimensions, Partitioning, Null handling, 3NF, grain, and Rapidly Changing Monster Dimensions.
Testers, let’s respect the differences in the projects we test, and grow our skills accordingly. Please don’t use a one-size-fits-all approach.