Quality assurance in the data warehouse does not start with testing, but with understanding the requirements. A business analyst with a testing background recognizes borderline cases early on, questions half-finished solutions from the business department and gives testers the technical understanding they need to challenge the specification itself, not just the code.
Key Takeaways
- Business analysts who come from testing recognize edge cases and gaps in requirements earlier because they are used to actively questioning specifications instead of accepting them as truth.
- Testers should actively challenge specifications from business analysts, because even business analysts make mistakes, and those who lack domain understanding can only test technically.
- Synthetic, technically specified test data sets cover new structures and constellations more reliably than production data that is not prepared for the changes to be tested.
- Job rotation, i.e. switching to the role of another discipline for two to three months, improves mutual understanding and has a direct effect on the quality of daily work.
Testers check whether something is right. Business analysts determine what should be right
The difference between testing and analysis can be summed up in one sentence: A tester looks to see if something is right. A business analyst says what should be right. This is a gross oversimplification, but it gets to the heart of both roles.
Those who switch from testing to analysis take with them a way of thinking that is often lacking in pure requirements work. Testers think in borderline cases. They look closely at the places where specifications break. This view helps when formulating requirements because it makes gaps visible before code is written.
Philipp Huber, who switched from software tester to business analyst in a data warehouse project for a large banking group, describes testing and analysis as two sides of the same coin. In agile teams, where tasks are distributed as required and t-shaping counts, it helps to know both sides: Methodology, tools and the product from both a testing and analysis perspective.
Why testers need to question the specification
Testers should not treat the business analysts’ specifications as truth. However, this is exactly what often happens: a data mapping is specified in this way, so the mappings are considered to be set. If something else comes out at the end, testers look for the error in the code or in their own test case, not in the specification.
Business analysts also make mistakes. That is why it is important that testers challenge the specification instead of blindly testing it. If a tester does not do this, only a purely technical test remains, and that is not enough.
Testers need a technical background to be able to challenge at all. In a banking warehouse, many fields look like a data tomb: they exist, but what they are good for remains unclear. Without knowledge of the meaning of the fields and the relationships between the entities, nobody can meaningfully check whether a result is correct.
It is very important to me that testers question the specification. But to do this, they need to know the background. If it’s a data graveyard for me and I have no idea what the fields are used for, then I can’t challenge it. Philipp Huber
Challenging requirements early on saves ballast later on
The greatest leverage effect on quality lies before the first line of code. Departments often do not come with a requirement, but with a half-finished solution that they have already come up with. This solution is often not what is really needed.
This is where the work of the business analyst comes in. Instead of adopting the solution they have brought with them, they ask back: What exactly do you need? Don’t think about what the solution should look like, but say what you want to achieve. In an environment with two warehouses with different focuses, it often turns out that elaborate data flows across both systems are not necessary and that many things can be done more simply.
If you skip this clarification, you build solutions on top of solutions. The requirement is already the finished solution, it is implemented and the next one is grafted on top. The architecture becomes confusing and no longer corresponds to a clear principle.
This is particularly serious in the warehouse. What is dragged along once can hardly be removed later. It is therefore better to make an effort at the beginning than to drag ballast along for years.
The same thing, twenty views: Standardization is analysis work
Different departments have different views for the same concept, but the warehouse needs one. A typical example is the classification of customers. Twenty different ways of classifying a customer can come together in a single project, from retail customers to large business customers.
Twenty parallel customer type attributes in the warehouse are of no use to anyone. The business analyst’s job is to talk to the specialist departments and standardize these views as far as possible before they become a permanent structure in the warehouse.
How structured requirements work is in practice
A uniform, central process for requirements often does not exist in large organizations. The recording process varies from department to department, sometimes better, sometimes worse. In practice, Excel lists with the required fields dominate, supplemented internally by in-house tools for tracking.
A group-wide business data model can provide orientation, but is only effective if the departments adhere to it. For some it is the description of their business, for others it is an appendage that someone in the warehouse has come up with. In a large company, the result remains inconsistent.
The shift from classic waterfall projects to agile working also changes the mindset, but does not automatically resolve the inconsistency. Anyone who confuses agility with a lack of structure is missing the point. Agility is not a license for a mess.
Test data for new structures is the real problem
There is no usable test data for new fields and new entities because the structures are still being developed. Such changes can hardly be tested with productive data, as this data was never prepared for the planned changes.
The manual solution of adding or changing individual records costs time and effort each time and is difficult to maintain. If you want to run the same test cases six months later on a different data set that is closer to production, it will no longer work properly.
There is also a visibility problem. A table with ten million data records says nothing about whether all the required constellations are covered in it. This is particularly difficult to find out with new data.
Business-based test cases that run everywhere
The most effective approach is isolated test cases that map individual data constellations and can be deployed at any time. Instead of searching through a forest of millions of production records, you describe the specific scenarios you want to test.
In one specific case, this approach was implemented using Excel macros and Quality Center. The technology was rustic, but the result worked. This is how the workflow worked:
| Step | What happens |
|---|---|
| Enter constellation | Data constellations are recorded in an Excel sheet, related entities can be copied as a test set |
| Define Expected Result | The same sheet is used to record how a consuming application expects the data |
| Load data | An Excel macro writes the entries directly into the staging area, from where they are loaded into the core by the warehouse |
| Automatically compare | Quality Center test cases check the expected result against the actual output of the last route |
The approach automates two things at the same time: generating the test data from the manually specified test cases and checking the output. The core issue is whether the transformation is correct, i.e. whether data that arrives in one structure appears correctly in another structure in the consumer system.
Excel as a basis has clear limits. Different versions of a file are sent via file shares and emails, which is not a permanent solution. However, the workflow itself is sustainable and can be implemented in the same way with better tools.
Acceptance beats elegance when it comes to tools
A test data approach is useless if the departments don’t accept it. This was precisely the strength of the Excel solution: the department was able to create test data directly because Excel is the tool they are used to.
For someone who works with Excel, formulas and copying test sets are a matter of course. Familiarizing yourself with a foreign special tool would be a hurdle. Excel is the comfort zone and increases acceptance.
The best tool is useless if people don’t understand and accept it. This solution was born out of necessity, because the existing tools were unable to cope with too many new structures and there was no time for extensive tool research.
Productive data and synthetic data should be combined
No single approach covers everything. In practice, a combination has proven its worth: specific test cases for the most important functionality, supplemented by regression on production-related data.
A large part runs via regression with anonymized production data. A baseline from production-related data is compared with the previous release in order to find unexpected deviations. The catch is in the detail: If a deviation occurs, you need to know whether it was expected.
This is exactly where pure production data testing fails. This data is not prepared for the planned changes. This is why additional targeted, synthetic data sets are needed to cover the central functionality, while the regression ensures that everything fits together in the end.
AI as a source of inspiration for test scenarios
Generative AI can suggest test scenarios, but cannot deliver them one-to-one. If you describe structures and ask a language model for possible test cases, you will get useful suggestions that can be used as a starting point.
A business analyst can provide testers with concrete scenarios without formulating every edge case down to the last detail with expected results. This detailed work remains the task of the tester. The input sets the direction, the testing side takes care of the elaboration.
Put on the other person’s shoes
The most effective tip for a better quality view is a temporary change of role. If you do someone else’s work for two to three months, you will see the world with different eyes afterwards.
Nobody becomes a perfect tester or business analyst in three months. But you can see what is important. This applies in both directions and can be taken further: a business analyst who sits down for a few months with the department that depends on the warehouse will then have a better understanding of why things are the way they are.
This understanding has a direct impact on the quality of the work. Those who remain curious and step out of their own box take more from external tasks than someone who only fulfills their own role to the best of their ability. It is precisely this change of perspective that lies at the heart of agile working.
