Monday, 13 December 2010

Nederland koploper op het gebied van testevenementen in 2010!

Ik houdt al weer bijna twee jaar een lijst bij van testevenementen in Europa. Dit is begonnen als hobby. (Tja, hoe suf kan een hobby zijn?)

Ondertussen verstuur ik reminders van de evenementen via Twitter en mijn nieuwsbrief. Misschien dat iemand hier nog wat aan gehad heeft de afgelopen jaren.

En omdat het het einde van het jaar is hierbij een bijdrage aan alle lijstjes die weer gaan verschijnen. Hoeveel testevenementen zijn er in welke landen gegeven. Het zijn er in ieder geval aardig wat die op mijn lijst verschenen zijn - 112 wel liefst.

De koploper is Nederland.
Dit is misschien niet zo vreemd, gezien ik in Nederland woon en het lijstje bijhoudt. De details van andere landen zou mij wel eens kunnen ontgaan, zeker omdat ik bijvoorbeeld maar net aan drie talen spreek.

Maar anderzijds is de testevenementen lijst op mijn site de meest complete lijst van Europese testevenementen op het internet in zoverre ik dat beoordelen. Dus met wat trots mag er best gezegd worden dat we koploper zijn in dit kleine landje. Gefeliciteerd!!

Land Aantal
Nederland 43
Engeland 20
België 13
Duitsland 13
Denemarken 4
Noorwegen 3
Frankrijk 2
Ierland 2
Oostenrijk 2
Spanje 2
Zweden 2
Italië 1
Kroatië 1
Malta 1
Portugal 1
Tsjechië 1
Zwitserland 1
Totaal 112

Mocht je nog tips hebben voor op de testevenementen lijst, of opmerkingen, laat het me weten!

Friday, 26 November 2010

Wat te doen met wollige beschrijvingen in ontwerpen?

Tester leest in ontwerp documentatie:
Binnen de organisatie is er een grote groep van medewerkers die al langere tijd betrokken zijn en altijd hun best gedaan hebben om hun werk tot het uiterste uit te voeren en 100% inzet te tonen. Voor deze collega's zijn diverse voorzieningen opgenomen in het arbeidsvoorwaardenpakket en een belangrijk deel is, zoals besloten door de directie in 2005, ook terug te vinden in art. 123 van het OR besluit van 2006, versie 3.98. Een extra vakantiedag is dan ook opgenomen en geldt dan ook voor medewerkers die ouders zijn dan 40 jaar. Het besluit is eveneens van toepassing op parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. De discussie over medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband hebben is ook gevoerd in het jaar 2006, maar later opgenomen in een nieuw akkoord van de OR met de directie. Dit besluit heeft geresulteerd in het opnemen van een extra vakantiedag voor deze medewerkers en de directie heeft hierbij alle goedkeuringen verwerkt in een nieuwe rapportage die uitgekomen is in 2007, OR besluit versie 4.01. Het nalezen van deze documentatie helpt erbij om deze gegevens ook te kunnen verwerken in de personeelsadministratie en wordt dan ook verwerkt in een automatische berekening.

Euh? Het volgende beeld verschijnt in mijn gedachten:

Wollige taal in ontwerp...

Als tester kom je wel eens software ontwerpen tegen die wel erg "wollig" beschreven zijn. In onze testcursussen leer je om bijvoorbeeld een beslissingstabel of een andere testtechniek te gebruiken om je testgevallen op te stellen aan de hand van een tekst die al zo duidelijk is dat een beginnende tester hier redelijk gemakkelijk mee om kan gaan. Het doel in zo’n cursus is dan ook om een testtechniek te leren. In de praktijk kom je vervolgens een tekst als bovenstaand tegen.

Wat te doen? Een tester met veel jaren ervaring met testtechnieken zou al snel de essentie eruit kunnen filteren en ook al een testtechniek kunnen toepassen om dit stuk tekst te kunnen omzetten naar testgevallen via een testtechniek. Maar heb je weinig ervaring met testtechnieken dan kan je nogal verrast worden.

Wat doe je dan?
  •  Jezelf doodstaren voor een uurtje op de tekst en je afvragen waar je in hemelsnaam moet beginnen?
  • De betreffende OR besluiten die genoemd worden opzoeken, printen en klaarleggen om deze te bestuderen.
  • Eerst proberen om dit duidelijk te krijgen bij de ontwerper en te vragen of hij dit anders kan opschrijven?
  • Het jezelf gemakkelijk maken door gewoon een paar testgevallen uit je hoofd te verzinnen. Later zie je wel hoe je dat gaat testen als je eenmaal in de testuitvoer fase begint.
Het eerste punt geeft al een beetje het gevoel van “verloren” zijn, de tweede optie is een goed punt, wordt wel veel leeswerk en leidt misschien wel weer tot de eerste aktie.

De derde optie heeft vaak het probleem dat de ontwerper er al niet meer is, of hier geen tijd voor heeft.

De vierde optie maakt de testuitvoer inefficiënt; je moet al senior tester zijn in het “Exploratory Testing” vakgebied en in je organisatie waar je werkt zullen test (analyse) technieken dan niet verplicht moeten zijn.

Het beste wat je kan doen in deze situatie is het schaap te scheren. Niet beginnen met nog meer leeswerk, eerst dit stuk begrijpen. Maak je eigen MS-Word versie van dit ontwerp (copy paste) en begin alle onzin weg te strepen, te verwijderen.
Binnen de organisatie is er een grote groep van medewerkers die al langere tijd betrokken zijn en altijd hun best gedaan hebben om hun werk tot het uiterste uit te voeren en 100% inzet te tonen. Voor deze collega's zijn diverse voorzieningen opgenomen in het arbeidsvoorwaardenpakket en een belangrijk deel is, zoals besloten door de directie in 2005, ook terug te vinden in art. 123 van het OR besluit van 2006, versie 3.98. Een extra vakantiedag is dan ook opgenomen en geldt dan ook voor medewerkers die ouder zijn dan 40 jaar. Het besluit is eveneens van toepassing op parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. De discussie over medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband hebben is ook gevoerd in het jaar 2006, maar later opgenomen in een nieuw akkoord van de OR met de directie. Dit besluit heeft geresulteerd in het opnemen van een extra vakantiedag voor deze medewerkers en de directie heeft hierbij alle goedkeuringen verwerkt in een nieuwe rapportage die uitgekomen is in 2007, OR besluit versie 4.01. Het nalezen van deze documentatie helpt erbij om deze gegevens ook te kunnen verwerken in de personeelsadministratie en wordt dan ook verwerkt in een automatische berekening.
Dit maakt:

Een extra vakantiedag geldt voor medewerkers die ouder zijn dan 40 jaar. parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband. opnemen van een extra vakantiedag 

En dan kan je effectief een techniek (EVT bijvoorbeeld) gebruiken om dit uit te werken.

