Workshop Procesverbetering in Agile BI/DWH omgevingen.

1. Februari 2014
Workshop Procesverbetering
Testen BI/ DWH
AGENDA
Persoonlijke introductie & verwachtingen 15m
Niels Bor en Marcus Drost (workshopleiders)
Deelnemers workshop
Inhoud
Deel 1 Korte presentatie: Waterval versus Agile/ Scrum (Marcus Drost) 15m
Deel 2 Probleem-awareness-spel (inzicht) test problemen BI/ DWH systeem (Niels Bor) 20m
Deel 3 Korte presentatie: Meer over testen (Marcus Drost) 15m (dan pauze 10m)
Deel 4 Praktijkvoorbeeld Agile regressietesttool DREAM (Marcus Drost) 30m
Deel 5 Probleem-awareness-spel (van oorzaken naar actie) (Niels Bor) 20m
Afsluiting 10m
Samenvatting workshop (Niels Bor en Marcus Drost) en feedback deelnemers (15m uitloop)
V2.3

2. Doel van de workshop
“Het verkrijgen van inzicht in de problemen van
waterval en agile testprocessen en het zoeken
naar mogelijke oplossingen. Specifiek voor dataintensieve omgevingen waar het gaat om
Business Intelligence, Data Warehousing en
Database Applicaties.”

4. Hoewel de praktijken die onder de noemer agile vallen al
gangbaar zijn sinds software ontwikkeld wordt, valt de
geboorte van agile als term en concept terug te brengen
tot het Agile Manifesto, in februari 2001, tijdens een
informele samenkomst van ontwikkelaars. Het handvest
stelt dat goede software wordt gemaakt door:
1.Personen en interacties boven processen en tools.
2.Software die werkt boven lijvige documentatie.
3.Samenwerking met de klant boven onderhandeling over het contract.
4.Omgaan met verandering boven het volgen van een plan.
Bron: Wikipedia

5. Uit het handvest volgen twaalf principes:
1.Klanttevredenheid, door snelle, continue levering van bruikbare software.
2.Zelfs late veranderingen in de requirements zijn welkom.
3.Werkende software wordt regelmatig geleverd (weken eerder dan maanden).
4.De ontwikkelaars werken nauw en dagelijks samen met de mensen die de business
kennen.
5.Projecten steunen op gemotiveerde en betrouwbare personen.
6.Een gesprek in levende lijve is de beste manier van communicatie, wat betekent dat men
zich best op dezelfde plek bevindt.
7.Werkende software is de eerste maatstaf van vooruitgang.
8.De ontwikkeling kan te allen tijde worden voortgezet.
9.Er is voortdurende aandacht voor technische uitmuntendheid en goed ontwerp.
10.Eenvoud is belangrijk: hoe meer er niet gedaan wordt, hoe beter.
11.De teams organiseren zichzelf.
12.Men past zich aan de omstandigheden aan.
Bron: Wikipedia

6. Iterative vs. Agile
First of all, Agile is iterative already but it is way more than just iterative. Here are a number of
differences between Agile and “just” Iterative development:
Mini-waterfall is still waterfall
Iterative is still waterfall, just on a smaller scale. A series of mini-waterfalls is certainly better
and less risky than one big waterfall but mini-waterfall still is fundamentally waterfall and
comes with all its known problems such as difficulty to adapt to change (“Nice idea but sorry,
the requirements have been signed off months ago”), cascading delays (“Oops, we need to
shorten the testing phase”) and low quality (“We don’t have time to fix those bugs. We’ll fix
them in a later phase/iteration”).
Bron: Sandy Mamoli

7. Comparing Agile and Traditional Approaches
Bron: Scott Ambler

8. A look back at waterfall

9. Currently in AGILE/ SCRUM

10. Change frequency
LOW
HIGH

11. Regression test frequency
LOW
HIGH

12. Regression in AGILE/ SCRUME/
SCRUM

13. AGILE/ SCRUM test bottleneck

14. Frequent application changing

16. Probleem-awareness-spel (inzicht)
De deelnemers van de workshop gaan onderling in gesprek over de gerelateerde problemen
die zij in de praktijk bij het testen van data intensieve systemen ondervinden. Zij identificeren
de test gerelateerde problemen door deze met gele briefjes op de desbetreffende onderdelen
van de datawarehouse te plakken: Source system, data storage & aggregation en
presentation.
Beschrijf het probleem zodanig dat de oorzaak kan worden achterhaald en eraan een actie
kan worden gekoppeld.

18. Typische problemen
1. Brondata uit productie en test is functioneel niet stabiel.
2. Testdata zowel handmatig als automatisch niet op tijd beschikbaar.
3. Voorbereiden test en inrichting testomgeving zoals klaarzetten ETL en loadfiles
kost veel tijd.
4. Doorlooptijden van testruns duurt erg lang; performance problemen
5. Testcases niet duidelijk en geen koppeling aan fysieke testgevallen. M.a.w.
testgevallen worden ter plekke gezocht en zijn dan toevallig wel dan niet voor de
test beschikbaar. Daardoor is testdekking min of meer toevallig.
6. Geen beschrijving van verwachte output van testcases en daardoor tijdens de
controle veel zoekwerk.
7. Dubbel werk door overlap tussen UT, FAT en GAT.
8. Herbruikbaarheid van testcases wordt niet gemanaged; er is geen koppeling
tussen functionaliteit en testcases/ testgevallen.
9. Voor het uitbreiden/ aanpassen van testsets met testgevallen is geen standaard
proces aanwezig, dus min of meer ad hoc.
10. Tester ervaart punctueel heel veel druk.

