Thursday, 30 September 2010

Risico- en review sessies, droogzwemmen en evalueren. Hoop gezwets of kosten besparend?

Veel testers willen graag betrokken zijn vanaf het begin van een ontwikkeltraject. Dit omdat we graag voorbereid willen zijn voor als we echt aan de fase "testuitvoer" gaan beginnen. Dat ligt in een traditionele ontwikkel methodiek (of bij geen ontwikkelmethodiek) namelijk op het kritieke pad. Als men de ontwerpen aan het maken is kan je al bezig met je teststrategie, wat leidt tot een testplan, en vervolgens je testgevallen gaan definiëren.

Er is nog een reden: in het begin van een ontwikkeltraject kan je al veel problemen uit de documentatie halen met relatief weinig inspanning. Een alinea aanpassen in een ontwerp is goedkoper dan later de software aanpassen en hertesten. In vergelijking met een software systeem wat al in productie draait zijn de relatieve kosten die je maakt om een probleem op te lossen al helemaal moeilijk in te schatten en kan dit exponentieel oplopen.

Maar hoe ga je daar als tester mee om? Er zijn een aantal technieken om ontwerp documentatie beter van kwaliteit te maken en er voor te zorgen dat we doelgerichter bezig te zijn met het maken van deze documentatie.

Review sessies
Met review sessies van documentatie kan je al veel problemen in de fase "ontwerp" er uit halen. Het niveau van review sessies loopt van samen in een vergaderruimte gaan zitten en door het document lopen, tot aan een formele review met rolverdeling. Waarbij bij mee gestructureerde reviews meer voorbereiding voor nodig is door alle deelnemers van de review sessie.

Product risico analyses
Voor een moderne testaanpak ga je werken vanuit de risico´s van het nieuwe systeem, waarbij je de hele organisatie betrekt. Op deze manier kan je gericht gaan zoeken naar de grootste problemen in een software systeem, waarbij je de grootste risico´s het eerst afdekt. Als je een product risico analyse vroeg in het traject uitvoert helpt dit ook de ontwerpers en ontwikkelaars om een focus op bepaalde gebieden te leggen, waardoor er al minder problemen ontstaan, juist omdat deze sessies inzicht geven in de risico gebieden.

Droogzwemmen (virtueel testen)
Een nieuwe kreet? De term 'Virtueel testen' heb ik nog niet zo lang geleden bij een presentatie gehoord. Procedures oefenen met alle beheerders van een systeem. Hier kan je ook weer denken aan samenzitten en door de business procedures en eisen lopen en bekijken of iedereen hetzelfde beeld heeft. Je kan kort een paar uur samen gaan zitten, of een sessie van een dag beleggen, waarbij je de rollen ' moderator' en ' tester' apart belegd, de testen voorbereid. En volgens de presentatie die ik gezien heb kan je een publiek van de doorsnede van de organisatie erbij plaatsen. 

Evaluaties
Iets wat nog te vaak wordt vergeten of wat vaak afvalt door tijdsdruk en chaos in projecten is het af en toe samenzitten om het traject door te spreken en te bekijken waar je het beter kan doen in een volgende iteratie of fase. Elk project loopt toch weer anders en er kunnen altijd verbeteringen aangebracht worden in de manier van werken. 

Belanghebbenden
Bij de toets-soorten, zoals hierboven genoemd heb je altijd de meeste belanghebbenden van het nieuwe IT systeem nodig, de gebruikers, de ontwikkelaars, ontwerpers, architecten, business managers, testers, sales, et cetera. Dit verschilt per systeem, een intern software product behandel je anders dan een IT systeem die over meerdere onderdelen van de organisaties, of over verschillende organisaties gaat.


