Valhelm verplicht! Presentatie door Rudi Niemeijer

Presentatie over: "Valhelm verplicht! Presentatie door Rudi Niemeijer"— Transcript van de presentatie:

1 Valhelm verplicht! Presentatie door Rudi Niemeijer http://www.testconsultancy.nl

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’: ICT’er of niet-ICT’er  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…

7 betrokkenheid teststrategie testorganisatie communicatie testmanagement planning en budgettering kengetallen bevindingenadministratie testproducten inzet methode professionalisering testontwerp testtoolstestomgevingen Tijd Product kwaliteit Middelen Ambitie Geld

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 V A L H E L M M O M E N T E N

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 Proces- kwaliteit beïnvloedt hangt af van Effectiviteit Productiviteit Veiligheid Bevrediging tester 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 6 21 Bron: ISO 9126/SQuaRE 25000

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)

12 Boodschap milieubewust verpakken Helder beeld, heldere bewoordingen, interpretatieruimte, veranderende omstandigheden 2

13 0100111001.. Romm el! Error klopperdeklop… klikkerdeklik… klopperdeklop… klikkerdeklik… Error

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 SPECIFICATIE? Een Kat Mijn beeld van wat een kat is Een beschrijving van mijn beeld van wat een kat is

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 kans impact II IV IIII Proces Cyclus Test Beslistabellentest Grenswaarden Classification Tree Method Exploratory Testing Algoritmetest Grenswaarden Error Guessing Equivalentieklassen

20 ?

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 TCF’s 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 TCF’s 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 kans impact II IV IIII 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

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’

29 1:25, onderzoek Jens Krause, 2009

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

32 Symbolische Software Modellering SPECIFICATIE 0100111001....0100111001

33 Symbolische Software Modellering SPECIFICATIE 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

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 pagina’s  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)

44 Ter afsluiting Samenvatting en handige informatie om zelf mee verder te gaan, referenties en links

45 Achtergrondinformatie (1)  Normering hoofdbescherming NEN-EN 397/NEN-EN 443 en NEN-EN 812 (http://www.nen.nl)http://www.nen.nl  Far from the Madding Crowd (Thomas Hardy, 1874) http://www.gutenberg.org/etext/27 http://www.gutenberg.org/etext/27  Close to the Madding Crowd (Jens Krause, 2009) http://planetearth.nerc.ac.uk/features/story.aspx?id=402 http://planetearth.nerc.ac.uk/features/story.aspx?id=402  The Meaning of Meaning (Charles Ogden en Ivor Richards, 1923) http://www.bol.com http://www.bol.com  Spreadsheet risico-analyse http://www.testconsultancy.nl/index.php/downloads#28 http://www.testconsultancy.nl/index.php/downloads#28

46 Achtergrondinformatie (2)  U spreekt met de Keuringsdienst van Waarde http://www.testconsultancy.nl/index.php/downloads#49 http://www.testconsultancy.nl/index.php/downloads#49  Nederlandstalig discussieplatform softwaretesters http://www.testforum.nl http://www.testforum.nl  ISO 9126 toegelicht http://www.testconsultancy.nl/index.php/downloads#4 http://www.testconsultancy.nl/index.php/downloads#4  Biografie Barry Boehm http://en.wikipedia.org/wiki/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 (niemeijer@testconsultancy.nl)niemeijer@testconsultancy.nl Deze presentatie vindt u op www.testconsultancy.nl/index.php/downloadswww.testconsultancy.nl/index.php/downloads en op www.testnet.org/Produktie/Bibliotheek/Presentaties.html www.testnet.org/Produktie/Bibliotheek/Presentaties.html