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))

Contact

Armando Dörsek                 armando.dorsek@verified.nl                     +31(0)6 23054054

€ 1.195,- ex. VAT (including materials and one exam (€ 200,- ex. VAT))

See Course Dates and Enroll

Verified biedt trainingen op het gebied van Data en Testen, zie de evenementenkalender.

Als je je wilt aanmelden voor een training, vul dan het onderstaande formulier in en we nemen snel contact met je op.

PRA – de Broodnodige Start van elk Testtraject

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.

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.

---

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).

---

Bij elke migratie heb je te maken met verschillende clusters van data, programma’s of andersoortige objecten. Als projectteam wil je graag een beeld vormen van het werk dat op je af komt.

Bij migraties wil je vooral dat éérst geschoond wordt. Dat wat daadwerkelijk over gaat naar het nieuwe platform, daar kunnen we wat tellingen op los laten.

Is het vooral veel werk? Dan is het de moeite waard om  de migratie voor een deel te automatiseren.  Bijvoorbeeld door omgevingsspecifieke verwijzingen en functies te uit te lichten. Of misschien zelfs geautomatiseerd te vervangen.

Is het vooral complexe materie, dan wil je op tijd kunnen starten met het nadenken over alternatieven. En wat ervoor nodig is om die op tijd te implementeren.

In beide gevallen geldt: aanpassingen dienen goed getest te worden, zo mogelijk al in de huidige omgeving zodat je zeker of bugs zijn ontstaan in de nieuwe omgeving (of deze al waren geïntroduceerd op de oude).

Je kunt iedere klantgroep in een matrix plaatsen: op de x-as vind je de mate van complexiteit (na een kwalitatieve analyse) en op de y-as de hoeveelheid werk in aantallen.  De omvang van een bubble geeft aan hoeveel gebruikers worden geraakt.

Ter afsluiting: houd voor ogen dat vooral de verhoudingen duidelijk moeten worden en vermijd discussies, of de “aantallen” wel juist gewogen zijn en wie objectief mag beoordelen wat complex is en wat niet.  Zodat je met elkaar kan sparren over de oplossingen.