Testplan
Nu ben je bezig met je testplan, of in ieder geval je teststrategie en je bespreekt je toets strategie met je opdrachtgever:
  1. Product risico analyse in de analyse fase (levert algemene risico's op)
  2. Review sessies in de ontwerp fase
  3. Virtueel testen in de ontwerp fase
  4. Review sessies in de bouw-fase (dit meer gericht op testdocumentatie)
  5. Voor elke testfase opnieuw een product risico sessie (ontwikkel-, systeem-  en acceptatietesten)
  6. Evaluatie momenten na testfases over de ontwikkel en test aanpakken
Kosten
  • Product risico analyses: 3 keer een risico sessie, 8 personen per keer, 3 uur per sessie (72 uur)
  • Review sessies: Zelfde als bij PRA (72 uur)
  • Virtueel testen: 1 keer, maar dan met 15 personen, hele dag (120 uur)
  • Evaluatie: 3 keer met beperkt aantal mensen, zeg 4 personen, 2 uur per sessie. (24 uur)
Ditt leidt tot de volgende inzet van resources: 72 uur + 72 uur + 120 uur + 24 uur = 288 uurPer sessie voorbereiding en verwerking van 30% (puur voor de inschatting) = 87 uur
    In totaal komen we dan op 375 uur, met werkweken van 36 uur, kom je ongeveer op 10 volledige werkdagen die het project moet besteden aan sessies ten behoeve van kwaliteit op de documentatie. En deze investering kan je later een veelvoud van dit aantal dagen opleveren. En dat is geen fabeltje meer, elk van deze technieken hebben zich in de praktijk al bewezen.

    Hoe leg ik dit uit aan de projectmanager
    Deze blog begon ik eigenlijk met het idee van: Hoe kan ik dit verantwoorden naar mijn opdrachtgever? Dat gaat men nooit doen. De kreet "Poolse landdagen" heb ik al wel vaker gehoord, maar dat is niet van toepassing op dit soort sessies, ze hebben een doel en leiden tot acties en resultaat.

    Het aantal dagen wat ik hier heb berekend is natuurlijk een 'nogal vrije' inschatting, maar valt op een ontwikkeltraject van een half jaar wel mee. En als je het objectief bekijkt levert het zeker wat op. En hoe vaker je dit soort sessies organiseert, hoe effectiever en efficiënter ze worden.

    Van de week dacht ik nog: "dat gaat een opdrachtgever nooit accepteren", maar nu zo uitgeschreven heb ik toch weer het beeld voor mij zelf gecreëerd dat het werken op zo'n manier leidt tot betere producten en doel gerichter werken. Tevens leiden alle genoemde onderdelen ook tot een betere samenwerking. Vooral in grotere projecten ontmoeten mensen elkaar pas richting het einde van een project als alles samenkomt, met deze sessies ontstaat eerder een samenwerking en eerder persoonlijk contact.

    Dus eigenlijk pleit ik er voor om dit standaard in elk test traject te implementeren, of om er in ieder geval over na te denken en te bespreken met je projectleider. Niet alle projectleiders zullen over te halen zijn, maar de grote voordelen en besparing in de kosten van software ontwikkel trajecten zal toch wel wat projectmanagers over de grens trekken vermoed ik.

    Wednesday, 29 September 2010

    Testpromotie tip 7: Positief blijven over testen en dat uitstralen

    Dit stuk hoort bij mijn andere log: "29 Tips om testen te promoten in je organisatie"

    Blijf in je gesprekken en communicatie altijd positief over testen, straal passie voor het testvak uit.

    Iets wat toch veel moeite kan kosten. Als tester zie je vaak de slechte karaktereigenschappen van een software product en deze blijven vaak hangen omdat je op de werkvloer vooral bezig bent om te communiceren over de problemen die je tegenkomt.

    Dan kan het lastig zijn bij het brengen van een boodschap over testen om een positieve houding te houden. Toch proberen om de zaken positief te formuleren. "Daar komt de tester, ojeee...." moet je zien te voorkomen, alhoewel dat natuurlijk niet altijd te vermijden is. Als tester kom je bijna altijd met slecht nieuws.

    Hier nog wat tips op dit gebied die je misschien kunnen helpen om niet als "de zeikerd van het project" over te komen.

    Niet meegaan in de negatieve trend
    Vaak ben je (gelukkig) niet de enige kritische medewerker in een traject. Zeker als tegen een einde van een project zaken spannend beginnen te worden zullen bepaalde mensen negatiever worden over de software. Mocht je dit waarnemen dan kan je twee dingen doen: Alles beamen dat het niet zo goed loopt, of de kritiek op het project relativeren. Dat laatste is wel heel lastig, maar toch zal je moeten proberen om deze relativering in je dagelijkse communicatie te stoppen. Jij bent dé expert van de softwareproblemen en als je mee gaat praten in de negatieve zin, zal je ook dat stempel krijgen van negatief.

    Om hiermee om te gaan is het misschien een goed idee om wat vaker te luisteren en als je iets wilt zeggen toch even stil te blijven in een gesprek. Luisteren naar de klachten in een project (of dit nu bevindingen of project problemen zijn), kan je helpen om een dieper begrip te krijgen van de échte oorzaken van de klachten.

    Bespreken van dit soort klachten  kan je dan het best doen in een één op één gesprek met de projectmanager of een andere collega die niet betrokken is bij het project. Zo kan je vanuit zijn/haar perspectief andere inzichten verkrijgen die je dan weer kan gebruiken in je communicatie. Voor de meeste zaken is wel een oplossing, maar dat vereist vaak even afstand nemen.

    Bevindingen altijd met een groep projectmedewerkers bespreken
    Iedereen mag bevindingen opvoeren in een bevindingen tool. Zorg er altijd voor dat er een bevindingen overleg wordt gepland met de juiste mensen uit het project (projectleider, ontwikkelaar, een tester, et cetera). Samen bespreek je de bevindingen één voor één door. Je bepaalt de impact van het probleem samen, of je het probleem gaat oplossen of niet, of later en wie het probleem gaat oplossen. Doe dit nooit alleen, anders wordt je als tester aangekeken op dit soort zaken. 

    Denk verder dan alleen testen en kom met voorstellen
    Je hoeft je niet te beperken tot het alleen testen van IT producten. Je kan ook in project overleggen tips geven hoe problemen van te voren eerder gevonden kunnen worden. Dit door te vragen of een review van documentatie misschien een idee is, of ontwikkelaars het werk van elkaar bekijken. 

    Testen is een mooi vak!
    Als iemand begint te klagen over het testen of daaromtrent zich negatief gedraagt, dan ligt het vaak aan het gebrek aan kennis wat testen nu werkelijk is. Wij testers zijn geen zeikerds, we klagen niet over elk detail, maar we willen wel integer en objectief blijven bij het uitvoeren van tests en het maken van testrapportages. Dit is een balans die elke tester moet vinden in zijn eigen professionaliteit. Blijf tegen mensen zeggen dat testen leuk is, hard werken en lastiger dan men vermoedt. De zinnen "testen is het mooiste vak binnen de IT"  en "een testafdeling is vaak de kennisbank van een organisatie" zijn af en toe fijn om te spuien, alhoewel er wel eens een wenkbrauw omhoog kan gaan bij een collega door dit te zeggen, helpt het wel in positieve zin.
    Presentaties geven over testen kan hier veel bij helpen.

      Sunday, 26 September 2010

      Testpromotie tip 5: Begin met testen

      Dit stuk hoort bij mijn andere log: "29 Tips om testen te promoten in je organisatie"

      Het ligt aan het niveau waar je organisatie of team al in zit natuurlijk, maar stel je voor er wordt nog niets getest en je wil nu toch wel eens dat dat een keer gebeurt.

      En de tekenen van het niet testen zijn overduidelijk:
      • Overbelaste helpdesk met veel klagende klanten / eindgebruikers.
      • Er zijn wel problemen in het product en iedereen weet er één of twee op te noemen. Er worden er elke keer maar een paar van opgelost
      • Projecten worden stopgezet door teveel problemen in producten.
      Mooi hoor, je bent zelf misschien geen tester, maar moet wel de kwaliteit bewaken, of je maakt je toch wel wat zorgen als je bovenstaande punten ziet. Begin maar eens met testen...
      • Vraag aan een (collega) programmeur of je zijn werk eerst eens mag bekijken voordat hij of zij het over de muur gooit naar de release manager
      • Is er een centrale punt waar alle software terecht komt, zoals een releasemanager of wie dan ook? Vraag dan eens of je alle software wat langs komt eerst een uurtje mag bekijken.
      • Bereken de kosten van alle problemen die langs de helpdesk komen. Uurtje werk kost x Euro, aantal mensen die zich er mee bezig houdt en de kosten van het oplossen van zo'n probleem. Dat soort zaken. Bespreek de besparing van van testen voordat de klant de software krijgt.
      • Bespreek de mogelijkheid om gebruikers uit te nodigen als men "bijna" klaar is met programmeren en en het zelf bijna goed genoeg vindt. Wel de gebruikers duidelijk maken dat het om een test gaat en dat er nog wel wat mis kan gaan en dat je ze daar voor hebt uitgenodigd
      Er is vast wel meer te verzinnen, ik zou zeggen, reageer op dit artikel en voeg je ideeën toe! Goede tips verwerk ik later weer in deze artikelen.

      Noordertest 2010, een review

      Deze week ben ik voor het eerst naar het Noordertest testevenement gegaan. Dit omdat ik nu in opdracht zit bij DUO in Groningen. Lekker dicht in de buurt dus dit keer. Het Noordertest evenement is in het leven geroepen voor de toch wel grote groep testers in onze noordse provincies, omdat de afstand naar de randstad toch veel mensen tegenhoudt om naar een testevenement te gaan. En dit terwijl we toch graag onze ervaringen delen en geïnformeerd willen worden over het laatste nieuws op het testvak gebied.

      Wat ik heb gezien bij Noordertest is dat er veel testers in het noorden zijn en gezien de scherpe vragen na presentaties en de goede discussies ligt de kennis op een hoog niveau.

      Ik ben zelf bij drie sessies geweest, ketentesten vanuit 6 invalshoeken, mensenwerk en leiderschap en virtueel testen. Hier mijn indruk.

      Ketentesten vanuit 6 invalshoeken
      Dit was een interactieve sessie, waarbij de spreker na een korte uitleg 6 stellingen over ketentesten neerlegde en ter discussie stelde aan de zaal. De spreker, Rik Marselis, is ondertussen een bekende op testevenementen. Hij is een goede spreker, duidelijk, met humor en altijd een mooie powerpoint presentatie op de achtergrond. Zijn presentaties zijn overigens altijd aan te raden om te bezoeken. Ook dit keer leidde hij een goede discussie over een aantal stellingen met betrekking tot ketentesten.
      - Ketentesten bij de overheid is anders dan anders
      - Testbeleid is een voorwaarde voor effectief ketentesten
      - Met zeven TPI NEXT aandachtsgebieden kun je ketentesten verbeteren
      - Ketentestregisseur is geen functie maar een rol
      - Hoe minder ketentestgevallen hoe beter
      - Integraal Keten Test Plan (IKTP) is heeeel anders dan Master Test Plan (MTP)

      Mensenwerk en leiderschap
      Dit was geen presentatie over testen, maar meer over organisatie en samenwerken. Altijd goed om verder te kijken dat je eigen vakgebied.

      De sprekers (Karin Bouius en Bert Hans van Eeden) werken bij het CJIB en zijn bezig met een cultuurverandering binnen de CJIB organisatie, er vanuit gaand dat persoonlijk leiderschap een basis is waaruit elk individu zijn werk op de beste manier kan doen en er een goede manier van samenwerken ontstaat tussen individuen die op deze manier in hun werk zitten. Hierbij gebruikt men de "7 eigenschappen van effectief leiderschap"  van Stephen Covey. De workshop die intern wordt gegeven duurt 2 werkdagen. Dit uurtje gaf inzicht hoe deze workshops worden gegeven en een inkijk op de ideeën van het CJIB hoe je een organisatie op deze manier kan indelen. Met uitleg, filmpjes en een oefening bevatte deze workshop alle onderdelen die je van een workshop mag verwachten. Het begrip paradigma en de vele manier van hoe je tegen situaties aankijkt werd behandelt in de oefening. Dit heeft mij wel wat stof tot nadenken gebracht. Ik ken zelf de 7 eigenschappen wel, maar vind het lastig om de praktijk te brengen, deze workshop heeft mij een klein stapje in de goede richting gegeven. 

      Virtueel testen 
      Met virtueel testen bedoelt de spreker het droogzwemmen, oefenen van procedures in een of meerdere sessies om zo belangrijke interpretatie verschillen en aannames die tot fouten leiden in documentatie al in een vroeg stadium eruit te kunnen halen. Op zich een goede manier en een goede aanvulling voor wat grotere IT systemen welke meerdere ketens omvatten. De presentatie kwam niet helemaal goed uit de verf en ik zelf begon pas interesse te krijgen bij de 5e of 6e slide. Ondanks dat begrijp ik wel de insteek van deze manier van toetsen en zie hier duidelijk een goede oplossing in om vroeg in het traject al bezig te zijn met het uiteindelijke product. Dit is een van de technieken die veel problemen kan voorkomen in en vroeg stadium en de kosten van een ontwikkeltraject kan beperkten in latere fasen (of in productie.)

      Goed dat dit weer eens wordt gepresenteerd, je zal dit soort technieken vaak niet als een standaard aanpak zien in een teststrategie, maar lijkt mij wel iets om over na te denken bij het maken van je teststrategie.

      Verder
      Tijdens het evenement heb ik wat collega's gesproken, veel bekende gezichten gezien "uit het westen" en nog een ex-collega her-ontmoet van een jaar of 3 geleden. Na de presentaties nog even gegeten en nagesproken over het evenement. Een professioneel test evenement, goed georganiseerd en op een professioneel niveau. Fijn om daarbij aanwezig geweest te zijn.
       

      Sunday, 19 September 2010

      Testpromotie tip 24: Ga naar testevenementen, neem je collega’s mee

      Dit stuk hoort bij mijn andere log: "29 Tips om testen te promoten in je organisatie"

      Hoe simpel is de tip: Ga naar testevenementen, neem je collega’s mee.
      Misschien niet gelijk het eerste waar je aan denkt bij het promoten van testen in je organisatie, maar toch.

      Veel testers gaan niet naar testevenementen en congressen, omdat het werk gebeurt in je eigen bedrijf en daarnaast heeft een mens ook nog een privé leven. Maar één of twee keer per jaar een testevenement bezoeken past wel binnen elk dieet. Dus probeer je collega's mee te nemen, misschien kan je binnen je bedrijf regelen dat dit als een "team building" dag wordt gezien, gevolgd door een etentje. Mij is het in ieder geval één keer gelukt om dit op deze manier te regelen.
      • Collega's praten de volgende dag over de gevolgde presentaties met andere collega's en met managers wat automatisch het denken over testen beïnvloedt.
      • Op testevenementen wordt je bedrijf ook eerder gezien als een serieuze testclub, wat het testen van buiten af promoot.
      • Een presentatie geven op een testevenement, waar je vanuit de praktijk van jou testorganisatie een verhaal verteld promoot niet alleen het bedrijf, maar ook intern zal je dan serieuzer worden genomen. Zorg wel dat je dit via interne nieuwsbrieven of anders intern communiceert.
      En een testevenement hoeft niet al te veel kosten, veel testevenementen zijn gratis. Als je bijvoorbeeld lid bent van Testnet, zijn alle evenementen gratis te bezoeken.

      Voor een volledige lijst van testevenementen, zie mijn website

      Testpromotie tip 23: Verspreid artikelen over test, vakbladen, maak kopieën, leg een bibliotheek aan.

      Dit stuk hoort bij mijn andere log: "29 Tips om testen te promoten in je organisatie"

      Als je de kans krijgt: verspreid artikelen over testen die je uit bladen haalt. Zeker als het te doen heeft met het domein waar je in bezig bent (performance testen, gebruikerstesten, de overheid, ...)
      Dat is makkelijker gezegd dan gedaan, want je moet deze artikelen wel ergens vandaan halen, dus is het eerst zaak om eens rond te gaan kijken. In deze blog wat internet test-nieuws tips en de eerste boeken voor je testbibliotheek.

      Test vakbladen
      Om te beginnen kan je de gratis testvakbladen gaan volgen. Ik heb al een lijst voor je gemaakt.
      Test websites
      Er zijn zoveel websites over testen dat je het eigenlijk niet meer goed kan bijhouden. Om het laatste nieuws over testen te vinden heb ik de volgende tips om eens te beginnen met rondkijken:
      Kast met boeken over testen
      Start je eigen bibliotheek en leen de boeken ook uit als iemand geinteresseerd lijkt. Minimaal zal je toch de volgende boeken in je kast willen hebben, zowel voor de beginnende als gevorderde tester, je collega ontwikkelaars, ontwerpers en managers. Hierbij een lijst van goede testboeken die mij geholpen hebben de afgelopen jaren. Let wel op met het kopen van boeken, er is ook veel onzin uit over het testen van software.
      * De links in deze lijst gaan gelijk door naar bol.com, kan je ze gelijk bestellen :-)
      Lessons Learned in Software Testing
      Lees elke dag een tip uit dit boek. Dit boek is geschreven door twee testgoeroes uit Amerika, lekker leesbaar en de beste "tip lijst" die je kan krijgen uit de praktijk van het software testen
      Reviews in de praktijk
      Ook handig voor ontwerpers die kwaliteit gericht willen werken, hoe kan je het best je documentatie reviewen, waar begin je, hoe bouw je dit binnen je organisatie op tot een goed niveau. En ook belangrijk: Waarom zouden we documenten reviewen en wat levert het op.
      SmarTEST
      Een andere manier van gestructureerd testen, goed uitgelegd, leest "lekker" weg. Alhoewel jij dat anders zou kunnen zien natuurlijk :-)
      Succesvol testmanagement
      Voor de testcoördinator en testmanager onder ons, veel tips en goede manieren om het testen in de hand te houden in de nogal vaak gestreste ontwikkeltrajecten. Iets simpels als "houdt een testlog bij" is goud waard!
      Surviving The Top-Ten Challenges Of Software Testing
      De titel zegt het al, inclusief stappenplan en zelf-reflectie.
      Testen 2.0
      Agile testen, niet alleen voor agile testers, haal hier veel ideeen uit voor andere testmethodieken of combinaties van ontwikkelmethodieken en hoe hier mee om te gaan.
      Testen van ketens met TMap NEXT
      Ketentesten, één van de belangrijkste speerpunten voor de toekomst in de testwereld.
      TestFrame
      Gebruik je testframe? HET boek Testframe, wordt nog steeds veel gevraagd in vacatures, logisch, want het is DE manier om handmatig testen te vertalen naar automatisch testen. Niet voor de beginner (is mijn mening).
      TestGoal
      Zeer goed boek, helder geschreven en begint met een aantal testprincipes. Altijd goed om vanuit principes te werken. Duidelijk uitleg van product risico analyses en exploratory testing.
      The Art of Software Testing
      Het eerste boek over testen, meer dan 40 jaar geleden uitgegeven en nog steeds actueel!
      TMap Next
      HET boek over gestructureerd testen. Als je deze niet in je boekenkast hebt, gelijk aanschaffen.
      TMap Next BDTM
      TMap next, maar dan voor projectleiders en managers om inzicht te krijgen in het TMap Next testproces. Ook voor testers die TMap Next aan het bestuderen zijn, legt sommige onderdelen uit TMap Next wat beter uit dan het originele boek.
      Een flink aantal testboek recencies vind je ook hier.

      Haal je informatie en verspreid het goede nieuws! Klinkt bijna religieus, maar dat was niet de bedoeling, zie het maar als een "vak idioot" opmerking.

      Friday, 10 September 2010

      Seven FREE magazines about testing!

      Keep up to date with the latest news from the test world!The world of software testing is growing and with that we need also magazines with the latest news about software testing. And it is great to find a lot of good stories about testing in FREE magazines. Because I could not find a list of all free test magazines I made this blog with the magazines I've read in recent years. 

      Here are the links to the various *free* magazines:

      Added after publishing this blog
       I hope you enjoy the reading! Do you have more tips for this page? Please comment on this blog or send me an email.

      Zeven gratis vakbladen over testen

      Click here for this weblog in English (because these are mostly English magazines)

      Blijf op de hoogte van het laatste nieuws in de testwereld!
      De wereld van het software testen is behoorlijk aan het groeien en daar horen ook vakbladen bij. En wat is mooier om deze vakbladen met vaak goede artikelen gratis te krijgen? Omdat ik niet zo snel een overzicht kon vinden van alle gratis testbladen heb ik deze blog gemaakt van de bladen die ik de afgelopen jaren heb gelezen en nog steeds volg.

      Hierbij de links naar de diverse *gratis* vakbladen over testen op een rijtje:
      Toegevoegd na het publiceren van deze blog:
      Als je op de hoogte gehouden wilt worden van nieuwe uitgaves van deze bladen kan je je inschrijven op de websites. Ik houdt je ook op de hoogte als je dat wilt. Dit via mijn website, twitter account, of je kan je inschrijven op mijn nieuwsbrief.

      Ik wens je veel leesplezier!

      Heb je nog meer tips voor deze pagina? Geef dan commentaar op deze log of stuur mij een mail.