20. Testsoorten Tmap (ter info)
Het testen is georganiseerd in een aantal testsoorten, TMap kent de volgende
testsoorten:
Unittest (UT): door de ontwikkelaar uitgevoerd. Toont aan dat een unit aan de in de
technische specificaties gestelde eisen voldoet.
Unitintegratietest (UIT): door de ontwikkelaar uitgevoerd. Toont aan dat een logische
groep units aan de in de technische specificaties gestelde eisen voldoet.
Systeemtest (ST): door de leverancier uitgevoerd. toont aan het ontwikkelde systeem of
dele daarvan aan de functionele- en niet-functionele specificaties en het technisch
ontwerp voldoen.
Systeemintegratietest (SIT): door de toekomstige gebruiker(s) uitgevoerd. Toont aan dat
(sub)systeeminterface afspraken zijn nagekomen, correct zijn geïnterpreteerd en correct
zijn geïmplementeerd.
Functionele acceptatietest (FAT): door de toekomstige gebruiker(s) uitgevoerd. Toont
aan dat het ontwikkelde systeem aan de functionele eisen voldoet.
Gebruikersacceptatietest (GAT): door de toekomstige gebruiker(s) uitgevoerd. Toont
aan dat het ontwikkelde systeem aan de wensen/eisen van de gebruiker voldoet.
Productieacceptatietest (PAT): door de toekomstige beheerder(s) uitgevoerd. Toont aan
dat het ontwikkelde systeem aan de van uit beheer gesteld eisen voldoet.

21. Methoden om de regressie te testen
1.[Steekproef] Controleren van enkele waarden en op basis van de resultaten
generaliseren
Voordeel: snel en zonder veel automatisering
Nadeel: onnauwkeurig, onvolledig
2.[Controlegetal] Door het maken van sommen wordt op basis van enkele
uitkomsten een uitspraak over de correctheid van het totaal gedaan.
Voordeel: snel te automatiseren
Nadeel: onvolledig; bij afwijkingen is de onderliggende oorzaak lastig te vinden;
afhankelijk van de applicatielogica
3.[Datamodel] Door het definiëren van het datamodel wordt een complete database
automatisch gecontroleerd op afwijkingen.
Voordeel: volledige dekking:100%, onafhankelijk van de applicatielogica;
onderliggende oorzaak is snel te vinden
Nadeel: aanschaf of huur van een tool

22. Over regressie gesproken…

23. Maar ook dichtbij…

24. Agile Development Team Testing Strategies
Agile development teams generally follow a whole team strategy where people with testing
skills are effectively embedded into the development team and the team is responsible for the
majority of the testing.
This strategy works well for the majority of situations but when your environment is more
complex you'll find that you also need an independent test team working in parallel to the
development and potentially performing end-of-lifecycle testing as well.
Regardless of the situation, agile development teams will adopt practices such as continuous
integration (CI) which enables them to do continuous regression testing, either with a testdriven development (TDD) or test-immediately after approach.
Bron: Scott Ambler

25. TOP 5 speerpunten automatisering 'Example DWH'
●
●
●
●
●
[Automatische regressietest] Door de hoeveelheid van data is een
automatische regressietest wenselijk met het oog op kwaliteit en tijd.
[Virtualisatie bronsystemen] Want bronnen leveren zelden op tijd en de
dekking van de testdata is vaak niet voldoende; door de automatische generatie
van testdata kan het team onafhankelijk worden van de bronnen.
[Automatische output controle] Door de automatische output controle kan
meteen na de testrun (snelheid) worden vastgesteld of het resultaat correct is.
Hierdoor wordt de testcyclus extreem verkort.
[Procesautomatisering] Uit de praktijk blijkt, dat daar waar automatisering
plaatsvindt, zelf veel processen nog handwerk zijn. Middels scheduling en
scripting kan de graad van automatisering worden opgevoerd en kunnen
verwerkingen naar de nacht worden verplaatst.
[Deployment] Deployment en invoeringsprocessen naar productie en
testomgevingen nemen veel tijd in beslag. Als de frequentie van wijzigingen wordt
opgevoerd, dan ontstaat hier gauw een bottleneck. Hier valt veel tijd te winnen.

29. DEMO DREAM (www.drost.name)
World’s first tool for continuous database and data warehouse regression testing.
Shouldn’t we be doing better? (Scott W. Ambler)Mission-critical business functionality is
implemented in RDBMSs. In the survey, 63.7% of respondents indicated that their
organizations did this, but of those only 46% had regression tests in place to validate the
logic. Shouldn’t we be doing better? Author: Scott W.Ambler

33. Probleem-awareness-spel (van oorzaak naar actie)
De deelnemers van de workshop gaan onderling in gesprek over de gevonden problemen en
proberen de oorzaken van de problemen te achterhalen (root cause analysis). Ga hiervoor
eerst de problemen groeperen. Bedenk dan acties cq. oplossingen voor de gevonden
problemen.

35. Mogelijke oplossingen
1.Regressie door de hele keten; zowel in ontwikkel en testomgeving
2.Simuleren van testdata; virtualisatie van bronsystemen; synthetische testdata
genereren
3.Het automatiseren van deploymentprocessen
4.Verbeteren performance door snellere machine of in de cloud
5.Testcases meteen vastleggen bij user stories en functionele specificaties.
6.Verwachte output van te voren voorspellen (een mal maken); voor automatische
output controle van te voren elektronisch vastleggen.
7.Afspraken waar wat en door wie wordt getest; zo veel mogelijk 'links' in het
ontwikkelproces testen.
8.Inrichten testdata management op het niveau van functionaliteiten zoals user
stories.
9.Zorgen dat data testdata management flexibel en continu is.
10. Automatische regressietest en automatische output controle waarmee
handmatig werk wordt voorkomen.

36. Samenvatting workshop
Feedback deelnemers