Ben je nu bezig met het herschrijven van het ontwerp? Misschien wel, maar hierdoor kan je tenminste wel snel voortgang maken. Ook kom je er op deze manier achter of het ontwerp überhaupt wel testbaar is, dus het is wel zaak om zo snel mogelijk je besluit te nemen of je een ontwerp gaat "uitkleden", van zijn wol ontdoen.
  • Dit lijkt omslachtig, maar helpt je om een goed overzicht te krijgen
  • Je leert hiervan om ontwerpen goed te leren lezen, je verbetert jezelf als tester
  • Veel werk? Meerdere rapportages van een OR lezen is ook veel werk en geeft vaak meer verwarring
  • Je bent op zoek naar condities en keuzes, niet naar leuke verhalen of ellenlange rapportages en notulen.
  • Goede basis om review commentaar te leveren binnen een project op dit soort ontwerpen
  • Verwijder geen hoofdstuk nummeringen, dit heb je nodig voor eventuele verwijzingen vanaf je testgeval

Ik heb zelf dit vaker uit moeten voeren en ook wel eens mijn teststrategie moeten aanpassen van "testgevallen maken aan de hand van..." naar "testen uitvoeren met behulp van Exploratory Testing".

  • Soms blijkt er geen schaap onder te zitten maar alleen wol en dan heb je wel wat terug te koppelen naar je projectteam.
  • Kom je zo'n geval tegen, dan heb je nu er een simpele en praktische tip bij: scheren dat schaap en hopen dat er nog een beestje onder zit.
Ik hoop dat ik hier iemand mee heb kunnen helpen. Heb je dit al eens gebruikt, gebruik je het nu of later in de toekomst? Ik zou het leuk vinden als je dat even laat weten en je ervaring verder deelt. Laat een boodschap achter bij dit blog.

Saturday, 20 November 2010

Testpromotie tip 14: Maak een herkenbaar logo voor je testteam en gebruik deze op al je documenten

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

Een herkenbaar logo maakt je (test)afdeling meer zichtbaar. Zeker als je het logo gebruikt op de voorpagina van al je documenten die je maakt, of op je intranet of andere digitale interface.

Een logo is een tekst, een beeldmerk of een combinatie van tekst en beeldmerk waaraan je een bedrijf of instelling kunt herkennen.

Basis principes en tips
  • Houdt een logo simpel, maar ook niet te saai zijn: alleen dat wat opvalt slaan we op in onze hersenen om te onthouden
  • Een logo kan bestaan uit een plaatje, maar ook uit alleen tekst. Bij tekstlogo’s kan je denken aan het gebruik van ‘de juiste font’
    • Een dik stevig font weerspiegelt kracht en een solide basis.
    • Een frivool font laat juist elegantie en vrouwelijkheid zien
    • Een schuine letter geeft een beweging weer.
  • Als je tekst gebruikt: altijd leesbaar logo maken, als mensen het zien moet men het direct kunnen lezen. Kijk dus uit met zogenaamde “geschreven” fonts
  • Kleur: Ook een beperkt aantal kleuren is belangrijk, maar bedenk dat niet alle documenten in kleur worden geprint: Het logo moet zonder kleur ook effectief zijn
  • Het psychologische aspect van een logo ligt in de kleur en vorm. Elke gekozen kleur en vorm heeft een betekenis. Het is belangrijk de juiste combinatie te kiezen tussen kleur en vorm.
  • Voorbeelden van kleur en de emotionele eigenschappen zoals ze in west Europa gelden. Dit kan in andere delen van de wereld anders worden uitgelegd, bijvoorbeeld is groen hier emotioneel gelijk aan natuur, maar in landen met een jungle betekent het juist de dood.
    • Rood: Sterke emotie, warmte, agressie, maar kan ook in de juiste context met liefde geassocieerd worden
    • Oranje: In Nederland heeft dit een culturele emotie, vrolijk, herfst, vuur, donkerder oranje: Aarden potten.
    • Geel: Klaar, vrolijk, stimulerend, zomer, licht, opvallend (wordt ook vaak voor gevaar logo’s gebruikt omdat het opvalt)
    • Groen: Natuur, comfort, goedgezindheid, contrasteert met rood (liever niet in combinatie gebruiken), combineren met blauw geeft verfrissende gevoelens
    • Blauw: Kalmerend, veiligheid, zekerheid.
    • Lichtblauw: creatief
    • Donkerblauw: intelligentie, frisheid en hygiëne
  • Een logo moet schaalbaar zijn (dus zowel klein als groot goed te zien zijn)
Hoe maak je een logo?
  • Zodra je gebruik gaat maken van een logo wordt het dus de eerste indruk die blijft hangen bij je collega’s. 
  • Dus neem er de tijd voor om een logo te maken en pak het stapsgewijs aan.
  • Teken eerst schetsen op papier, begin desnoods met krabbeltjes op papier om jezelf te stimuleren. Een paar krassen kan al een goed idee geven over een logo.
  • Ga vervolgens dit uitwerken (eerst op papier) en dan op de PC. 
    • Maak verschillende versies die je bekijkt
    • Experimenteer met diverse lettertypes
    • Vraag feedback aan collega’s
  • Test je logo door het aan een college te laten zien en te vragen of hij het logo na een week uit zijn hoofd kan tekenen
Dit waren wat aandachtspunten en wat tips. Op internet vind je veel meer tips, maar ook veel voorbeelden van logo's. Aan de hand van bovenstaande kan je al gelijk herkennen welke goed zijn en welke minder goed. Misschien kan je een logo die je op internet vindt wel gebruiken als basis voor je eigen logo, maar wat ik al zei: Eerst op papier met een pen of potlood brengt de meest originele ideeën.

Sunday, 31 October 2010

Chickenwings, waar komt die naam vandaan?

Heel begrijpelijk krijg ik de vraag best wel vaak: Waar komt de naam Chickenwings vandaan? Gezien de naam niet echt een verwijzing is naar software testen en eerder naar Kentucky Fried Chicken lijkt te verwijzen.
De naam komt van een eerder opgericht bedrijf uit 1999/2000.

In die tijd kon je als consument eindelijk digitaal aan de slag met videobewerking op de PC. En ik had altijd al een film willen maken, dus stelde ik voor om een film te gaan maken. Om de kosten te drukken en deze van mijn inkomen af te kunnen schrijven ben ik toen een bedrijfje gestart. Verder kon je in die tijd nog geen .nl site krijgen als je niet ingeschreven was in de KvK.

De naam was snel verzonnen. In de pauze's aten we namelijk ovens vol met chickenwings en zo was Chickenwings Film Productions geboren. Een naam en een jaar later onze eerste film: Fluorescerend bloed. Best wel een goede film, met een heuze premiére in het Ketelhuis in Amsterdam.

Hierna hebben we nog een tweede film gemaakt 'The last Dutch picture show' en dat was ook de laatste, Chickenwings Film productions viel uit elkaar en we zijn gestopt met het maken van films. Bij het oprichten van mijn free-lance bedrijf stond ik weer voor de keuze om een naam te kiezen. De herkenbaarheid van het woord "Chickenwings" en dat ik daarmee nog alle kanten opkon, zelfs kip verkopen was dan ook de reden om dit te doen.

Nou, als iemand dit nog eens aan mij vraagt kan ik verwijzen naar deze blog, nu is het bekend...

Je vind de film "Fluorescerend bloed" nog steeds op de International Movie Database

