Perspective on Business Intelligence (BI) Testing

Let me share my high level perspective on Business Intelligence (BI) Testing, or more specific: Extract-Transform-Load (ETL) Testing.?I try to look at 3 essential dimensions to work on (long term) in order to facilitate the testing during the sprint (short term).?

1. Product:

?? Get insight in the infrastructure, the flow of the data and which tools are being used from the beginning untill the end. You need to recognise the bottlenecks, complex and/or risky parts and big hubs, so you can give them explicit attention during testing.

?? Use automation for Unit Testing up front. Check on basic things like integrity (dates, timelines, duplicates, data present, etc.) or standards (date formats, notation, etc.). This is important to speed up the process to get to a certain level of quality of your developed feature.

?? Use automation to test on Regression afterwards. This is important to get grip on the bigger picture and a more controlled release.?

2. Data:

Start with a small dataset to run early and often at the start of development, you’ll create a predictable situation. It should be maintainable and 'fast'. It will probably be the basis for future scenarios.

?? Create a small but complete as possible testdataset. This will cover as many scenarios as possible.

?? Have a small set of production data, if possible, to cover at least some production dynamics.Later on, when the developed feature is more mature and bugs are less expected, raise the volume of production data. Ideally, check the processing and outcomes via automation.?

3. Value stream:

Testing (quality) is a team effort; work together towards a controlled situation.

?? Work as team on features: functional pieces, part of a product goal. Use a work breakdown structure to create small, full (so testing incl.!), work items to complete the feature. It is a team responsibility to complete the features according to the team/department standards (DoD).

?? Tip: Create a dependency map to show the dependencies and desired sequence of these work items. This will give insight in your coming sprint work.

?? Make the testing visible and the tooling accessible for the whole team, to facilitate the team responsibility.

?? Have a team shared understanding of the value stream: the steps to be taken to get features done and at the end customer.?

Having these three blocks in place, makes you flexible in your testing. There is an overall transparent HOW. Tools & testdata will support getting to a certain level of quality quickly. You can focus as team during the sprint on the WHAT and tailor your testing to it.?

Having set this base, it’s easy to continuous improve it after gaining new insights or in case of new functionality.

Any thoughts?