2. Valhelm verplicht! Ter ingeleide Korte biografie van testprofessionals anno nu Uitbreiding van het portfolio Boodschap milieubewust verpakken Testdiepgang in begrijpelijke taal Lucht-, zand- en cementmanagement Welke kant gaat de ontwikkeling op? In de ban van Boehm Ter afsluiting
3. Ter ingeleide Over de spreker, het vakgebied, andere disciplines, ontwikkelingen en het doel van deze presentatie
4. Ter ingeleide Rudi Niemeijer: informatica ingenieur, software ontwikkelaar sinds 1990, tester sinds 1994, zelfstandig sinds tester 1998, ISEB Testing Practitioner Testconsultancy Groep, testforum.nl (2003, 1600+ leden) Over mijn testhelden Wat er veranderde, wat (nog) niet veranderde Wijsheid uit andere disciplines Testen in het middelpunt van de belangstelling Iedereen kan testen: ICTer of niet-ICTer Het werk van een testprofessional anno nu
5. Korte biografie van testprofessionals anno nu Middelpunt, aandachtsgebieden, ambitieniveau, portfolio
6. Testen in het middelpunt van belangstelling klopperdeklop klikkerdeklik klopperdeklop klikkerdeklik
8. De hoogte van de lat Vroegtijdig betrokken zijn bij het begin van een nieuw traject met veel inbreng en sturing Niet alleen testuitvoering aan het eind, maar ook procesverbeteringen aan het begin Samenwerken met het team, maar ook eindcontroles uitvoeren Verantwoordelijk voor de totale kwaliteit van de software en alle fouten eruit! Niet alleen goed in ons eigen werk, maar ook anderen helpen hun werk te verbeteren De centrale spil, maar nooit op het kritieke pad VALHELMMOMENTEN
9. Uitbreiding van het portfolio Kwaliteitskenmerken, ISO 9126, statisch en dynamisch, de gebruikskwaliteit en het ontwikkelproces 1
10. Portfolio Interne- en externe kwaliteit Functionaliteit Betrouwbaarheid Bruikbaarheid Effici谷ntie Onderhoudbaarheid Portabiliteit Effectiviteit Productiviteit Veiligheid Bevrediging tester 6 21 Bron: ISO 9126/SQuaRE 25000 Proces- kwaliteit be誰nvloedt hangt af van Gebruiks- kwaliteits be誰nvloedt hangt af van gebruiks- context Geschiktheid Juistheid en volledigheid Koppelbaarheid Beveiligbaarheid Bedrijfszekerheid Foutbestendigheid Herstelbaarheid Duidelijkheid Leerbaarheid Bedieningsgemak Aantrekkelijkheid Tijdsbeslag Middelenbeslag Analyseerbaarheid Wijzigbaarheid Stabiliteit Testbaarheid Aanpasbaarheid Installeerbaarheid Samenwerkbaarheid Vervangbaarheid
11. Het softwarerealisatieproces in het kort Een chaotisch softwareontwikkelproces leidt zelden tot foutloze software en nog veel minder vaak tot bruikbare en betaalbare oplossingen Maar ook foutloze software kan volledig onbruikbaar blijken op het moment van in-productiename Solide programmeermethoden garanderen nog geen foutloze software Ook een degelijk ontwikkelproces zorgt in het geheel niet automatisch voor solide programmeerpraktijken Kortom: er kan een hoop misgaan 1 Uitbreiding van het portfolio (testen binnen het kwaliteitsmodel)
14. Hoe gaat dat met boodschappen De verzender denkt goed na over de betekenis die hij wil overbrengen en kiest de bewoordingen die passen bij de ontvanger en de situatie De ontvanger luistert goed naar de uitgesproken boodschap en probeert een mentaal beeld van de betekenis te vormen De verzender en ontvanger controleren of het juiste beeld is overgebracht Yeah, right. Klinkt dat als een tester en ontwikkelaar? Ogden en Richards The Meaning of Meaning en de Semiotic Triangle (driehoek van de symbolenleer)
15. ? Een Kat Mijn beeld van wat een kat is Een beschrijving van mijn beeld van wat een kat is SPECIFICATIE
16. Wat heb ik daar mee te maken? Een groot deel van de fouten in documentatie en software vindt zijn oorzaak in communicatieproblemen en een verkeerde perceptie Het kunnen voorspellen van communicatie- en perceptieverstoringen helpt in het formuleren van een testaanpak Ook de werkrelatie met ontwikkelaar, ontwerper en klant verbetert met begrip van perceptie Immers: in een verschillende beleving wordt een boodschap anders aangevuld 2 Boodschap milieubewust verpakken (begrip voor het cognitieve proces)
17. Testdiepgang in begrijpelijke taal Laten we er niet omheen draaien en zeggen wat we gaan doen en doen wat we hebben gezegd 3
18. Het perspectief van de belanghebbenden kans impact Klant en bedrijfsproces Leverancier en ontwikkelaars Kans Impact
19. Toekennen van testontwerptechnieken Proces Cyclus Test Beslistabellentest Grenswaarden Classification Tree Method Exploratory Testing Algoritmetest Grenswaarden Error Guessing Equivalentieklassen kans impact II IV III I
21. Stel vast dat .. .. de berekeningen op alle schermen onder alle omstandigheden het gespecificeerde resultaat opleveren; .. bij het initieel openen van ieder scherm alle user-interface componenten de juiste default waarde en state (zichtbaar, klikbaar) vertonen; .. de 5 meestvoorkomende gebruikershandelingen met ieder scherm kunnen worden uitgevoerd; .. met een jaarvulling gegevens geen enkel scherm bij de meestvoorkomende gebruikershandelingen meer dan 1 seconde een zandloper toont; .. alle mogelijke lees-schrijf-wijzig-verwijder handelingen op ieder scherm foutloos werken.
22. Testclaimformuleringen Formulering van de diepgang van testen in natuurlijke taal, geen modellering Meerdere TCFs combineren tot een werkbaar geheel Geen vervanging van testbasis, testspecificaties of testspecificatietechnieken Bruikbaar over de verschillende manieren van testen heen Een lijstje testclaimformuleringen leidt heel snel tot opmerkingen als maar dan missen we dit.. Ideaal! Tussen de 10 en 20 TCFs lijkt nu de maat Kwaliteitsattributen mooi in te bedden Prima te combineren met de risicomatrix
23. Testclaimformuleringsproces Meeting met deelverzameling stakeholders Iteratief proces: Tester vraagt om de zorgpunten die nog leven Formuleert een testclaim om het zorgpunt heen Leest de formuleringen voor en vraagt wat missen we dan? Na een tijdje zijn de zorgpunten geaddresseerd De testclaimformuleringen zijn nu opgesteld De grootheden moeten nu worden achterhaald (de meestvoorkomende, representatieve set, normaal gebruik, etc) De testclaimformuleringen worden nu verdeeld over de testsoorten en naar wens verwerkt in een risicomatrix
24. Voorbeeld testclaimformuleringen in de risicomatrix Top-5 gebruikershandelingen Volledige beschreven functionaliteit Default-waarden en default-state Alle berekeningen werken goed Minder 1 seconde wachttijd bij normaal gebruik Pilotsessie levert geen verrassingen op Tien willekeurige gebruikers kunnen binnen een half uur aan de slag Nooit meer dan 3 klikken Altijd juiste order bij juiste klant Maximale vulling van de database geen probleem kans impact II IV III I
25. Voor gevorderden.. Nuancering met alle, belangrijkste, enkele, selectie van, .. De kwaliteitsattributen een voor een aflopen Hou de verantwoordelijkheden in de gaten; systeemtest versus acceptatietest De testbasis kan van alles zijn: specificatie, handleiding, oud systeem, the oracle assumption Maak de testclaimformuleringen niet te ingewikkeld: beter een paar combineren dan een megaclaim 3 Testdiepgang in begrijpelijke taal (toepassen van testclaimformuleringen)
26. Lucht-, zand- en cementmanagement Close to the Madding Crowd (Jens Krause), de kracht van de groep en de tester als richtinggever 4
27. Verlanglijstje van een jarige tester Iedereen werkt volgens dezelfde methodiek Er is een betrouwbare projectplanning De documentatie is altijd op orde Software wordt op tijd opgeleverd Er zitten wel fouten in de software, maar niet veel en altijd op de plek waar de testgevallen ze vinden De klant doet acceptatietesten zonder daarbij de systeemtesten te overlappen De klant heeft een acceptatietest ..
28. Hoe krijg je het betere testen op de kaart? Vanuit de hi谷rarchie methoden en technieken verplicht stellen Alle mogelijke standaarden en richtlijnen beschikbaar maken Voorbeelden voor iedere praktische situatie Methoden en technieken verplicht stellen Audits en controles op de naleving Kwaliteit prevaleert boven tijd en geld Afdeling software kwaliteit en test management Zodra er ruimte en behoefte is voor verbetering deze implementeren en borgen Verbeteringen van binnen uit
30. Let op bij verbeteringen van binnen uit Het helpt om de doelen realistisch te houden Timing is van het allergrootste belang Er is een ideaal moment voor iedere vernieuwing Oefen in de ook goed, dan niet reactie Niet meer dan 1 of 2 keer richten per jaar Richten is iets anders leiden Wisdom of Crowds 4 Lucht-, zand- en cementmanagement (over subtiele verbeteringsprocessen)
31. Welke kant gaat de ontwikkeling op? De testaanpak toespitsen op de ontwikkelmethode, linksom of rechtsom, met en zonder specificaties testen 5
33. Symbolische Software Modellering Feedbacksessies tussen Opdrachtgever Ontwerper Bouwer Tester Structured Walkthrough met klant, bouwer en tester Documentinspecties door klant, bouwer en tester Systeemtesten door tester Acceptatietesten door opdrachtgever SPECIFICATIE
34. Linksom.. Documentatie niet leidend; representant maatgevend Feedbacksessies met ontwerper, opdrachtgever, bouwer en tester Logboek met opmerkingen uit de feedbacksessies Tester heeft richtende rol bij de sessies, zorgt tevens voor een werkende testomgeving en houdt de administratie bij Testdoelformuleringen op platformniveau en functionaliteit die door de techniek wordt gedicteerd Adaptief onderhoud in een latere fase is in potentie een groot probleem
35. Rechtsom.. Structured walkthrough (informatieoverdracht) Documentinspecties (fouten in documentatie) Systeemtesten en acceptatietesten Totale afhankelijkheid van sluitende documentatie Dwars door het midden Varianten op het thema lijken effici谷nter dan ze zijn Projecten kunnen volledig misgaan door een misperceptie van de rotatierichting 5 Welke kant gaat de ontwikkeling op? (over testen met en zonder specificaties)
36. In de ban van Boehm Kunnen documentinspecties ooit uit? 6
37. Waar is Boehm als je m nodig hebt! Al enkele maanden worden documentinspecties gehouden De voorbereidingen worden nu centraal gedaan zodat de opkomst beter is Er worden flink wat fouten gevonden De ontwerpers waren in eerste instantie wat terughoudend, maar gaan nu lekker mee Het management wil graag weten, wat de kosten/baten van de documentinspecties zijn (oeps)
38. Cijfers van de inspectiebladen Er zijn 19 functioneel ontwerpen ge誰nspecteerd met in totaal 262 paginas Er zijn 301 fouten gevonden (spelfouten uitgesloten) waarvan er 190 effect hadden gehad op de volgende fases (OTAP gebaseerd) Er is 110 uur besteed aan het uitvoeren van de inspecties (0,6 uren per gevonden fout) De gevonden fouten hadden 732 uur gekost voor bouw, systeemtest, acceptatietest en/of productie De documentinspecties hebben daarom 622 netto uren opgeleverd
39. Omdat de testers documentinspecties op functioneel ontwerpen uitvoeren (zet je valhelm maar op, want hier komen de ontwerpers!) 622 uur bespaard!
40. Ja, maar.. Ontwerpers zijn het niet eens met de gevonden fouten, hadden ze zelf ook wel gevonden 622 uur? Dat is zowat de helft van de ontwerptijd! Hebben we de helft van de tijd uit onze neus gegeten? Normaal vertel ik er altijd iets bij en dan was het wel goed gekomen Echt inhoudelijke fouten worden nooit gevonden Ja, hallo, daar hebben ze toch geen ontwerp voor nodig? Dat inspecteren kost allemaal veel te veel tijd en is helemaal niet nodig, we doen tenslotte al peer reviews
41. Berekeningen en gevolgen (1) minor, Major en Critical definities van belang: zou kunnen, zal en overstijgend effect op het product Geen spelfouten! Slechts deel van minor bevindingen! Statistieken goed bijhouden op het inspectieformulier Aanname: 20% van de FO-fouten in bouw gevonden, 60% in de systeemtest, 15% in de acceptatietest en 5% in productie Uren die een fout kost afhankelijk van de fase: B=0,25 T=1 A=8 P=40 t = 0,2 * 190 * 0,25 + 0,6 * 190 * 1 + 0,15 * 190 * 8 + 0,05 * 190 *40 = 732
42. Berekeningen en gevolgen (2) De ontwerpers staan direct voor de deur om te verklaren dat de cijfers absoluut niet kunnen kloppen Hoe kunnen er nu 622 uur bespaard zijn als er niet meer dan 1500 uur in het ontwerpen is gaan zitten? Hebben ze gelijk?
43. Walkthroughs en inspecties Inspectie: vinden van fouten Walkthrough: kennisoverdracht Wat betekent het als een ontwerper meer waarde toekent aan een walkthrough dan aan een inspectie? 6 In de ban van Boehm (managementcijfers over documentinspecties)
45. Achtergrondinformatie (1) Normering hoofdbescherming NEN-EN 397/NEN-EN 443 en NEN-EN 812 ( http:// www . nen . nl ) Far from the Madding Crowd (Thomas Hardy, 1874) http://www.gutenberg.org/etext/27 Close to the Madding Crowd (Jens Krause, 2009) http://planetearth.nerc.ac.uk/features/story.aspx?id=402 The Meaning of Meaning (Charles Ogden en Ivor Richards, 1923) http://www.bol.com Spreadsheet risico-analyse http:// www .testconsultancy. nl /index. php / downloads #28 Certified tester
46. Achtergrondinformatie (2) U spreekt met de Keuringsdienst van Waarde http:// www .testconsultancy. nl /index. php / downloads #49 Nederlandstalig discussieplatform softwaretesters http://www.testforum.nl ISO 9126 toegelicht http://www.testconsultancy.nl/index.php/downloads#4 Biografie Barry Boehm http://en. wikipedia . org / wiki / Barry _ Boehm
47. Vragen? 1 Uitbreiding van het portfolio (testen binnen het kwaliteitsmodel) 2 Boodschap milieubewust verpakken (begrip voor het cognitieve proces) 3 Testdiepgang in begrijpelijke taal (toepassen van testclaimformuleringen) 4 Lucht-, zand- en cementmanagement (over subtiele verbeteringsprocessen) 5 Welke kant gaat de ontwikkeling op? (over testen met en zonder specificaties) 6 In de ban van Boehm (managementcijfers over documentinspecties)
48. Dank voor uw aandacht! Valhelm verplicht! door Rudi Niemeijer ( [email_address] ) Deze presentatie vindt u op www.testconsultancy.nl/index.php/downloads en op www.testnet.org/Produktie/Bibliotheek/Presentaties.html
Editor's Notes
#2: Over de presentatie Softwareontwikkelstrategie谷n anno 2010 zijn steeds vaker gebaseerd op 'lightweight', 'just-in-time' en 'good enough' principes die, naast de vele voordelen, ook een aantal in het oog springende nadelen hebben: als een project uitloopt is het bijna altijd de productkwaliteit en de testfase die onder druk komen te staan. Om brokken en valpartijen aan het eind van een project te voorkomen is het daarom effectief om niet met testen te wachten totdat er een werkend stuk software beschikbaar komt maar de hele looptijd voor het ontplooien van testactiviteiten te benutten. Dit betekent dat er van de geijkte paden afgeweken moet worden, maar veel testers hebben echter geen idee welke rol zij zonder ontwerpen en software kunnen vervullen. In 'valhelm verplicht' wordt de tester meegenomen in de mogelijkheden van het 'valideren zonder je te bezeren', ofwel 'testen zonder software'. Deze activiteiten bestaan niet uit het achter de computer uitwerken van mastertestplannen of testscriptsjablonen, maar het mengen in overleggen, voeren van discussies en houden van interviews. Dat dit niet altijd zonder slag of stoot gaat mag duidelijk zijn. Enige gepaste beschermingsmaatregelen zijn hier dan ook aanbevelenswaardig. Presentatieopening Anno 2010 worden testers vroegtijdig betrokken en vormen ze een belangrijke schakel in de totaalkwaliteit van software. Maar of dat altijd zonder problemen gaat?
#3: Inhoud van deze presentatie Ter ingeleide Korte biografie van testprofessionals anno nu Uitbreiding van het portfolio Boodschap milieubewust verpakken Testdiepgang in begrijpelijke taal Lucht-, zand- en cementmanagement Welke kant gaat de ontwikkeling op? In de ban van Boehm Ter afsluiting
#5: Bio van de spreker Rudi Niemeijer, sinds 1994 werkzaam als tester, heeft achtergronden in de elektronica, grafisch ontwerp, fijnmechanica, robotica en tekstschrijven. Hij is ingenieur in de informatica, ISEB Testing Practitioner en weet als geen ander mensen enthousiast te krijgen in het vakgebied testen. Rudi is sinds 1998 vennoot van Testconsultancy Groep (www.testconsultancy.nl), ondermeer bekend als workshopdocent, initiatiefnemer van testforum.nl http://www.testforum.nl en kritische recensent van testboeken. In 2009 verzorgde hij, samen met Martin Pol, de TestNet thema-avond 'NoorderTest 2009' met de presentatie 'U spreekt met de Keuringsdienst van Waarde'.
#7: Kerntaak Het vinden van fouten in software wordt vaak als de kerntaak van een tester gezien. Zodra software voor het eerst gebruikt kan worden, zijn het de testers die een oordeel vellen over de kwaliteit ervan. Toeschouwers Zodra een tester met zn werk begint, is er een niet aflatende aandacht van zon beetje iedereen die in de software is ge誰nteresseerd; van ontwerper en ontwikkelaar, projectleider en opdrachtgever, tot potenti谷le eindgebruikers, beheerders enzovoorts. Downside Als er laat in het softwareontwikkelproces nog veel fouten worden gevonden, is niemand blij. Zeker als dat ook nog eens niet direct aan het begin van de start van het testen is. De waardering die testers verwachten blijft dan nogal eens uit, of vervalt in een rechtstreekse kritiek op het testproces. Het kan geen kwaad om als tester altijd een valhelm te dragen!
#8: Wat we moeten We zijn druk met de dingen die we moeten doen om de testfabriek aan de gang te houden. Niet dat we nu de hele dag bezig zijn met professionalisering of teststrategie谷n, maar het hoort tot het portfolio van de testprofessional anno 2010. Als we het goed doen, zijn veel van deze activiteiten onzichtbaar voor de rest van het project: wij hebben onze zaakjes voorelkaar zodra er van ons actie wordt verwacht. Niet vergeten Aan het eind van de dag worden we immers afgerekend op de kwaliteit van ons werk, dat alles verband houdt met de kwaliteit van de software, ons eigen ambitieniveau, of we onze afspraken nakomen en dat we de planningen die we afgesproken hebben, halen.
#11: Maar we willen ook veel Anno nu is de tester ge谷volueerd van een professionele dwarsligger naar een testprofessional die overal een antwoord op weet, van het testen van functionaliteit tot performance, concurrency, security en alle andere kwaliteitskenmerken die we uit het ISO 9126 kwaliteitsmodel kennen. We zijn goed in het testen van de interne- en externe kwaliteit van onze software, maar als het aan ons ligt verleggen we waar nodig onze horizon naar het gebruik van de software in de praktijk. De klant is onze nieuwe beste vriend! Gedeelde verantwoordelijkheden! En als we toch bezig zijn, dat ontwikkelen van software kan vast veel beter dan nu gebeurt. Laten we beter communiceren! Eerder betrokken worden! Eerder beginnen met testen! Reality check Zijn we allemaal al zover?
#14: De boodschap in perspectief Software maakt zich niet zelf. Ook kleine schermpjes met op het oog weinig functionaliteit hebben een flinke tijdsinvestering van een ontwikkelaar achter de rug. Een tester kan en mag niet vervallen in consumentengedrag: het is zijn werk om fouten te vinden. Maar ook een diplomatiek getrainde tester zal wel eens een zucht van het is nog niet goed laten vallen en in combinatie met de nodigde tijdsdruk ontstaat dan nogal eens een geirriteerde ontwikkelaar. Valhelm verplicht!
#15: De theorie van het overbrengen van informatie Dat het niet altijd gaat zoals in theorie zou moeten is duidelijk. Maar hoe kan dat?
#16: Symbolenleer (semiotics) Ogden en Richards hebben in 1927 hun onderzoek over het overbrengen van boodschappen gepubliceerd. Het heeft veel relevantie in ons vakgebied. Kort gezegd komt het erop neer dat er een onderscheid bestaat tussen werkelijkheid, beschrijving van de werkelijkheid en beeld van de werkelijkheid. Bij het overbrengen van informatie van de ene persoon naar de andere vindt er een vertaling plaats van beeld naar taal naar beeld. Door deze vertaling verdwijnt er informatie, maar wordt er door de ontvanger ook informatie toegevoegd. In ons vakgebied hebben we op twee manieren met deze symbolenleer te maken. In het voorbeeld is te zien, dat hoe nauwkeurig wij ons als tester ook uitdrukken, we er rekening mee moeten houden dat de boodschap niet overkomt. Daar kan de ontvanger van de boodschap niets aan doen: zo werkt communicatie met taal. Op een ander vlak hebben wij ook met symbolenleer te maken: het ontwikkelen van software gaat vaak met taal gepaard.
![Dank voor uw aandacht! Valhelm verplicht! door Rudi Niemeijer ( [email_address] ) Deze presentatie vindt u op www.testconsultancy.nl/index.php/downloads en op www.testnet.org/Produktie/Bibliotheek/Presentaties.html](https://image.slidesharecdn.com/valhelmverplicht18-12855757796913-phpapp01/85/Valhelm-Verplicht-1-8-48-320.jpg)