Thursday, 21 October 2010

What about testing infrastructure?

I've been in some infrastructural projects the last few years and still wondering how these projects survive and produce products that are of 'good enough' quality. With testing infrastructure I mean: Upgrade of the Operating System for the complete company, new Multifunctional printers, Citrix environments, corporate virus tools and so on.

Testing is not a part of developing infrastructure
Wish I could say testing is really a part of this infrastructure world. But it isn't. There are not many testers around specialized in this area. I did lead a team of 10 testers at a company, those people were all testing infrastructure. The complete team of testers in the company had 35 (or so) infrastructural testers. Well... How many of them really studied the craft of testing, how many knew at least one methodology or testing technique? Maybe five or six? And what are they doing a few years later? Testing software again at another company or getting another job, system engineer, designer, bus driver or something. De motivated by the lack of interest in the infrastructure world for testing.

Methodology for testing infrastructure
One company tried to work out a methodology for testing infrastructure. They came up with their 750 page book about structured testing and made a light version of it. So the structure is there, what about testing? Well, let the technicians test within the boundaries of this methodology. What if they don't want to be in this structural hazard of this methodology? What if they really do not want to test? Because they are technicians, they want to create a system that makes it possible to connect several thousands of computers together, or build a software distribution system that enables them to distribute applications with one press on the button. "Please don't tell us to test!"

Infrastructure is becoming software
But more and more the infrastructure world is realizing costs of solving problems in production go up. Also, infrastructure is becoming more and more complex. Your Windows computer is not on your desk but on a server some miles away. The little box on your desk has also an operating system, but that's only there to pass keyboard strokes and mouse gliding to that server a few miles away. Virtualization of infrastructure (servers, switches, desktops) makes infrastructure look more and more like software products. The combination of hardware and software does not matter anymore.

Realizing the costs of problems in production
While the software world already knows (at least more companies understand) that going to find out there are problems with your system when it is already in production isn't going to work for the long term, in the infrastructure world it is still a hidden cost.

Let the technicians test
I tried starting to explain exploratory testing to the technicians that would be testing the release, because that was part of my strategy, some scripted testing, for the basic checks and then we would test the highest product risks with exploratory testing. And I would explain how to do that...

And then realized something I already knew, but forgot for a while, that good exploratory testing can only be done by testers with some experience in testing.

"Testing? Bug tracking tools?"
And also realize that IT companies that sell you an infrastructure solution even don't know yet what a bug database is.

If the level of testing in the infrastructure world is still on "not even knowing what testing is and not ever heard of bug tracking tools", it will be a hard day’s work to keep up with technology that works 'good enough'.

I need you!
As I see it, we will need a lot of testers in the infrastructure world who are capable of exploring all the attributes, searching for the flaws in infrastructure systems, just as we do with software.

