your reference in testing services Test Coördinatie Introductie 1 Gent, 4 april 2011
Wat verstaan jullie onder testen? En testcoördinatie? 2 Hoe zien jullie het?
Testen bestaat uit activiteiten die uitgevoerd worden om één of meerdere kenmerken van een product, proces of dienst vast te stellen volgens een gespecifieerde methode Testen is een proces dat inzicht geeft in- en adviseert over de kwaliteit en de daaraan gerelateerde risico s 3 Definities volgens TMAP Next
Een test level is een groep van testactiviteiten die gezamenlijk worden uitgevoerd en aangestuurd 4 Definities volgens TMAP Next
Johan Symons, Introductie tot de psychomotoriek - coördinatie = het harmonisch en economisch samenwerken van spieren, zenuwen en zintuigen om doelgerichte, stabiele bewegingsakties en snelle situatie - aangepaste reacties (reflex) tot stand te brengen. Voor een optimale samenwerking dienen volgende aspecten in acht te worden genomen : een juiste krachtmaat (bewegingsomvang en snelheid) een juiste spierkeuze (bewegingsuitvoering en richting) een vlot wisselspel tussen spierspanning en ontspanning voor een goede motorische aanpassing 5 Wat is coördinatie - in het menselijk lichaam?
Coördinatie van de testen voor een specifiek project van één of meerdere test levels Coördinatie van alle activiteiten en processen die daaraan gelinkt zijn voor een specifiek project van één of meerdere test levels Coördinatie van mensen die bezig zijn met de activiteiten die gelinkt zijn aan testen voor een specifiek project van één of meerdere test levels 6 Wat is coördinatie binnen testen?
Testen is toch enkel het uitvoeren van testen...... of hebben we toch nood aan een meer gestructureerde aanpak? 7 Gestructureerd testen
Nadelen van ongestructureerd testen - testinspanning kan niet voorspeld worden - resultaten kunnen niet gemeten worden - geen correcte selectie van test cases - komt meestal onder tijdsdruk omdat er geen plan bestaat - geen inzicht in de stand van zaken rond kwaliteit - inefficiënt en niet effectief 8 Gestructureerd testen
Voordelen van gestructureerd testen - het kan gebruikt worden in de meeste situaties - het geeft een correct inzicht in de risico s en de kwaliteit van het test object - defects worden in een vroeg stadium gevonden - defects worden voorkomen! - aangezien testen onderdeel is van het kritisch pad wordt het hele traject geoptimaliseerd - test producten zijn herbruikbaar - het test proces is beheersbaar 9 Gestructureerd testen
Kick Off 10
Formuleren van de testopdracht en testdoelstellingen 11 Waar gaat dit hoofdstuk over?
Inzicht krijgen in de doelstellingen van - het project - de projectorganisatie - de opzet van het systeemontwikkelproces - het te testen systeem - de eisen waaraan het systeem moet voldoen Al deze informatie is nodig om de verdere stappen in het testproces te zetten 12 Wat is het objectief hiervan?
Wat valt binnen en buiten de testopdracht? Om dit te weten moeten we de grenzen kennen/definiëren Grenzen van - testobject welke systemen of systeemonderdelen? interfaces - Tot? of Tot en met? - testactiviteiten welke testsoorten vallen in de scope? hoort unit testen hierbij? zijn er externe testactiviteiten? reviews van tussenproducten onderdeel van de scope? Een figuur zegt meer dan 1000 woorden!! 13 Hoe bepalen we de scope van de testopdracht?
Wat is een testdoelstelling? - een testdoelstelling is een in de taal van de opdrachtgever of belanghebbende gespecifieerd succescriterium van de testopdracht taal van de opdrachtgever niet in IT-Termen (tenzij de opdrachtgever zich in de IT bevindt) vertaling/mapping naar IT terminologie is nodig om naar testproject te rapporteren succescriterium van de testopdracht indien alles goed gaat - OK! indien afwijking - bijschaven op Resultaat, Tijd, Risico of Kosten 14 Wat is een testdoelstelling?
Testdoelstellingen 1 Toon aan dat de nieuwe functionaliteiten volgens verwachtingen werken 1 Nieuwe klanten moeten kunnen aangemaakt worden a 1 Marketingacties moeten gericht kunnen gevoerd worden b 1 Facturen moeten correct geprint worden c 2 Toon aan dat systeem X voldoet aan het veiligheidsbeleid a 2 Enkel de gebruikers met de correcte authorisaties mogen aanloggen op het systeem b 2 Aanloggen van buitenaf kan enkel via het afgesproken protocol 3 Lever inzicht in het gevoel dat de organisatie heeft t.o.v. de migratie van de huidige gegevens a 3 Huidige klanten en hun producten moeten gekoppeld blijven Een voorbeeld 15
16
Wat is een teststrategie? - een teststrategie is de verdeling van de testinspanning en dekkingsgraad over de te testen delen of aspecten van het testobject, met als oogmerk de belangrijkste fouten zo vroeg en goedkoop mogelijk te vinden. Deze verdeling is afhankelijk gemaakt van risico s op het gebied van business, systeemontwikkeling en testen 17 Definities volgens TMAP Next
Welke activiteiten voeren we uit bij het opstellen van de teststrategie? - opstellen risicomatrix - bepalen van testzwaarte 18 Onderdelen teststrategie
Geen onbeperkte tijd en budget Beperking voor het halen van het testresultaat dat vastgelegd is in de doelstellingen We moeten de tijd en het geld optimaal verdelen Risicomatrix helpt ons bij het maken van deze keuzes 19
Wat is een risicomatrix? - de risicomatrix is het resultaat van de analyse van het te testen product met als doel dat de test coördinator en de verschillende betrokken partijen tot een gezamenlijk beeld komen van wat de meer of minder risicovolle kenmerken en onderdelen zijn van het te testen product, zodat de grondigheid van de testen hieraan kan gerelateerd worden 20 Definities volgens TMAP Next
5 stappen voor het opstellen van de risicomatrix Stap 1 - Voorbereiden & bepalen relevante elementen Stap 2 - Bepalen van de schade Stap 3 - Bepalen van de faalkans Stap 4 - Bepalen van de risicoklasse Stap 5 - Volledigheidscontrole 5 stappen 21
Wat is het uiteindelijke resultaat? Volledig systeem X Deelsysteem 1 B Bij uitval van het volledige verkoopproces verlies van inkomsten maar de kans dat de deelsystemen uitvallen is uiterst klein A Als deze functionaliteit niet of niet juist werkt krijgt het bedrijf zware boetes en negatieve pers. Dit deelsysteem wordt dagelijks honderden keren opgestart en wordt gebouwd met een voor het bedrijf nieuwe technologie Deelsysteem 2 C Een onjuiste premie kan verlies van omzet betekenen maar is gebouwd in bekende en betrouwbare technologie Externe interface B Als niet wordt voldaan aan de beveiligingseisen kan vertrouwel klantinformatie openbaar worden en leidt het bedrijf zware imagoschade. De externe interface wordt gerealiseerd met een binnen het bedrijf al lang bekende en beproefde technologie zodat de faalkans als laag wordt ingeschat 22 Het uiteindelijke resultaat
Risicomatrix is een momentopname Matrix moet regelmatig doorlopen worden - inventariseer de (nieuwe) beschikbare informatie - beoordeel de actuele situatie pas indien nodig de matrix aan - volg de uitvoering van de maatregelen - neem indien nodig aanvullende maatregelen Niet afschrikken om de strategie aan te passen! 23 Onderhoud risicomatrix
Als we alle gekende risico s in kaart hebben gebracht, moeten we bepalen hoe zwaar we deze gaan testen Hiermee moeten we wel nog andere aspecten mee in kaart brengen: - tijd einddatum van het project blijft er staan - kosten we hebben slechts een beperkt budget (in de meeste gevallen) Daarom gaan we de test levels bepalen 24 Moet het altijd zo uitgebreid?
Wat is een test level? Een test level is een groep testactiviteiten die gezamenlijk wordt uitgevoerd en aangestuurd 25 Definities volgens TMAP Next
Algemeen principe - zo vroeg mogelijk testen goedkoper de hersteller moet zo snel mogelijk leren van de gemaakte fouten 26 Welke test levels?
Welke test levels zijn er standaard voorzien? - Reviews van tussenproducten - Unit Testen - Unitintegratie Testen - Systeem Testen - Systeemintegratie Testen - Acceptatie Testen 27 Welke test levels?
Niet beperken tot deze test levels! Welke testsoorten te kiezen is afhankelijk van drie aspecten - tijd - risico - kosten 28 Welke test levels?
Wat is de volgende stap? Combinatie van keuze van test levels en de risicomatrix die we eerder opgesteld hebben 29 Hoeveel effort per test level?
Link met de risicomatrix Volledig systeem X B x x xx xxx Deelsysteem 1 A x xx xxx xx Deelsysteem 2 C x x Externe interface B x xx x Aantal x-en bepalen hoe zwaar iets getest moet worden 30 Hoeveel effort per test level?
31
Na het opstellen van de teststrategie brengen we alles een niveau van detail lager - Testontwerptechnieken - Concrete criteria per test level opzetten 32 Wat houdt dit hoofdstuk in?
Test technieken zijn moeilijk en tijdrovend! Is de enige manier om de strategie aantoonbaar te maken!! Zonder testtechnieken kan men niet de juiste zwaarte geven aan de testen die uitgevoerd worden als gevolg van de strategie Vormt de link tussen testdoelen en testgevallen 33 Waarom testtechnieken?
We mogen de doelstelling van testtechnieken niet vergeten - met zo weinig mogelijk testgevallen een zo hoog mogelijke foutvindkans creëren - alleen in geval van zeer hoog risico testen we alle gevallen - het komt erop aan van de juiste techniek te kiezen in het kader van de te testen objecten 34 Doelstelling testtechnieken?
Welke testtechniek is de juiste voor ons? Veel variabelen om rekening mee te houden - kenmerk - testzwaarte - testbasis - kennis en kunde van de testers (zeker rekening mee houden in de acceptatietesten) - arbeidsintensiviteit van de techniek 35 Welke gebruiken we?
Hoe doen we dit concreet? X Volledig systeem B xx functionele test Proces cyclus test Deelsysteem 1 A xxx functionele test Beslissingstabel Deelsysteem 2 C Externe interface B xx security test Data cycle test Risicoanalyse Dit doen we per test level 36 Welke gebruiken we?
Wanneer kunnen we beginnen met een bepaald test level en wanneer zijn we ermee klaar? Kan tijdsgebonden zijn Bij voorkeur wordt dit afhankelijk gemaakt van criteria die op voorhand bepaald worden 37 Wanneer starten/stoppen?
Wat zijn Entry & Exit criteria? - Entry criteria geven aan wanneer er kan begonnen worden met een bepaald test level Voorbeelden de test cases voor dit test level zijn voor minstens 50% afgerond bij de niet-afgeronde test cases zijn er geen componenten met risicoklasse A - Exit criteria geven aan wanneer er kan gestopt worden met een bepaald test level Voorbeelden minstens 85% van de testen zijn succesvol afgerond bij de niet-succesvol afgeronde testen is er geen priorititeit 1 38 Criteria per test level
Waarom stellen we deze op? De start en het einde van een test level mogen niet enkel afhankelijk zijn van de tijd Indien dit toch gebeurt door bijvoorbeeld een verkorting van de voorziene tijd kunnen we aan de hand van deze criteria de risico s beter inschatten naar de volgende test levels toe Om de planning onder controle te houden 39 Criteria per test level
40
Bepalen van de benodigde infrastructuur Opzetten van overlegstructuur 41 Wat houdt dit hoofdstuk in?
Wat verstaan we onder infrastructuur? - testomgeving(en) - test tools - setup van testruimte Infrastructuur moet ook ingepland en gebudgetteerd worden!! Infrastructuur 42
Testomgevingen - Algemeen principe - OTAP - Ontwikkeling - Test - Acceptatie Kunnen eventueel samen gebruikt worden - Productie Testomgevingen 43
Testomgevingen - Specifiek - afhankelijk van de gekozen test levels - dus ook afhankelijk van de gekozen testdoelen - voorbeelden zijn performantie testomgeving migratie testomgeving demo omgeving preproductie omgeving Testomgevingen 44
Welke soorten testomgevingen kennen we? - fysieke testomgevingen eigen hardware en software onafhankelijk van anderen duur - virtuele testomgevingen 1 server met meerdere omgevingen afhankelijkheid met meerdere omgevingen van de operaties op deze eneorgan server goedkoper Testomgevingen 45
Belangrijk bij het bepalen en vastleggen van testomgevingen - wees realistisch - een tester heeft altijd meerdere omgevingen nodig - zorg dat er resources zijn voor de opzet en he tonderhoud van deze omgeving(en) - overweeg eventueel virtuele omgevingen Infrastructuur - Testomgevingen 46
Welke vragen moeten we ons stellen rond test tools? - hebben we test tools nodig? test management tools defect Management tools functionele test tools - dienen we deze aan te kopen? - dienen deze nog opgezet te worden? - moeten we specifieke tools zelf bouwen? Test Tools 47
Als gevolg van de antwoorden op de vorige vragen, moeten we - budgetteren - plannen - manieren van werken afspreken met alle betrokken partijen Test Tools 48
Wanneer is een testruimte nodig? - vooral bij acceptatietesten door eindgebruikers - om systeem- en acceptatietesters samen te brengen - om eventuele opleidingen te geven aan testers alvorens zij hun testopdracht starten Is niet altijd mogelijk Indien wel mogelijk moet ook deze ingepland worden! Setup testruimte 49
Waaraan voldoet een goede testruimte? - alle benodigde hard- en software is aanwezig - afgesloten van de normale werkomgeving - testcoördinator is eigenaar van deze ruimte - mogelijkheid aparte meeting room Setup testruimte 50
Wat en waarom? - de overlegstructuur geeft de communicatielijnen aan tussen de verschillende betrokken partijen - bij deze communicatielijnen staat er ook hoe vaak en op welke manier er gecommuniceerd wordt - in grote lijnen - op die manier weet iedereen wanneer en hoe ze over de testen gebriefd worden - op voorhand vastleggen om miscommunicatie te voorkomen 51 Opzet overlegstructuur
Waar op letten bij het vastleggen van de overlegstructuur? - werk met SPOCs per partij - niet te zwaar maken, haalt de aandacht weg van de essentie - testen - haalbare meetings plannen qua tijd aanwezigen - schematisch en duidelijk weergeven 52 Opzet overlegstructuur
53 Wat houdt dit hoofdstuk in?
Opvolgen van de voortgang Behandelen van afwijkingen 54 Wat houdt dit hoofdstuk in?
Wat doen we in deze fase? - we geven inzicht in en hebben controle over: de voortgang van het test proces de kwaliteit en de risico s van het test object de kwaliteit van het test proces Het is de rol van de test coördinator om het totale test proces te controleren in een optimale manier en hierover te rapporteren 55 Onderdelen van controleren
Is een van de moeilijkste taken voor de test coördinator, aangezien er verschillende factoren in meespelen: - medewerkers - betrokken partijen - verwachtingsmanagement Vereist de nodige communicatie en sociale vaardigheden die vanuit de test coördinator moet komen Monitoring 56
Waar halen we de informatie vandaan? - intern beheerde data over het gehele proces - data die voorzien wordt vanuit de verschillende test levels - informatie van buiten het test proces meeting minutes gesprekken project meetings stand-up meetings... Monitoring 57
Wat doen we met deze informatie? - we analyseren mogelijke trends gaan we de goede richting uit of niet? - gevaren kunnen op tijd gedetecteerd worden - opportuniteiten kunnen ook op tijd gedetecteerd worden!!! Monitoring 58
Wat doen we als we een gevaar of een opportuniteit zien? - stap 1 analyse van de gebeurtenis inschatten van de risico s maatregelen voorstellen - stap 2 coördineren met de opdrachtgever en eventueel andere betrokken partijen indien nodig Monitoring 59
60
Het belang van rapportage Opstellen van tussentijdse rapportage Opstellen van een eindrapport 61 Waar gaat dit hoofdstuk over?
Als we niets rapporteren, hebben we niets getest! Rapporten geven inzicht in de kwaliteit van het testobject en van het testproces Informatie mag niet enkel bij de test coördinator blijven De klant/opdrachtgever op hun gemak stellen Beslissingen triggeren om het proces bij te sturen 62 Waarom rapporteren?
We kunnen een oneindig aantal tussentijdse rapporten genereren, maar dit mag uiteraard niet in de weg staan van de essentiële testopdracht Rapportage dient afgestemd te worden met de belanghebbenden Zoveel mogelijk de eisen samenbrengen rond 1 of enkele rapporten 63 Welke zijn mogelijk?
Het is de taak van de test coördinator om aan te tonen dat - het verwachte resultaat bereikt wordt - de risico s van het systeem in productie te nemen zo klein mogelijk zijn, gegeven alle voorwaarden - dit alles plaats heeft gevonden binnen het afgesproken budget en tijdsframe 64 Waarom een eindrapport?
Structuur - gelijkaardig met het test level rapport - entry & exit criteria worden nu acceptatiecriteria - er zijn geen over te dragen defects meer - wel nog openstaande defects Bevat ook het advies over het al dan niet in productie brengen van de test coördinator 65 Wat vermelden we hierin?
66
Voordelen van tools als ondersteuning Soorten tools 67 Waar gaat dit hoofdstuk over?
Welke zijn de belangrijkste voordelen van het inschakelen van tools? - hogere productiviteit - hogere kwaliteit testen - hogere arbeidsvreugde (minder manuele regressietesten bijvoorbeeld) - uitbreiding testmogelijkheden - rapportagemogelijkheden 68 Waarom hebben we tools nodig?
Er zijn niet echt nadelen, echter wel valkuilen - setup is arbeidsintensief - hoge onderhoudseisen - upgrade van de tool vereist de nodige aandacht - a fool with a tool is still a fool 69 Zijn er ook nadelen?
Er zijn verschillende soorten tools aanwezig die je job als testcoördinator kunnen vereenvoudigen - tools voor het plannen en het beheren van de testen - tools voor het ontwerpen van de testen - tools voor het uitvoeren van de testen - tools voor het debuggen en het analyseren van de code 70 Welke tools zijn er?
Niet blijven bij de traditionele tools Er zijn meer tools dan Quality Center - Jira - defect tracking - Mantis Bug Tracking - MS Excel - Notepad - CSV editors -... Concreet 71
We kennen de opdracht en alle betrokken partijen We kennen de doelstellingen van de testopdracht We weten wat we gaan testen We weten hoe we dat gaan testen We weten wat onze criteria zijn waar we naartoe gaan werken We weten hoeveel ons dit kost en wanneer we deze activiteiten zullen uitvoeren We zijn praktisch georganiseerd om al het voorgaande te kunnen uitvoeren We zijn met de uitvoer begonnen en we proberen deze onder controle te houden We hebben gerapporteerd over de voortgang en hebben op het einde van de testen een finaal testrapport opgesteld De evaluatie van de testopdracht is afgerond en wordt meegenomen naar de volgende opdracht 72 We kunnen het makkelijker maken voor onszelf
Online informatie - www.tmap.net - veel bruikbare checklists - www.testforum.nl - bijzonder actief forum - www.erikboelen.be - mijn eigen testblog Boeken - Lessons learned in software testing, Cem Kaner - TMAP Next, Michiel Vroon, Tim Koomen - Testen 2.0, Anko Tijman Veel informatie beschikbaar 73
www.erikboelen.be Twitter - @destruise 74 Contact Erik Boelen +32 (0) 486 39 45 73 erik.boelen@me.com www.erikboelen.be @destruise