As a trainer of the DAU-CDAT Training (Certified Data & Analytics Tester) people sometimes ask me questions about the training. Curious? Below you’ll find the Top questions.
Note: do you have a question yourself? Just let me know and I’m happy to answer (or to find someone who should know the anwer).
#1) I am a data engineer, not a tester. I am worried that I don’t understand the testing lingo. Should I worry?
No, that should not be a problem! In the world of Testing, people have different “dialects” when it comes to the testing terminology. Therefore, trainers will always make sure that everyone is on the same page, first. This will give you the opportunity to learn the terms that are used in CDAT. To get even more prepared, you could read ISTQB and/or TMap related books or take a training about testing in general.
#2) Will I learn to automate tests for a data centric environments?
As CDAT is a Foundation training, the focus will be on learning what to test, why to test this, how to elicit test cases (test design) and how to create a testing approach that you can use to report remaining risks in clear wordings to your client. The “how” question, specifically tools and test automation, will be tackled in (future) trainings in the DAU curriculum.
#3) Can I take the exam with Brightest without attending a training?
Yes, you can try and take the exam with Brightest without attending the training: DAU is not forcing you to attend the training before you can enter the exam (like some other certifications do). Please contact us for exam vouchers, should you decide to do so. Keep in mind that many attendees feel that the training adds value as they return to their work place with new concepts and practical tools. If that sounds good to you, then please take the time (2 days or 4 evenings) and join the training.
When dealing with data centric systems, e.g. when analyzing and testing data warehouse or business intelligence environments, you’ll probably come across various errors. These errors can be due to insufficient analysis of the source data, developing the wrong transformations or even by using the system in the wrong way. To explain and categorize these common mistakes, you’ll find a summary of common mistakes below.
Types of errors
Homonyms and Synonyms in columns/field names
Technical differences between systems
Wrong usage of source systems
Fields/Columns filled with technically correct values but not providing any real business
History issues
Wrong mappings
Wrong transformations
Homonyms/Synonyms
When various concepts are known under the same description, we call this a “homonym”. For instance, an “area” may be used to depict a quantity of a two-dimensional surface (e.g. measured in square meters) but it may also refer to a region (e.g. a neighborhood, borough or zone).
When two different names are used for the same concept, we call these “synonyms”. For instance, when analyzing concepts like “contact” and “client”, it is important to figure out if the meaning of the concepts are 100% identical or that slight differences apply, based on the usage in the source systems. E.g. for some departments, contacts may be treated as a customer only after they have actually put in their first order with the company.
When analyzing, building and testing interfaces between systems, data integration and reports, this is something to take a good look at.
Technical Differences between Systems
When transferring (loading, moving) data from one system to another and integrating these values, issues may arise due to technical differences between systems. In the design, development and test of the interfaces and data integration, this needs attention.
Character Sets
One example is the different implementation of treating characters, i.e. storing specific characters in a different way on the various systems. Computers are good at storing numbers (1’s and 0’s) but for storing texts, character sets were developed. These may be incomplete and not able to store all relevant characters – leading to simplifying texts. E.g. the ASCII character set is able to store “plain English” characters but to store all letters, punctuation and symbols of other languages, the Unicode character set is required.
Physical Storage of Data
Related to the issue above, is the difference in storing files on different systems like mainframes, Windows based system and a Unix/Linux based systems. Files may be treated in a different way where it comes to technical features like “end of line” characters and the way specific characters are stored.
Differences in Data Types
When storing data, you often get to choose from different data types, like character, numbers, dates and currencies. Various Database management systems (DBMS’s) and integration tools treat data types in different ways. These differences may be inherent to the system, others may be configured by technical staff. E.g. if a source system only supports storing text and target systems have ways to store numbers, dates and texts, some kind of transformation is needed. The analysis of the possibilities in the source systems is crucial: is “7,001” to be treated the same as “7.001”? Data profiling tools can be helpful. Make sure ask the right questions during review of the specifications, to test variations in the unit- and system tests and to have “rich” acceptance test sets that cover all kinds of different values in the source systems.
Wrong use in/of Source Systems
Users are extremely resourceful when it comes to using their tools (i.e. our source systems) in the most efficient manner. This will sometimes lead to using in a way it was not meant to, e.g. by filling “free format” fields with data that should have been stored elsewhere. Or by team A using field X in a different way than team B, making it difficult to analyze the data in that certain field (X).
Values are Technically Correct – but have low Business Value
When analyzing data sets, you may come across tables which contain a lot of “generic” of default values. Consider a table with customers having a column called “MarketSegment”. If most hold the value “99 Various Market Segments”, the business value of having such a field in a report is quite low.
When analyzing data in order to build meaningful reports, this should be mentioned to end users in an early stage – as they will probably record this as a finding or bug at the time of an acceptance test.
The following situation is even worse: when users decide to enter blanks or certain values like “X” or “0,0” in fields that should have been filled in a correct manner. In this case, the value is not only too generic (like with “99 Various Market Segments”) but plain wrong. If not addressed, it may lead to wrong business decisions. E.g. when car crashes are not registered on their precise location, due to users entering wrong geo locations, dangerous streets and crossings may not get improved in time.
History Issues
Some source systems are designed is such a way that only the current situation is stored, and does not retain “history”. Should history be required this may lead to (at least) two kinds of issues.
The first issue arises when end users get creative in storing information that they want to keep in fields that weren’t meant for this purpose, like in a “Remarks” field. Should data analysts overlook the data in this field, e.g. because the technical documentation says it’s “just for remarks”, this may lead to issues. Data profiling should be applied, to find out if these situations occur in the source systems. Even if the issue is addressed, retrieving the relevant data from such fields can be hard and error prone.
The second issue happens when there is uncertainty about the actual validity of a value, as the original values get overwritten in the source systems. Is the shown value “the latest value” or the “original value”? Input from the user community is required.
Note: A solution may consist of developers building a system for “change data capture” (CDC), registering each and every change in the source system and figuring out what to do with it based on technical and business rules.
In data warehousing, history is often kept by the use of Slowly Changing Dimensions type 2 (SCD2). Tables have columns added with a begin- and end date, showing the period in which the situation is valid. When an attribute changes value, a new row is added with a new begin date (and the old record gets “closed”). More variants of SCD exist, and when developing solutions based on SCD, errors can be introduced as well. Be sure to have a test plan in place to cover the basic situations when working with SCD.
CustomerID
Short Name
ValidFrom
ValidUntil
1
Dorsek
01-01-1980
14-02-2021
1
Dörsek
15-02-2021
<null>
2
Johnson
01-01-1980
<null>
3
Smith
01-01-1980
17-09-2020
3
Smith-Jones
18-09-2020
<null>
“Customers” table with SCD2 based History columns
Wrong Mappings
Mappings can be implemented in a wrong way, in many ways.
First, due to a human errors, columns may be mapped to other columns than intended (in the design). E.g. mapping “StudentName” in the student database to “BANKACCOUNT” instead of “LASTNAME”. Replacing the manual mapping with more automated mappings tackle many of these issues and many of the wrong mappings are easily discovered by a visual check. Should a mapping hold many similar fields, this may become more difficult, but even so: checking it is very valuable, as solving issues in Acceptance Tests are more costly than bugs that are found early in the process.
A second type of error does not concern mapping the actual fields, but concerns the contents of the fields. E.g. when mapping dates from TEXT and DATE fields to other DATE and DATETIME, extra attention is required from developers and testers. Does “20230305” stand for 3 May 2023 or 5 March 2023? Are DATETIME fields (e.g. “20230305000000”) actually holding date/time with much precision – or only the date?
If several systems hold similar values, these may be integrated, but small differences are lurking around the corner: if system A will store “sex” coded as 1 (male), 2 (female) and 0 (unknown and other) and system B will store texts “boy”, “girl”, “man”, “woman”, “military”, “disabled”, “other” and <blank>, then business rules will need to be applied to make sure that the data in Data Marts and reports will be meaningful.
Suggestions
This is just a limited number of issues that may occur. You’ll probably have found some of these, and others, yourself. Feel free to share your experiences and report issues that you’re experiencing in the field of data.
Due to the increasing demand for specialized education regarding testing of Data Warehouses (DWH), Business Intelligence (BI) and Analytics, we are hosting the unique training “Certified Data & Analytics Tester”.
Since the start of this training in 2018, we have welcomed many groups of (future) data & analytics testing consultants. The training is well received and we are proud of an average rating of 8/10!
At the end of this page, you’ll find the scheduled ‘open’ courses to which you can enroll. Would you rather participate as a group? You can also book an in-company course. Please contact us and we will answer your questions and/or help you to enroll in one of the courses.
Introduction
Today everybody recognizes the importance and added value of data for your Business model, if applied well. Whole Industries are changing: think of companies like Amazon, Uber, Netflix and Walmart.
Data is high-prioritized at more and more organizations strategy agendas. They hire (interim) professionals who can collect, analyze, model and visualize (Big) Data. Both these companies and their clients trust on reliable, complete, correct and on-time delivered information. Not just one time, but continually. Data professionals can provide this trust by using methods from the field of quality assurance and testing.
So, where to start? In this practical course you will get insights to a structured testing approach in complex Data & Analytics projects.
Set up
During this 2-day course at foundation level you will learn about Data & Analytics; what is it and how do to test in a Data & Analytics environment. This test method is based on international test-standards (ISTQB) with a specific and practical translation to a Data (Analytics) environment.
The course is set up in such a way that enables both data professionals and professionals to share ‘a common language’ regarding testing in Data & Analytics environments. Accordingly, the student will learn how to embed structured testing to reach and improve the quality goals. The course combines theory with practice and contains many exercises which connects the student with practice and delivers the most applicability.
Subjects
After this training, you will:
be able to define a vision and test strategy – and to translate it to an efficient test approach in data-oriented environments and -projects.
have become familiar with test specification techniques applicable to data & analytics projects.
be able to distinguish between different data quality attributes, measure these and you will be able to use data profiling techniques
have become familiar with the specifics of the test environments and privacy-aspects of data its usage in data & analytics testing projects..
Program
Day 1:
Towards a common Basis: Business Intelligence, Data warehousing en Data & Analytics
Testing and the Test Process
Risk Based Testing (RBT)
Tester’s Skills Matrix
Testing of Reports & Dashboards
Day 2:
Testing Transformations (ETL)
Testing Completeness of Data
Data Quality and Data Profiling
Test Environments
Privacy Aspects
Test tools
During the course, links between theory and practice are made and supported by examples of test plans, test design techniques and test reports according to ISTQB standards.
Requirements
No specific education and/or training is required. Affinity with IT and/or business knowledge of Data & Analytics is an advantage, like: Data Warehousing, ETL, Data Migrations, Business Intelligence or Analytics. Knowledge of ISTQB is an advantage but not required.
On the second day, attendees need to have access to a laptop with he possibility to install (open source) software.
Target Audience
The course is designed for test engineers, test coordinators, business analysts, data leads, data warehouse developers and BI-consultants.
Exam
The course can be concluded with an on line test (multiple choice), hosted by Brightest. An exam voucher will be provided. After successfully passing the exam, the attendee will be rewarded with the certificate ‘DAU Certified Data & Analytics Tester (Foundation Level)’.
Literature
At start of the course you will receive a copy of the slides, the syllabus/reader and several materials to support you during the course and in your daily practice.
Trainers
Armando Dörsek
Armando Dörsek is an ISTQB- and TMap® Next certified test manager. He has over 20 years of experience in ICT as a developer, coach and test consultant of which the last decade in Business Intelligence, Data Warehousing and/or Analytics focused environments. Recent clients were in the area of health insurance, banking, retail and government (tax, law enforcement). Projects are often large, complex and have a company-wide impact.
Rogier Ammerlaan
Rogier has been active for many years in the disciplines of software quality and agile development in financial institutions and more technical environments like greenhouse automation. After graduating on the topic of CMM he specialized in software testing, taking up several roles like tester, test coordinator and test manager in large (international) projects. Rogier is a near full time trainer in the field of testing and test improvement, scrum/agile and robotics.
Duration
2 days
Price
€ 1.195,- ex. VAT (including materials and one exam (€ 200,- ex. VAT))
Profiteer nu van de Black Friday Deal van Verified en ontvang je examenvoucher t.w.v. EUR 200,- helemaal gratisbij je inschrijving voor “Certified Data & Analytics Tester”.
Dit betekent dat je voor de tweedaagse training inclusief het officiële examen van DAU/Brightest nu geen EUR 1195,- maar slechts EUR 995,- betaalt (ex. BTW).
Deze actie gaat per direct in en is geldig tot en met vrijdag 25 november 2022 (23:59 CET).
Schrijf je nu in en vermeld in het commentaarveld “Black Friday” om aanspraak te maken op deze korting.
Je kunt elke test-Euro maar één keer uitgeven, dus je wilt testen en toetsen gericht inzetten. Een Product Risico Analyse (PRA) kan je daarin ondersteunen. Wat is een PRA? In een notendop: je vraagt aan de stakeholders welke risico’s worden ervaren. Zo ontstaat een gedragen beeld van de risico’s die worden gelopen – en kun je gericht maatregelen definiëren, waaronder testen en toetsen.
Als we onbeperkte resources (tijd, geld en personeel) zouden hebben, dan zouden we “alles” kunnen testen. Helaas is de werkelijkheid anders en moeten we keuzes maken. Een PRA-sessie helpt bij het maken van keuzes op gebied van testen en toetsen – en andere mitigerende maatregelen.
In een PRA-sessie geven de stakeholders aan welke risico’s zij ervaren: wat gebeurt er als iets het niet -of niet goed- doet? Risico’s worden gescoord op Kans en Impact (kosten, schade). Op basis daarvan bepalen we welke onderdelen we “zwaarder”, “normaal” en “lichter” willen testen. Op die manier besteed je je testbudget heel gericht aan de grootste risico’s. En pak je de ernstigste risico’s als eerste aan.
De testmanager of -coördinator helpt bij het kiezen van de testontwerptechnieken die het beste toe te passen zijn, gegeven een bepaalde zwaarte.
Werkvorm PRA varieert De werkvorm van een PRA kan variëren: veelgebruikte methodes zijn “stickeren” (meer stickers = meer risico/belang) of het toekennen van punten per Functie. Elk van de elementen landt dan in een kwadrant van de onderstaande risicomatrix.
Ook de indeling/verdeling van de kleuren over het vlak kan afwijken.
Afbeelding: Risicomatrix
Wat betekenen de kleuren? Landt een onderwerp (functie, systeemdeel, proces) in de rode zone, dan willen we daar méér zekerheid over hebben en dan zullen we éérder en intensiever testen. Landt een onderwerp daarentegen in de groene zone, dan volstaat minder diepgaand (en later) testen.
Van PRA naar Teststrategie Op basis van het aantal elementen in een specifieke zone, het beschikbare budget, de beschikbare tijd én de aanwezige skills van de testers, kan een testconsultant een voorstel doen voor een teststrategie. In deze strategie staat wie, wat, wanneer, hoe en waarmee zal testen en over welke andere mitigerende maatregelen (anders dan “testen”) we eventueel beschikken.
Deelnemers aan de PRA
Aan een PRA-sessie kunnen al diegenen deelnemen die een uitspraak kunnen doen over de kans en de impact van fouten in het op te leveren product (het systeem, de output van het systeem). Dat wil zeggen: product owners, systeemeigenaren, eindgebruikers, beheerders, lead engineers en testers maar óók privacy- en security-experts van de organisatie.
De laatstgenoemden vertellen ons iets over kaders waarbinnen we ons moeten bewegen (zoals: privacy- en securityrichtlijnen, architectuur). Dit kan invloed hebben op de gevraagde samenstelling van het bouw- en testteam (skills, ervaring).
Deze groep kan bij uitstek bepalen wie er last van gaan hebben als het systeem niet goed werkt en wat de schade zal zijn: Hoeveel omzet missen we? Krijgen we boetes? Loopt ons imago een deuk op? Kunnen collega’s hun werk niet meer doen – of alleen nog door omwegen te bewandelen? Wat kan een uur, dag of week wachten en wat móet juist 24*7 doorgaan? Voor wie is het product? Voor een “doorsnee” collega of voor “De Toezichthouder”? Wordt het product dagelijks gebruikt of “maar één keer per jaar” (en wat als dat dan net de Miljoennenota is?) Wat kost een hersteloperatie als het mis is gegaan?
Bijkomend voordeel van gezamenlijke deelname aan de PRA: je ziet vaak dat de Business (afnemer) en de IT-leverancier elkaar veel beter begrijpen na zo’n sessie.
Een sessie waarin functies worden gerangschikt: “lage, gemiddelde en bovengemiddelde testinspanning gevraagd”.
Wat is dan “Lichter en Zwaarder Testen”?
Testers zijn in staat om testontwerptechnieken in te zetten die méér of juist minder testgevallen opleveren. Dit heeft gevolgen voor de zgn. testdekking: met méér testgevallen heb je een betere dekking, maar soms is méér niet noodzakelijk beter (bv. in de “groene zone”).
Bij het vaststellen van een teststrategie bepaal je dus wélke testontwerptechnieken je inzet op welk deel van de PRA Matrix.
Een ruw voorbeeld: je zou ervoor kunnen kiezen om alle functies die in de “groene zone” staan, te testen middels een checklist, door de eindgebruiker. Alle elementen in de “oranje zone” betreffen in deze casus condities (beslissingen) en invoer/uitvoer en verlangen daarom testen op basis van equivalentieklassen (EP), grenswaardenanalyse (BVA) en een beslissingstabel (Decision Table). De condities in de “rode zone” testen we op basis van Modified Condition Decision Coverage (MCDC).
NB: De teststrategie wordt ook gevormd op basis van de projectdoelstellingen, de aard van het product, het budget en van de eventuele aanwezigheid (of afwezigheid) van testvaardigheden in het team. Als een team een bepaalde testontwerptechniek niet beheerst, zal voor een “next best” optie gekozen moeten worden.
De Rol van Testautomatisering
Niet alleen wát je wilt testen, maar ook hoe váák je het wilt testen speelt een rol bij het uitstippelen van de teststrategie. Wil je iets vaker testen? Dan zul je snel denken aan testautomatisering.
Neem je alle gerealiseerde testgevallen op in een geautomatiseerde (regressie) testset? Of voer je ze éénmalig uit? Dit heeft direct invloed op de testkosten – op de langere termijn. En maakt het inzetten van “veel testgevallen” wellicht toch eerder nuttig en betaalbaar. Tegelijk moet je goed nadenken over de onderhoudskosten van zo’n (geautomatiseerde) testset.
Andere Mitigerende Maatregelen
Testen en toetsen zijn bekende maatregelen die ingezet kunnen worden voor het mitigeren van de onderkende risico’s. Daarnaast zijn nog talloze andere maatregelen denkbaar: bv. méér ervaren ontwikkelaars verwerven (verlaagt de kans op fouten) of méér beheerders aantrekken (verlaagt de impact van fouten).
Heb je je voorgenomen om de training “Certified Data & Analytics Tester” te volgen en heb je nog een klein zetje nodig om er nu écht mee te beginnen? Dan kan Verified je daarbij helpen: als je je vóór 1 juli 2022 aanmeldt voor een training, krijg je van ons het examenvoucher ter waarde van EUR 190,- (ex. BTW) kado! Te Laat
Hoe werkt het? Je meldt je aan voor één van de trainingen in de evenementenkalender (deze hoeft dus niet voor 1 juli plaats te vinden) en zet in het opmerkingenveld “Zomerdeal”. Je betaalt dan voor de training EUR 1005,- in plaats van EUR 1195,- (ex. BTW).
Kleine Lettertjes:
Deze actie start op 28 mei 2022 en geldt alléén voor nieuwe aanmeldingen, die via de website van Verified zijn aangemeld. De actieprijs van de cursus is EUR 1005,- in plaats van 1195,- (ex btw) incl. één examenvoucher. Je ontvangt de voucher na betaling van de cursus. Mocht je de training annuleren dan vervalt de aanbieding voor het gratis examen: je kunt de voucher dus niet “meenemen” naar een andere training.
Samen studeren is toch véél leuker dan in je eentje? En nu levert het je ook nog eens een mooie korting op!
Samen studeren voor Certified Data & Analytics Tester (CDAT)
Hoe werkt het?
Als je je vanaf nu samen met een vriend/collega/kennis registreert voor de training “Certified Data & Analytics Tester” via het formulier onderaan deze pagina, dan krijgen jullie allebei 10% korting op de reguliere cursusprijs (ex. examen). Dat wil zeggen: je betaalt per persoon geen EUR 995,- maar EUR 895,50 voor deze training.
Let erop dat je in het opmerkingenveld aangeeft met wie je samen de training aanvraagt (naam en achternaam).
Deze actie is geldig tot 7 februari 2022.
Details
De korting wordt verstrekt op de factuur van de training zodra beide deelnemers zich daadwerkelijk via het deelnameformulier voor de training hebben ingeschreven.
De actie is geldig voor nieuwe deelnemers die zich na 10 januari 2022 aanmelden tot 7 februari 2022.
Om het examen van Data & Analytics United (DAU) af te leggen, heb je een voucher nodig van Brightest. Deze kun je ook aanschaffen via Verified maar op de vouchers kunnen we geen korting verstrekken. Als je in het aanmeldingsformulier aangeeft dat je de voucher graag ontvangt, zullen we deze ook meenemen bij de factuur. Je kunt de voucher ook tijdens of na de training aanvragen.
Op 26 september heeft Armando Dörsek namens Verified het “Superlot” van de Grote Clubactie van zijn buurmeisje Luna in ontvangst mogen nemen.
De opbrengst van het Superlot gaat naar spelmaterialen voor de jeugd van de Apeldoornse Mixed Hockey Club (AMHC), waar Luna speelt in de jeugd. We hopen dat er nog veel bedrijven hetzelfde doen en daarmee de club van Luna steunen!
In juni 2021 heeft Armando Dörsek, onze consultant op gebied van testen, kwaliteit en compliance, een presentatie voor het KNVI verzorgd. Deze heeft als titel: “10 Beginnersfouten in het Datalandschap (waar Testen het verschil kan maken)”. De deelnemers konden door middel van stemming besluiten welke vijf (van tien) onderwerpen die avond toegelicht zouden worden.
Onderwerpen
De deelnemers konden kiezen uit de volgende onderwerpen:
Meer is niet altijd beter…
(over gebruik van productiedata)
Doet u mij maar een testertje!
(over specifieke vaardigheden en eigenschappen)
Onderschatting van kaders…
(over security en privacy)
Datakwaliteit, dat kunnen we niet echt meten?
(over data-kwaliteitsattributen)
Datakwaliteit? Garbage In = Garbage Out, toch?
(over eigenaarschap van data, datakwaliteit en effecten op data-projecten)
We herstellen die data hier – omdat het kan.
(ten koste waarvan corrigeer je data in een datawarehouse)
Onze Helden: de Bugfixers
(over de delicate balans tussen snel en goed)
Slepen met Data
(over het effect van “meerdere waarheden” – naast het risico op datalekken)
Wil de Echte Klant opstaan?
(over acceptatietesten in een dataproject)
Risico’s? Eh…
(over het nut van risicogebaseerd testen in een dataproject).
Opname
De presentatie (opname) is beschikbaar op de site van de KNVI.
Blogreeks
Op basis van de onderwerpen zal Armando Dörsek een blogreeks schrijven, te starten met de onderwerpen die bij KNVI gepresenteerd zijn.
Houd de site in de gaten!
Trainings for the second half of 2021 are currently being planned. Verified will be organizing trainings in Berlin, Copenhagen, Utrecht and Schiphol Amsterdam. If you’re participating in one of these trainings, you’ll get a free (*) exam voucher, worth EUR 190,-.
This way, planning ahead is really beneficial!
*) Rules apply
Valid for all CDAT trainings from July through December 2021, organized by Verified and enrolled before 1 July 2021 through the Verified-website. The free voucher is part of a (paid) training and will be sent to the attendee immediately after full payment and upon completing the training.
Daarnaast blijft het mogelijk om in company trainingen en trainingen op maat aan te vragen. Vragen? Neem vooral contact met Verified op, we staan je graag te woord.
In samenwerking met Ammerlaan IT Advies & Opleidingen verzorgt Verified in oktober 2020 de training “DaU Certified Data & Analytics Testing” in een Engelstalige online variant.
De cursus behandelt essentiële kennis en vaardigheden voor het testen en toetsen van datawarehouse-, business intelligence (rapportages, dashboards) en analytics oplossingen. De doelgroep omvat niet alleen testers maar ook ontwikkelaars, analisten en data scientists.
De deelnemers ontvangen op 4 woensdagmiddagen alle stof die nodig is voor het behalen van het examen voor CDAT. Door te kiezen voor deze vorm bedienen we niet alleen de Engelstalige medewerkers in Nederland maar ook geïnteresseerden in het buitenland (bv. Europa, India en het oosten van Noord- en Zuid Amerika).
Naast deze online training blijven natuurlijk ook de klassikale open inschrijvingen én de in-company training op de kalender staan. Bekijk alle trainingsdata hier.
Photo by J. Kelly Brito on Unsplash
Testen & Toetsen in de wereld van BI, Datawarehousing en Analytics
We gebruiken cookies om ervoor te zorgen dat onze site zo soepel mogelijk draait. Als je doorgaat met het gebruiken van deze site, gaan we er vanuit dat je ermee instemt.OKPrivacybeleid