So please technical people that want to learn about testing: don't leave me here alone and join me in the testworld, I don't know if I can hold out much longer here!

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.

      Friday, 13 August 2010

      Testpromotie tip 12: Publiceer in het blad van de organisatie over testen

      Dit stuk hoort bij weblog: "29 Tips om testen te promoten in je organisatie"

      Over het algemeen wordt een artikel serieuzer genomen als het is verschenen in gedrukte vorm in een blad. Als het gedrukt is, wordt er meer waarde aan gehecht. Dus het publiceren van artikelen over testen in het bedrijfsblad is een goede manier om het testbewustzijn te verhogen.

      Ik ga nu geen tips geven hoe je een goed artikel schrijft (misschien later), wel heb ik nog wat tips toegevoegd als je je artikel eenmaal hebt geschreven. Maar ik begin met twee bekende formules uit het vak "communicatie" (NIMA-A en Communicatietheorie II).

      Ik denk dat dit al wel genoeg is om je op weg te helpen, ik pas ze zelf ook toe en tot nu toe met redelijk succes. Voor testers die geen communicatie hebben gestudeerd hierbij de twee formules die bijna klinken als toverspreuken: ABABA en AIDA

      ABABA: Actualiteit, Belangrijkheid, Afwijking, Belangstelling, Autoriteit 
      AIDA: Attention, Interest, Desire en Action

      ABABA
      Als je een artikel wilt schrijven, maar krijg je het gepubliceerd. Niet in elke organisatie zal dat altijd mogelijk zijn. Je kan je kansen verhogen door je artikel echt als nieuws te brengen. De ABABA formule wordt door journalisten gebruikt om te bepalen wat nieuws is.
      • Actualiteit: nieuws is wat net is gebeurd of op het punt staat te gebeuren.
      • Belangrijkheid: iets is nieuws als er voor veel mensen veel op het spel staat (vaak ook in negatieve zin).
      • Afwijking: nieuws is wat ongewoon is.
      • Belangstelling: nieuws is een ontwikkeling of een gebeurtenis waarvan de lezers zelf de gevolgen ondervinden.
      • Autoriteit: nieuws is informatie die van een belangrijke bron afkomstig is.
      Bevat je onderwerp/artikel de bovenstaande zaken? Dan vergroot je je kansen behoorlijk om je artikel gepubliceerd te krijgen.

      AIDA
      Voor de structuur van je artikel en met het doel "promotie van het testvak" zal je na moeten denken over hoe je je "reclameboodschap" gaat brengen. Ook hiervoor is een handige formule. Het AIDA-model is een marketing model, waarbij vier belangrijke stappen zijn verwerkt die in een reclame-uiting aan bod moeten komen.

      Attention (Aandacht)
      Als eerste moet je de aandacht van de lezer te trekken in je artikel. Dit kan door een pakkende kop, of aparte lettertype of kleur bijvoorbeeld. Waarbij je goed oplet waar het artikel in komt. Als het blad veel blauw heeft, kijk dan eens of je in groen kan publiceren. Zoek wel positieve kleuren en lettertypes. Geen onleesbare lettertype op een zwart vlak, dat komt wat deprimerend over (althans, hier in Europa dan).

      Interest (Interesse)
      Tweede gedeelte in je artikel. Probeer de aandacht in het stuk om te buigen tot echte interesse. Hier kan je meer op emoties van de lezer ingaan, of een zeer positieve alinea schrijven over het testvak. Beloof een besparing op de kosten, of snellere tests of bugvrije producten. Kijk uit dat je niet teveel belooft, je wil nog steeds vertrouwen houden gedurende je loopbaan.

      Desire (Verlangen)
      Nu kan je dieper in gaan op het onderwerp en (bijvoorbeeld) de voordelen benoemen van testen ten opzichte van niet testen, of voor- en nadelen van geautomatiseerd testen, model based testen, exploratory testen, et cetera. Men moet dit ook willen!

      Action (Actie)
      In het laatste gedeelte van je artikel kan je proberen vragen op te roepen bij de lezer. Geef inhoudelijke informatie over je onderwerp, maar maak er geen handleiding van. Geef aan dat men je altijd voor vragen kan bereiken op telefoonnummer en email adres. Sta open voor vragen en draag dat uit.

      Artikel af? Nadenken, nalezen, aanpassen en reviewen!
      Vaak schrijven we iets moois en nadat we het verstuurd hebben bedenken we opeens zaken die we vergeten zijn te melden, of je leest later het stuk terug en je ziet wat fouten waar je niet zo blij mee bent... Uit pure ervaring (dus maken van fouten) heb ik nog de volgende tips:
      • Denk na wat je wilt schrijven en schrijf het stuk op
      • Niet gelijk versturen, ga er eerst maar een paar nachten over slapen, denk in de tussentijd na over je tekst
      • Pas het stuk aan, aan je nieuwe inzichten
      • Lees het stuk zelf na. Vaak zie je fouten overigens beter als je het afgedrukt hebt.
      • Maak lange zinnen korter, maak er twee zinnen van.
      • Voeg plaatjes toe die het verhaal ondersteunen.
      • Wat is de doelgroep van het (bedrijfs)blad? Pas het taalgebruik aan aan de doelgroep, leg vak-idioom kort uit.
      • Laat het eerst lezen door een paar collega's, vrienden, hier komen zeker goede tips uit. Ook spelfouten worden op deze manier goed verwijderd.
      Zo, dat zijn mijn ideeën, nog toevoegingen hierop? Dan hoor ik het graag, dan kan ik dit weer hierin verwerken.

      Friday, 6 August 2010

      Testpromotie tip 6: Maak zelf de bevindingendatabase

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

      Nog geen bevindingen database? Zet de bevindingen database zelf op, begin desnoods met een Excel sheet op een centrale lokatie. Een centrale lijst van bevindingen overtuigt heel wat mensen van het nut van één lijst. Vaak zie je dat iedereen wel een lijst van problemen in de software heeft, maar heeft niet iedereen het complete plaatje.

      Voordelen bevindingen database
      Om het bewustzijn te verhogen, geef een presentatie over de voordelen van een bevindingen database (of in ieder geval een centrale lijst van bevindingen)
      • het is een eenvoudige manier om geen gevonden bug meer te laten ontsnappen.
      • iedereen heeft hetzelfde beeld over de bevindingen in een product
      • door een aktiehouder te koppelen aan bevindingen heeft iedereen zijn aktielijst klaar liggen
      • je kan goede lijsten genereren voor bijvoorbeeld readme bestanden en releasenotes bij nieuwe software update
      • analyse tool voor testers én ontwikkelaars: waar worden de meeste problemen gevonden, is dat een kwetsbaar deel van de software?
      Zelf een Excel sheet bouwen
      Zolang je niet de mogelijkheid ziet om een bevindingen tool in het bedrijf te krijgen, of je neemt je eerste stappen als organisatie in bevindingen registratie, zet de bevindingen database dan zelf op
      • Niet wachten hiermee, als je in je werk constant refereert naar bevinding nummer #0002, #0054, et cetera, dan wordt men snel bewust van de centrale bevindingen lijst.
      • Zet een Excel sheet op, of ben je handig met MS-Access?
      • Zorg ervoor dat er periodiek een overleg komt met minimaal een projectleider, bouwer, ontwerper en een tester. Daarin bespreek je de openstaande bevindingen, status, prioriteit en de aktiehouder per bevinding
      Hoe eenvoudig je bevindingen registratie ook is, gebruik altijd de volgende zaken
      • Korte omschrijving: in één duidelijke zin het probleem beschreven
      • Bevinding nr: voor verwijzing naar unieke nummers van de bevindingen
      • Status: Open, in behandeling, op te lossen, te testen, opgelost, gesloten
      • Prioriteit: Hoog, midden laag? Of 1 t/m 5? Probeer een oneven nummer aan te houden voor prioriteiten, dit schijnt psychologisch het best te werken (ik weet niet meer waar ik dat van heb, dus of het echt waarheid is... Wie kan daar iets over zeggen?)
      • Aktiehouder: Wie moet er NU iets mee gaan doen
      • Gevonden datum, opgelost datum
      Speel bevindingenbeheerder
      Wees niet bang om bevindingen beheerder te spelen. Hier wat tips:
      • Als iemand het over een probleem heeft, vraag of hij je een mail kan sturen met uitleg
      • Voeg deze beschrijving toe aan je lijst en mail terug dat het daar-en-daar staat en dat het besproken
      • Ga geen bevindingen samenvoegen, een probleem die je hebt gevonden is één probleem. Als meerdere bevindingen door één oorzaak komen (wat vaak gedacht wordt), wil nog niet zeggen dat het oplossen van deze oorzaak alle gevonden problemen oplost.
      • Standaard motto "als het niet in de bevindingen lijst staat, is het geen bevinding."
      • Spreek mensen aan op het wel of niet oplossen of analyseren van bevindingen. Pas hier wel mee op als men nog niet gewend is om hiervoor aangesproken te worden en spreek mensen pas aan als de bevinding ook in een bevindingen overleg is besproken. 
      • Je kan het controleren op bevindingen in het begin ook bij de projectleider / teamleider beleggen, of een change-manager. Daar waar de autoriteit en vertrouwen ligt.
      • Wees consequent, en blijf het beheer goed volhouden voor een lange tijd. Herinner jezelf dat je elke dag de bevindingenlijst even controleert. Zo win je vertrouwen.
      Verder dan Excel
      Je kan echt ver gaan met een bevindingen registratie tool. Pas op dat je Excel of MS-Access niet helemaal verbouwd totdat het een echte applicatie wordt. Ik bedoel; met macro's enzo. Er zijn veel betere bevindingentools gratis te krijgen. Als je zo ver komt dat iedereen in je team met de bevindingenlijst en het bevindingenproces bekend is, is het misschien eens goed om een échte bevindingentool te gaan promoten en inzetten.

      Bevindingentools zijn over het algemeen gratis te vinden op het internet. Voor de meeste zal je wel wat hulp nodig hebben van wat technische mensen, maar dat helpt ook weer om de acceptatie hiervan te bevorderen. Misschien kan je vragen aan een bouwer of hij een aantal tools eens kan vergelijken en wat hij aanraadt om bij jullie te gaan gebruiken. Gratis tools kosten nog steeds veel geld als het niet in de organisatie past.

      Als je eens rond wilt kijken naar dit soort tools, surf dan even naar http://www.software-pointers.com/en-defecttracking-tools.html Hier vind je veel gratis bevindingentools. Bugzilla bijvoorbeeld, deze gratis tool wordt veel gebruikt.

      Denk er aan, het is niet dat jij er aan toe bent, maar het team / de organisatie. Eerst in de hoofden van de mensen, dan verder uitwerken.

      Succes!



        Wednesday, 28 July 2010

        Testpromotie tip 4: Begrijp de ontwikkelaar

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

        Begrijp de ontwikkelaar goed en weet hoe je met ontwikkelaars omgaat.
        Soft skills zijn voor een tester van levensbelang bij het creëren van test bewustzijn. Het volgende lijstje kan je in ieder geval een beetje helpen bij empathie en hoe je reageert op ontwikkelaars.

        Het lijstje is al 10 jaar oud, maar nog steeds erg sterk, misschien wel belangrijker nu agile opkomt!

        Goede tester: Goede ontwikkelaar:
        Domein kennis Kennis van de binnenkant van het product
        Snel op snelheid komen Grondig inzicht
        Onwetendheid is belangrijk Deskundigheid is belangrijk
        Model is gedrag van gebruikers Model is systeemontwerp
        Focus op wat fout kan gaan Focus op hoe het kan werken
        Focus op de ernst van het probleem Focus op de interesse in een probleem
        Empirisch Theoretisch
        Wat is waargenomen Hoe is het ontworpen
        Sceptisch Gelovige
        Tolereert verveling Automatiseert verveling
        Comfortabel met conflicten Vermijd conflicten
        Rapportage van problemen Begrijpen van problemen

        (uit Pettichord, “Testers and Developers Think Differently: Understanding and Utilizing the Diverse Traits of Key Players on Your Team,” Software Testing & Quality Engineering, Vol. 2, No. 1, 2000, pp. 42-45.)

        Nu nog een paar extra tips om je helemaal op weg te helpen:
        • Overtuig de ontwikkelaar dat de software kwaliteit hun eerste en belangrijkste prioriteit is.
        • Overleggen met de ontwikkelaar over de test strategie en testgevallen is een goede manier om dit proces te starten.
        • Communiceer voortdurend met de ontwikkelaar - bijvoorbeeld, laat ze een controle doen op elke zware bevinding voordat je ze aanmeldt in jullie bevindingen database. Dit geeft de ontwikkelaar de tijd om de correcte oplossing te vinden voordat het in het volgende overleg wordt besproken.

        Toon intelligentie:
        • Ken de functionele en technische specificaties.
        • Maak aantekeningen wanneer u vragen stelt, zodat je niet constant dezelfde vragen blijft stellen.
        • Log je bevinding met reproduceerbare regressie stappen en geef een duidelijke analyse van de gevolgen van de bevinding indien van toepassing.
        Nog meer tips? Zoek dan op 'agile' op internet. Omdat agile een aardige focus heeft op samenwerken kan je, ook als je niet in een agile ontwikkel traject zit, toch heel wat ideeën opdoen!

        Tuesday, 27 July 2010

        Testpromotie tip 2 & 3: Beplak de muren!

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


        Testpromotie tip 2 & 3: Plak artikelen uit IT vakbladen en posters over testen tegen de muren!

        Artikelen uit IT- en vakbladen
        Er zijn vast wel interessante artikelen in IT bladen of op websites die betrekking hebben op de soorten producten die bij jou organisatie  passen. Het gaat er met artikelen vooral om, om de emoties van je collega's te raken met verhalen uit de realiteit.
        • Problemen in vergelijkbare software producten uit je organisatie die in de krant staan of op NU.nl
        • Ik heb vandaag nog een "test-gedicht" uit het gratis magazine "The testing planet" in A3 opgehangen (die vond ik erg goed)
        • Ben je bezig met performance testen? Of ideeën aan het uitwerken, zoek op internet de 5 belangrijkste aandachtsgebieden hierover en plak op!
        • Het internet barst van de realistische verhalen over software problemen, dus als je het goed doseert kan je een tijdje vooruit ;-)
        Posters over testen of van je testmethode tegen de muur
        • Heb je een teststrategie die je om kan zetten in een mooie flow, met leuke plaatjes erbij? Zoek die ene A2 kleurenprinter in je organisatie, maak een paar afdrukken en hang ze op.
        • Zoek je testers? Maak een mooie werving poster en hang op!
        • Plaatjes zeggen meer dan woorden: Een insect op A3 formaat, met het woord ‘bug’ er onder?
        • De vijf beste manieren om performance testen uit te voeren
        • Je bevindingen proces is ook een goede om ergens te vertonen, gezien veel mensen dit niet in hun hoofd hebben (zeker de niet-testers kunnen wel een geheugensteun gebruiken)

        Bekijk natuurlijk wel de situatie in jouw organisatie, hangen er al posters, kan je het bij het ontwikkelteam ophangen, of bij een manager in zijn kantoor. Het is mij bijvoorbeeld wel een keer gelukt om het testproces op A2 formaat aan de muur te krijgen bij mijn teammanager.

        Heeft dit succes? Tja, dat weet je natuurlijk niet van te voren. Een goed voorbeeld van succes is het verhaal van Google : "Testing on the toilet". Hierbij was men er uiteindelijk op uit gekomen om posters over testen op het toilet te hangen. Lees hier meer over op http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html


        Mooie poster maken voor jezelf? Op internet is best wel veel te vinden:
        • Google naar de woorden “making poster tips” en je hebt aardig wat resultaten waar je genoeg tips kan vinden!

        Saturday, 24 July 2010

        Testpromotie tip 1: Altijd presentaties geven over testen

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

        Als men je vraagt om een presentatie te geven over testen: altijd doen!

        Het volgende kan gebeuren:
        • Misschien is er in je organisatie een maandelijkse team bijeenkomst
        • Je wilt een nieuw idee introduceren aan je collega’s
        • Een project ‘kick off’, kan je gelijk de “test kick-off” presentatie geven die je altijd al wilde
        • Je wordt gevraagd om een presentatie voor een vakgroep binnen je organisatie te geven.

        Er zijn vast nog wel meer situaties te ontdekken en voor je zelf te creëren waar je het testen positief kan promoten via een praatje over testen of een presentatie voor een grotere groep mensen.

        Welnu, belangrijkste tip hierbij is: Herhaal jezelf niet teveel in de verschillende presentaties, je moet voorkomen dat men “Nee, niet weer.” gaat denken en helemaal niet meer naar je luistert.

        Verder: Oefen je presentatie van te voren, voor de spiegel voor je vriend of vriendin, voor je kat of je hond. Meet de tijd op die je nodig hebt om rustig een presentatie te geven en ken je presentatie uit je hoofd.

        Dit en nog meer tips over het geven van presentaties vind je op www.managementstart.nl
        En er is net een boek uit over presenteren, deze is mede-geschreven door Derk-Jan de Grood, de auteur van het boek "Testgoal". Ik heb dit boek nog niet gelezen, maar ondertussen wel besteld.

        Hieronder de directe link naar de twee genoemde boeken op Bol.com

        Presenteren? Alles mag!
        Presenteren? Alles mag!
        Derk-Jan de Grood & Jan Iedema


        TestGoal / druk 1
        TestGoal / druk 1
        Grood, D.J. de

        Thursday, 22 July 2010

        Nieuwe Nederlandstalige boeken over testen

        Er zijn weer twee Nederlandstalige boeken uit over testen. Onderstaande de beschrijving van de uitgever.
         

        Batchtesten
        Batch-programma's en het draaien van batches zijn bijna net zo oud als de eerste computers. De meeste bulk voor brieven, betalingen en orders, wordt door batches aangemaakt en verzorgd. Ondanks sexy web-applicaties en andere on-line toepassingen, zijn batches nog steeds onmisbaar voor veel grote organisaties zoals de overheid, financiële instellingen en universiteiten. De belastingdienst bijvoorbeeld verstuurt alle aangifteformulieren batchmatig naar de burgers toe. Batchfouten raken de klant direct, zijn daardoor sterk media-gevoelig en kunnen dus veel imagoschade toebrengen aan een organisatie. Batchtesten is een laatste kans voor het management om de risico's te minimaliseren.

        Dit boek biedt een gestructureerde methode om batches te optimaliseren. De BATCH-methode geeft helder aan hoe je in vijf stappen de batches kunt analyseren en het beheer ervan kunt optimaliseren. Het implementatieproces van de methode in de organisatie wordt verder vergemakkelijkt door de gedetailleerde beschrijving van de verschillende stappen. Daarnaast maken vele praktijkvoorbeelden de complexe materie voor een ieder begrijpelijk.

        Batches zijn belangrijk voor organisaties en zullen dat ook in de toekomst blijven. Desondanks is er weinig literatuur over te vinden. Dit boek is wereldwijd één van de eerste boeken op het gebied van batches en batchtesten. Het sluit aan bij bekende methodieken als TMap, PRINCE2, e.d.

        Over de auteur
        ir. Dew Persad heeft Technische Natuurkunde aan de TU Delft gestudeerd, met als specialisatie supercomputers. Hij zit al meer dan 13 jaar in het testvak en heeft opdrachten uitgevoerd bij onder meer KPN, ING, Delta Lloyd en de overheid. Bij zijn laatste twee opdrachten heeft hij zich gespecialiseerd tot senior business consultant Batches/ Batchtestmanager.

        Als trainer van de cursus 'Kwaliteitsmanagement in de ICT' heeft hij het belang ingezien van het overdragen van kennis aan collega's. Dit alles heeft meegespeeld bij zijn besluit om een boek te schrijven over Batchtesten, mede ook omdat er weinig literatuur over dit onderwerp te vinden is en dat de informatiebehoefte op de werkvloer groot bleek.

        ISTQB Testwoordenboek - Engelse en Nederlandse definities
        Goede communicatie binnen een project heeft een eenduidig begrippenkader als randvoorwaarde. Het testwoordenboek biedt een nagenoeg volledige set van testbegrippen, inclusief definities. Gezien het grote aantal internationale projecten voorziet dit woordenboek in zowel de Engelse als Nederlandse begrippen. De begrippen en definities zijn gebaseerd op de glossary van de International Software Testing Qualification Board (ISTQB). Het ISTQB programma is inmiddels in bijna 70 landen operationeel, waaronder alle belangrijke ICT-landen. Met ruim 150.000 ISTQB gecertificeerde testers is het een de facto standaard binnen het testvakgebied.

        Het ISTQB Testwoordenboek biedt:
        - een volledige lijst van alle testbegrippen
        - definities voor alle testbegrippen
        - alle onderdelen in zowel de Engelse als Nederlande taal
        - een zoektabel voor het snel kunnen zoeken naar Nederlandse begrippen
        - volledige aansluiting bij de ISTQB en internationale testterminologie
        - ter voorbeiding op het ISTQB Foundation en Advanced examen duidelijk geïdentifeerde relevante termen
        - alle begrippen van de ISTQB Expert syllabus 'Improving the testing process'.

        Erik van Veenendaal is internationaal erkend testexpert en oprichter van Improve Quality Services BV. Binnen ISTQB vervulde hij van 2005 tot 2009 de rol van Vice President en momenteel is hij voorzitter van de ISTQB Glossary werkgroep.

        Meile Posthuma is als testadviseur werkzaam bij Logica. Als voorzitter van de Belgium and Netherlands Testing Qualifications Board (BNTQB) is hij betrokken bij verschillende internationale en nationale ISTQB werkgroepen.

        Klik op onderstaande links voor een directe link naar bol.com voor deze boeken
        Batch testen / druk 1
        Batch testen / druk 1
        Persad, D.


        ISTQB Testwoordenboek / druk 1
        ISTQB Testwoordenboek / druk 1
        E. van Veenendaal & Posthuma, M.

        Sunday, 18 July 2010

        29 Tips om testen te promoten in je organisatie

        “De gebruikers kunnen met deze aanpassing in het systeem vanuit hun huis aansluiten op de het netwerk en beheer uitvoeren. Omdat jullie testteam de kennis en ervaring met dit soort systemen heeft willen we graag dat jullie dit testen.“

        Een valide vraag en een goed begin voor een testopdracht. Na een uur praten met de ontwikkelaar kregen we de eerste input over de testopdracht. Duidelijk was in deze situatie dat test weer eens aan het einde van een project gevraagd wordt om mee te kijken. Geen ideale situatie, maar toch, testen was nog niet echt bekend bij het vragende team, dus dat men vraagt om een test is positief.

        Aan het einde van het uur hadden we geen idee van de planning en we vroegen: “Wanneer is de planning dat dit in productie gaat? “. Volgens de ontwikkelaar waren ze al in productie en dat werkte prima.

        “Waarom zal je het nog testen als het allemaal al klaar is en naar tevredenheid werkt?”. De ontwikkelaar kon daar geen wantwoord op geven, we zijn naar zijn projectmanager gegaan en hij legde uit dat hij een formeel rapport wilde waarin stond wat de resultaten van test waren, zodat hij hiermee een overdracht naar de lijn kon uitvoeren.

        Ik heb toen aangegeven dat testen geen vrije tijdsbesteding was en als het prima werkt in productie dat hij dat dan kan communiceren.

        Niet de beste manier om testen te promoten, nee zeggen op een opdracht. Maar testen als administratieve afhandeling van een project gaat mij toch te ver.

        Dit leverde mij een idee op om een artikel te schrijven over het promoten van testen. Ondanks dat we met zijn allen vinden dat testen een echt vakgebied is, is de inhoudelijke kennis over testen bij andere disciplines vaak nog onbekend.

        Wat is testen precies, wanneer begin je, hoe doorloop je een testtraject, waar let een tester op? Wel handig om te weten als je een testteam vraagt om te gaan testen. Het is tijd om het aan iedereen uit te gaan leggen en wat meer begrip te krijgen.

        Hier mijn tips om testen te promoten. In latere weblogs zal ik een aantal onderdelen verder beschrijven.



        1. Als men je vraagt om een presentatie te geven over testen: altijd doen!
        2. Plaats posters over testen of van je testmethode tegen de muur
        3. Plak artikelen uit IT vakbladen over testen tegen een muur (de testmuur?)
        4. Begrijp de ontwikkelaar goed en weet hoe je met ontwikkelaars omgaat.
        5. Nog nooit getest bij een afdeling? Begin gewoon met testen en communiceer bevindingen
        6. Nog geen bevindingen database? Zet de bevindingen database zelf op, begin desnoods met een Excel sheet. Een centrale lijst van bevindingen overtuigt heel wat mensen
        7. Blijf in je gesprekken en communicatie altijd positief over testen. Straal passie voor het testvak uit.
        8. Overtuigen kosten en baten van vroeg starten met testen en vroeg bevindingen vinden
        9. Spreek goed de exit criteria van een test door met alle belanghebbenden
        10. Testplannen stap-voor-stap doorlopen met projectmanagers en teamleiders
        11. Houdt product risico analyse sessie
        12. Publiceer in het blad van de organisatie over testen
        13. Zorg dat je een Jip-en-Janneke uitleg over testen klaar hebt liggen, wat je altijd kan vertellen. (elevator pitch)
        14. Maak een herkenbaar logo voor je testteam en gebruik deze op al je documenten
        15. Zet een ontwikkelaar in het testteam
        16. Zet een tester bij het ontwikkelteam
        17. Niet onafhankelijk testteam maar afhankelijke teams (alleen samenwerken zorgt voor een goed product)
        18. Voor managers: leg de focus op het proces niet het product, er moet iemand op het proces letten, ook het testproces.
        19. Voor managers: Elke stap in het proces zou een stuk test moeten bevatten, niet alleen op het einde
        20. Zorg voor management commitment. Dit is nodg om het testen zichtbaar te maken
        21. Als je communiceert, herhaal niet constant dezelfde boodschap. Elke herhaling maakt je minder geloofwaardig en mensen gaan dan niet meer luisteren ("heb je hem weer")
        22. Speel in op de gevoelens van anderen bij het overbrengen van de boodschap, wat raakt je gesprekspartner, lezer?
        23. Verpreid artikelen over test, vakbladen, maak kopieën, leg een bibliotheek aan.
        24. Ga naar testevenementen, neem je collega’s mee
        25. Als software fout loopt in productie, analyseer en bespreek met management hoe die fouten gevonden hadden kunnen worden in het ontwikkelproces
        26. Zorg dat managers op diverse niveaus verstand hebben van testen en de risicos van niet testen tot aan het testproces en de dagelijkse specifieke problemen die spelen op de werkvloer.
        27. In dit proces: Geduld, geduld, geduld
        28. Vertel wat je gedaan hebt, maak reclame voor je eigen werk. Hoeveel bevindingen heb je op tijd gevonden? Hoe snel is de laatste testronde gegaan? Etc.
        29. Maak een stappenplan hoe tot testbewustzijn te komen in je organisatie.

        Friday, 16 July 2010

        Het gehele stuk "Linkedin discussie: Hoe kan je best geld besparen op testen?"

        Het gehele stuk "Linkedin discussie: Hoe kan je best geld besparen op testen?" is gepubliceerd in de Testnet Nieuws van deze maand! Je hoeft dus niet meer te wachten op het complete stuk op dit weblog. Ga naar http://www.testnet.org om de laatste TNN (14-2) deze te downloaden. De posting over dit onderwerp is ondertussen verwijderd.

        Saturday, 3 July 2010

        Nog even herhalen: Testprincipes

        Wat is een principe? Even op internet zoeken geeft zo’n beetje de volgende betekenissen: manier waarop iets werkt, grondoorzaak, werkend beginsel, grondbeginsel, grondstelling, idee, stelregel.

        Wij testers hebben in ons vakgebied principes die als basis gelden voor het testvakgebied. Niet iedereen leest alle testliteratuur, maar ik hoop toch wel dat ze bij de professionele tester toch wel bekend zijn. Want je hoeft geen specifieke testmethodiek te volgen, als je in je uitwerking van je testaanpak maar rekening houdt met deze grondbeginselen.

        Zo niet, hierbij even een aantal op een rijtje, komend uit twee boeken. Een is onderdeel van het ISTQB foundation examen en de ander is het boek “Testgoal”.

        Foundations of software testing, Graham, Veenendaal, Evans, Black, ISBN 978-1-84480-989-9
        • Testen levert een lijst van bugs op, maar geen bugs vinden betekent niet dat de software correct is.
        • Alles testen is onmogelijk
        • Start zo vroeg mogelijk in het traject met testen
        • Bugs vind je vaak bij elkaar in één module / onderdeel / functionaliteit
        • Pesticide paradox – Herhalen van dezelfde tests levert geen nieuwe bevindingen op
        • Testen is context afhankelijk, je test verschillende systemen op verschillende manieren
        • Afwezigheid van bugs wil nog niet zeggen dat de gebruiker tevreden is met de software

        Testgoal, Derk-Jan de Grood, ISBN 978-90-12-11883-5
        Testgoal gaat meer in op de tester zelf, hoe gedraag je jezelf in het testvak, wat zijn de grondstellingen waar je als tester rekening mee houdt.

        De resultaatgedreven tester hanteert de volgende principes
        • Focus op resultaat
        • Bouw aan vertrouwen
        • Neem verantwoordelijkheid
        • Beheers het testvak
        • Sla bruggen
        • Test gefaseerd
        • Faciliteer de gehele IT lifecycle
        • Geef overzicht en inzicht
        • Zorg voor herbruikbaarheid
        • Bedenk: testen is leuk
        Als professionele tester zouden deze principes in je bloed moeten zitten, bij elke testervaring , communicatie, planning, strategiebepalingen mee genomen moeten worden. Je moet ze dromen, eten, inademen en weer uitdragen.

        Zo, dat was even de herhaling van wat testbasis gedachten die ik toch weer even wilde publiceren, lekker om weer in het kort door te lezen voor sommige van ons, voor anderen een eerste ontmoeting? En nu de vraag: hoe professioneel gedraag jij je, zijn er principes waar je jezelf kan verbeteren, waar je vanaf nu wat meer rekening mee houdt?

        Zijn er nog meer principes die niet in dit lijstje staan, reageer op dit artikel, ik hoor graag aanvullingen en ideeën hierover en dat maakt deze blog alleen maar beter!

        Saturday, 12 June 2010

        Is testen in productie in de toekomst onvermijdelijk?

        The horror! The horror!
        Als een tester te horen krijgt dat het testen in de pilot gaan plaatsvinden, samen met de eindgebruikers in de huidige kantooromgeving… Dan gaan er best wel wat haren overeind staan in de nek, kippenvel op de armen en er komt een aanstormend gevoel van onbehagen over de tester heen. Maar zouden we hier niet gewoon open voor moeten staan en onze eerste primaire reactie moeten onderdrukken?


        De testers aan het woord

        De testvakorganisatie van Nederland, Testnet, heeft 21 juni aanstaande een thema avond “ testen in productie” (http://www.testnet.org/Produktie/Evenementen/ThemaAvond.html). Volgens de beschrijvingen op deze site zullen de presentaties in gaan op het waarom en hoe.


        Ik heb dit jaar een presentatie gezien van Egbert Bouman (Valori), waar hij aangaf dat we daar naar toe moeten gaan, testen in productie. Dit vanuit het perspectief van ketentesten en het beheer van test en productie omgevingen. De heer Bouman gaf tevens dat het vroeger toch anders ging: Elektronica werd gemaakt om te testen door extra testcircuits in elektronica te plaatsen. Een voorbeeld is je CV-ketel. Bij Mainframe systemen zie je dit bijvoorbeeld ook.


        Ketentesten
        Systemen zijn steeds meer aan elkaar gekoppeld en elk stukje software communiceert met een ander stukje software in het zelfde apparaat, in het apparaat onder je bureau, of met een apparaat aan de andere kant van de wereld. Zo zijn informatiestromen grotere “globetrotters” dan de gemiddelde mens.


        Sterker nog, software communiceert met een stukje software onder je bureau, deze geeft de boodschap door aan een ander stukje software in de wereld, die het weer doorgeeft aan een ander stukje software, et cetera. Hoe weten we zeker dat als we informatie deze keten insturen, dat de goede informatie er aan de andere kant ook weer uitkomt?

        Eén of meerdere Pc’s in een afgesloten testomgeving en een black box testtechniek gaan ons daar met deze toenemende complexiteit niet mee helpen.


        Verschillende besturingssystemen, andere protocollen, migratie van data heen en terug. En dan de interpretatie van die data in al die stukjes techniek. En dit weer geïnterpreteerd door uiteindelijk de mens, die in het spel van een menselijke keten ook niet feilloos de boodschap kan overbrengen.

        Links in de rij krijgt men te horen: “Dit is een proef, waarmee we gaan proberen de informatie die je nu krijgt aan de andere kan van de rij te krijgen. De toverspreuk is: Wattus unus daga ”. Deze zin gaat van oor tot mond tot oor en is dit na 10 personen in de keten vervormd tot “Moge de Mataglap met je zijn” bijvoorbeeld. Wij mensen maken deze software en koppelen al die onderdelen aan elkaar. Een interpretatie verschil van een 1 of een 0, crashed een component in de keten en kan zo ook de gehele keten onbruikbaar maken.


        Mijn ervaring in de praktijk

        Ik heb zelf meer dan tien jaar geleden ook software getest in productie, het zogenaamde CLIEP02 bestand waarmee je meerdere overboekingen kon maken (via batchbestand). Dat bestand werd in productie geplaatst met in de records een ‘t’ (voor test) in plaats van een ‘p’ (voor productie). Wel oppassen natuurlijk met dit soort acties. Ik was niet van plan om per ongeluk al het geld van mijn rekening op de rekening van het bedrijf te schrijven.


        Bij een andere opdrachtgever hadden we voor het testen van een nieuw landelijk netwerk een “ extra circuit” ingebouwd, door naast de productie servers en switches testapparatuur te plaatsen. Zelfs de bekabeling tussen de diverse steden was voor testdoeleinden apart gereserveerd. Hierdoor ontstond ook een goede represent
        atieve testomgeving. Dit stond echter niet in de initiële projectplannen en was ad-hoc opgebouwd vanuit test, waardoor het niet helemaal een ideale omgeving was, maar heeft wel de mogelijkheden getoond om een “ testcircuit” op te bouwen. In dit geval dus ook een fysiek testcircuit.

        Hierbij hebben we wel per ongeluk een keer een geheel kantoor weggedrukt met performance testen door een foutje waardoor de testomgeving deel werd van de productie omgeving. We hadden snel de handen van de knoppen toen we het hoorde en de storing was minimaal, mede door de bewaking en snelle terugkoppeling vanuit de servicedesk.


        Maar dat was een klein probleem. Testen in productie kan bijvoorbeeld ook een vliegtuig laten crashen, terwijl je alleen maar bezig was met het testen van zoiets als een administratie systeem.


        De meeste tijd heb ik in mijn leven als tester gespendeerd in lab-omgevingen, waarna het product wordt verplaatst (bij een positief resultaat) naar de productie omgeving. En dan kan er nog heel wat fout gaan door verschillen in de twee omgevingen, bij sommige bedrijven is dit zelfs onvermijdelijk en zijn er standaard procedures om dit op te vangen.


        Valt het allemaal wel mee?

        Het valt allemaal wel mee, je kan goed geïsoleerd testen en voor ketentesten hebben we de testtechniek “programma interface test” . Hmja, voor functionele tests inderdaad.


        Maar performance testen dan? Simuleren van een bericht dat door 10 systemen heen gaat die je niet allemaal in je privé laboratorium hebt? Drivers? Stubs? Simulatie software, dat kan al een heleboel doen.


        En het testen op infrastructurele componenten. Geld om productie na te bouwen in een testomgeving zal er niet zo vaak zijn, als een productieomgeving überhaupt in kaart te brengen is. De complexiteit kan behoorlijk oplopen, zeker bij de grotere organisaties.


        Testen in productie en andere oplossingen

        Één oplossing is een extra circuit bouwen in het systeem voor testuitvoering, software en voor infrastructuur ook de hardware. Het gevoel hierbij is dat het niet de meest efficiënte oplossing is. Eén systeem bouwen kost al een hoop centen, maar om er dan nog een tweede ‘ernaast’ te bouwen. Hoe krijg ik dat in mijn testbudget gewaarborgd?
        Misschien kunnen we beter denken aan andere ontwikkelingen die nu spelen. Dit zijn huidige trends zoals virtualisatie van testomgevingen, testen in de cloud en crowd testing.

        Virtualisatie van de testomgeving is prima, kan een hoop tijd en ellende besparen. Maar kan je ook de rest van de keten virtualiseren en meenemen in je testomgeving? Dat zou een goede optie kunnen zijn, en ik heb al een succesverhaal gelezen dit jaar. Dan blijft de vraag hoe je er achter komt wat je dan moet meenemen in de testomgeving.

        Het probleem blijft bestaan dat je niet precies weet wat er buiten je eigen vertrouwde omgeving gebeurt.
        Testing in de cloud en crowd testing is op dit moment vooral gericht op het testen van web based applicaties, waarbij “de cloud” een soort van virtualisatie is (maar dan op steroïden, was een kreet die ik laatst las).

        Crowd testing(zie als voorbeeld www.utest.com ) is goed om web based applicaties te testen op verschillende computer configuraties. Het wordt helaas beperkt doordat de testers ver weg zitten en er puur via het geschreven woord wordt gecommuniceerd. Hierdoor kan je het alleen maar toepassen op kleinere applicaties.


        Misschien een combinatie van deze drie opties? Waarbij je het systeem bouwt in een virtuele omgeving, in een “cloud” en dubbel uitvoert, een voor het productie werk en een voor testdoeleinden. In dit geval blijf je de onbekende koppelingen met andere systemen behouden. Voor infrastructurele projecten (en overigens ook embedded software) moet je ook nog de afhankelijkheden met de hardware meten waardoor dit niet opgaat voor dit soort testtrajecten.


        De beste representatieve test is in productie
        De beste test is in productie, omdat je dan zeker weet dat wat je test representatief is voor de werkelijke situatie. Als ik het heb over grotere infrastructuur veranderingen is de keuze: beperkte test, waar de testresultaten feitelijk weinig zeggen over de échte situatie, niet testen en laat de risico’s maar aan de projectmanager over of dus toch in productie testen.


        Voor alle testtrajecten geldt zeer waarschijnlijk hetzelfde: in de toekomst (nu al in vele gevallen) gaat de huidige testomgeving niet meer voldoende zijn en zullen we aan de slag moeten met andere oplossingen om de kwaliteit op een goede en representatieve manier te meten. Projectmanagers gaan ons wel vreemd aankijken als we steeds vaker gaan zeggen: “Maar dat kunnen we niet testen.” Voor dit soort uitspraken waren we niet ingehuurd en beperkt de toegevoegde waarde van testen.

        Hoe we dat gaan doen is nog de vraag en moeten we nog maar eens goed over nadenken met zijn allen.