Testers
 
In elk vak heb je ze, maar vaak onder andere benaming. Zo heb ik ooit voor de Rontgen Technische Dienst las-onderzoek gedaan en een collega zij daar ooit over... Ik word betaald om te kijken of een ander een probleem heeft. En dat is het met testers precies zo. Zij testen de software om te kijken of er geen fouten in zitten. Bedenk dat het levens zou kunnen reden als je een paar goede zeikers er heb zitten als het om software voor vliegtuig besturing gaat dan wil je dat er geen "foutjes" in zitten.
 
Een andere uitdaging zou zijn dat de programeur beter zijn best gaat doen zodat er geen fouten meer in de software zitten.
 
Hoe dan ook maker (programeur) en onderzoeker (tester) hebben elkaar nodig om van elkaar te leren.

Niemand maakt nooit fouten. En als je nooit fouten maakt dan heb je altijd nog collega's die fouten maken. Of gekken die met een cirkelzaag de stroomkabels doorsnijden.
 
Testers zijn de mensen die ervoor zorgen dan fouten gevonden en mogelijk zelfs voorkomen kunnen worden. Meestal 'zeikers' en vervelende indringers maar altijd onmisbaar.

Haha...
 
Ik snap wel waarom er zoveel reacties waren...
Dat bevestigd maar weer eens dat testers zeikerd.s zijn ;)

Testen is anderen in staat stellen betere kwaliteit te leveren.
 
Laat mij maar zo'n "zeikerd" zijn ;-)

Zeker een bouwer, die Remco.
Die vinden 2 reacties al veel....:P

Natuurlijk zijn testers belangrijk, maar het moet ook niet overdreven worden. Ik denk zelfs dat een "domme" tester beter is dan een intelligente.
Denk maar eens na over deze stelling en vraag je dan af waarom?
Antwoord is duidelijk, als je intelligent bent ga je er te vaak vanuit dat een ander dat ook is en dat is juist de grote fout!
Mensen die fouten maken doen dit juist vanuit een niet nadenkende zaak.
Vr.groet Bart Goldhoorn.

Ik wil niet zeiken hoor Phuong, maar Remco reageerde op de tekst in het artikel. Daar stond in dat er veel reacties waren.

Gelukkig is het verkrijgen van goede testers geen lot uit de Loterij! Met gerichte training is heel veel te bereiken! De doeltreffendheid van testers zal de komende jaren nadrukkelijker op de agenda geplaatst moeten worden. Na jarenlang van procesoptimalisering komt er een moment dat we moeten investeren in de de effectiviteit van testers zelf! Wijzelf zijn wel overtuigd, nu de 'anderen' nog :-) !

@Bart Goldhoorn
autisten schijnen hiervoor het best geschikt te zijn...
dat jij ze dom vindt, zegt meer over jouw bekrompenheid

Testen is een groot gebied. In voorgaande reacties werd gezegd dat 'domme' testers beter zijn dan intelligente. Als je het hebt over 'monkey-test' is dit waar. Maar testen is meer dan alleen maar op 'verkeerde' knoppen drukken en kijken wat er gebeurd. Bekijk de kwaliteitsattributen maar eens. Je kan bijvoorbeeld testen op functioneel gebied, op het gebied van beveiliging, gebruiksvriendelijkheid, load test, performance test, stress test.
Functioneel testen bestaat bijvoorbeeld ook weer uit verschillende gebieden (testtechnieken): semantisch, syntactisch, equivalentieklassen etc. dit kan dan ook nog een handmatig of geautomatiseerd uitgevoerd worden.
 
Kortom: allerlei verschillende talen, smaakjes, methodes en technieken die "bouwers" hebben kennen wij binnen test ook.

Of autisten hier geschikt voor zijn wil ik buiten de discussie houden, het antwoord van Test Enigineer geeft een juiste opsomming.
Fijn dat er ook mensen zijn die hier over nadenken.

Leuk dat de titel van dit stuk een citaat is van mijn reactie op het vorige artikel, ik voel me vereerd.
Wat betreft de discussie of een "domme" tester beter is dan een slimme tester, omdat intelligente testers de aanname maken dat andere mensen ook intelligent zijn: hier wordt ??n van de eerste principes geschonden die een nieuwe tester meekrijgt tijdens zijn opleiding: 'assumptions are the mother of all f*ckups'. Een intelligente tester maakt juist niet bovenstaande aanname, en is daarom veel beter in staat zijn werk te doen dan een 'domme' tester.
Hiermee wil ik overigens niet zeggen dat testers nooit aannames mogen maken. Sterker nog, zonder aannames kom je nergens: de documentatie is altijd incompleet en op meerdere manieren te interpreteren. Het gaat erom dat de aannames die maakt, ook duidelijk vastlegt en vermeld tijdens het testen.

@Test Enineer
 
Jij bent overduidelijk een geschoolde tester die toch vooral uitgaat van testtechieken.
Een goede tester is volgens mij een tester die niet methoden en technieken centraal stelt maar vooral pragmatisch bezig is en vooral zijn gezonmde verstand gebruikt en niet de jbf mehtode hanteert.
Want juist die "bouwers"gebruiken niet altijd die smaakjes methoden en technieken. je moet het testen zowiezo als onafhankelijke activiteit zien.
Waar ik werk is testen onderdeel van het gele commerciele traject. Wat inhoudt dat lang niet elke gevonden fout opgelost gaat worden. Zeker als je de beperkte capaciteit aan bouwers bij ons in aanmerking neemt.
 
Daar komt bij : Een goede tester is niet iemand die alle testmethoden en technieken kan dromen en kan toepassen. Een goede tester is iemand die de applicatie kent, en die de business kent waar de testen systemen worden gebruikt.
Eerst komt de kennis van de applicatie en dan de testkennis.

@Bedrijfskundige tester
 
Je tekst getuigd niet van veel testkennis!
Een goede tester heeft helemaal geen verstand van het systeem dat hij test nodig! (Dan moet er natuurlijk wel voldoende documentatie aanwezig zijn, maar dat hoort eigenlijk sowieso het geval te zijn.)
Sterker nog, als iemand het systeem kan dromen, slippen juist de minder voor de hand liggen fouten er makkelijk doorheen.
 
Acceptatietesters zijn meestal wel de testers die veel systeemkennis hebben, maar die hebben juist veel minder testkennis nodig en dat is daarmee ook niet de groep waar dit artikel over gaat.
 
De functionele testers kunnen op basis van technieken en methoden een uitspraak doen over de kwaliteit van de geteste software, maar ook over de kwaliteit van de tests.
 
En het maakt voor een tester niet uit welk 'smaakje' de bouwer gebruikt. Volgens mij wilde de schrijver die dat introduceerde alleen maar aangeven dat testen een net zo uitgebreid, spannend en uitdagend imago verdiend als ontwikkelen.
 
Uiteraard is een goede tester pragmatisch, maar dat is een goede bouwer ook, of een goede projectleider. Maar als je niet systematisch en methodisch te werk gaat, stelt je hele testwerk niets voor!
 
Een goede tester vraagt de business waar de verwachtte risico's liggen, zodat hij weet waar hij de nadruk op moet leggen bij het testen..
 

Ik krijg de indruk dat je niet echt weet waar je het over hebt. Sla eens een TMap Next boek open, misschien gaat er een (test)-wereld voor je open!

Even door de twee stukken heen gefietst, staan vol foute opmerkingen, logisch dat er reacties komen.
 
"Het beroep van tester is niet zo interessant, want je maakt niks."
Testafdelingen maken kwaliteit, dat niemand anders dat begrijpt...
 
"Het vergt creativiteit om fouten op te sporen die niet via automatische systemen zijn te vinden"
Sterker nog, het vergt testers om testscripts te maken voor automatische systemen...
 
"Een goede tester moet zowel de wensen van de klant snappen als fouten in de code kunnen opsporen."
Nou, nou, ik ga echt geen fouten in de code opsporen. Dit vind ik nog steeds de kracht van de ontwikkelaars zelf. Ik wil wel helpen, maar de verantwoordelijkheid over de code ligt bij de ontwikkelaar zelf.
 
"En de echt slimme mensen vinden het niet erg om af en toe eens wat te testen maar alleen maar testen is te eenzijdig."
Testplan maken, tesstrategie opzetten, testomgeving configureren, bevindingen analyse, communicatie tussen de verschillende gedragsgestoorden, adviseren over wel of niet releasen, kwaliteitsverbetering voor ?n na het testtraject in de picture zien te krijgen, maken van automatische testscripts, gebruikers ondersteunen bij acceptatie, et cetera... Hoezo alleen maar testen? Lijkt me dat "slimme mensen" whatever ze hier mee bedoelen genoeg uitdagingen hebben. Het is alleen dat die "slimme mensen" het vak niet kennen en denken dat testen puur het uitvoerend werk bevat. Ga toch weg met dit soort uitspraken!
 
"De code waaraan haar softwareontwikkelaars werken, wordt bij iedere aanpassing automatisch getest. De ontwikkelaars schrijven daarvoor zelf unit tests."
Ahum... Weet iemand nog te herrineren waarom "de tester" nu juist een ander persoon moest zijn? Volgens mij gaat dit over een heel klein deel van het testtraject. Wel belangrijk en toe te juichen, maar zie het niet als vervanging voor een systeem test of acceptatie.
 
"Ook de performance tests die inzichtelijk moeten maken of het systeem sinds de vorige aanpassing is verbeterd"
Je bedoelt het hertesten van een systeem. Waar zijn de performance testen op gebaseerd? Op hoe de gebruikers er mee omgaan, of doordat bepaalde technieken worden getest?
 
"De gebruiksvriendelijkheid test Brand samen met de gebruiker en daarvoor neemt hij ook interviews af. "Ik kijk meer vanuit de gebruiker naar het systeem en denk in functionaliteit en oplossingen."
TE LAAT natuurlijk, zoals de testwereld al een tijdje roept, maar goed, dit is inderdaad een goede actie als aanvulling op een testtraject.
 
"Wel hebben ze de verschillende fases - ontwerpen, testen, accepteren en in productie nemen - strak gescheiden door de versies van een ontwerp op verschillende servers te draaien."
Lijkt me een standaard OTAP omgeving. Wat is hier speciaal aan?
 
"Vanwege onze werkwijze hebben we bijna geen testers nodig. ...... - Testers zijn dus niet maanden aan het ontwikkelen voordat de klant iets te zien krijgt, maar breiden het systeem gaandeweg meer uit.
Eh?? Testers zijn niet nodig, maar zijn aan het ontwikkelen? Ja sorry hoor. Als het project straks op zijn einde raakt dan ben je nog fouten van de eerste opleveringen aan het fixen als dat nog kan op deze manier. Ook bij iteratieve ontwikkeling wil je eerst een goede systeemtest.
 
"Testers zijn niet blij met hun slechte imago. Dat blijkt uit de reacties op het artikel 'Gezocht: creatieve ...' dat Computable vorige week publiceerde. Volgens Koop is het daarom belangrijk programmamanagers te laten zien wat er gebeurt als testen achterwege wordt gelaten."
Bereken de kosten van ??n software fout die een gebruiker vindt. Als de gebruiker die vindt kost het bergen geld die je had kunnen besparen als een tester eerder in het traject iets vindt. (het oude liedje...)
Dat is bewijs genoeg dunkt mij.
 
Waar ik me bij deze stukken in de Computable vooral aan stoor, is dat het testen steeds meer naar voren gaat in ontwikkeltrajecten, reviewen van ontwerpen, praten met de gebruiker, het schrijven van use-cases voordat er maar iets in ontwerpen komt. Deze stukken brengen het testen weer terug naar het spelen met software, pure uitvoering. Door te testen wil je de kwaliteit meten, en dat zit in alle fases van een ontwikkeling en is iedereen in een team bij betrokken. Door dit soort berichten te publiceren worden deze ontwikkelingen in de testwereld weer 10 jaar terug gezet!
 
Overigens, de titel van dit stuk klopt ook niet, moet zijn "Goede tester is prijs uit de loterij'
 
Groeten van een profesionele zeikerd.

In dit stuk staat: 'Volgens Koop is het daarom belangrijk programmamanagers te laten zien wat er gebeurt als testen achterwege wordt gelaten.'
 
Ik heb echter in mijn reactie geschreven: 'Aan de programmamanagers door aan te tonen wat de kosten zijn van niet testen.'
 
Moet ik toch even kwijt.

Testen is een noodzaak. Iedere fout die in de testfase naar boven komt is een potentiele besparing op ontwikkelkosten. Testen mag echter niet ontaarden in een doel op zich - want dan worden het "zeikerd*". Een rechtgeaarde programmeur, pardon "ontwikkelaar", beschouwt testers als bondgenoot. Een tester constateert en documenteert. Een gebruiker ondergaat en frustreert.
De keuze lijkt mij duidelijk.

Ik schaar mij achter de laatste spreker.
Testen is beslist geen doel. Het doel is het opleveren van een ICT systeem waarmee een bedrijfsproces kan worden ondersteund. En dat moet op een acceptabel tijdstip, tegen een acceptabele prijs en met een acceptabele kwaliteit. Definitiestudie, Ontwerp, bouw zijn essentieel om dit te bereiken. Test is eigenlijk altijd nodig omdat productkwaliteit (nog) niet voldoende te borgen is in een ICT-ontwikkeltraject.
Architecten, ontwerpers en bouwers die dit beseffen zullen testers zien als bondgenoten die helpen hun producten te verbeteren, en dus zelden als zeikerds. Een tester die zijn (of haar) rol in het geheel begrijpt zal zelden een zeikerd zijn, maar beredeneerd keuzes weten te maken tussen formele oplevercriteria, en pragmatisme, en zal het gat proberen te dichten tussen ICT en business. Inderdaad het lot uit de loterij.

Aanvullend: Goede testers zijn in mijn optiek mensen met het talent om zich razendsnel het bedrijfsproces eigen te maken dat wordt ondersteund door de te testen IT-oplossing, een gedegen kennis van het testvak, en de kunst te beheersen hierover met verschillende partijen te communiceren.
 
Deze zaken zijn essentieel om boven geschetste rol goed te vervullen.
Het eerste om keuzes te kunnen maken over of en wanneer je bepaalde zaken gaat doen. En het 2e om de aktiviteiten die je gaat verrichten op de juiste manier te doen, en het derde spreekt denk ik vanzelf.
Testers met bovenstaande kennis en eigenschappen zijn moeilijk te vinden winnende loten uit de loterij.
 
Sander Koops (Testmanager)

Dit artikel wordt met alle goede bedoelingen geschreven doch door niet adequaat te reageren werkt men eigenlijk mee aan de creatie van een verkeerd beeld. Het vak testen is meer dan "de tester" alleen. M.a.w. het vak "Testen" dient in zijn volledigheid besproken te worden en niet het vak beoordelen, omdat er een artikel verschijnt over een tester. Hoe goed bedoeld dat ook is. Misschien dat deze reactie de Computable triggert om testen als vak te beschrijven en de impact op een ontwikkeltraject of inkooptraject aan te geven.
Uiteraard is een goede tester een lot uit de loterij, maar zonder een goede testmanager is zijn effectiviteit een stuk minder. En een goede testmanager is ook een lot uit de loterij, maar zonder een goede opdrachtgever is zijn effectiviteit een stuk minder.
Dus zie het vak testen niet als een mannetje dat af en toe komt zeuren over problemen die men eigenlijk niet wilt weten. Het feit dat een tester een zeikerd wordt genoemd wilt eigenlijk aangeven dat zijn omgeving (die hem zo bestempelt) niet volwassen genoeg is om effectief met zijn kennis en inzet om te gaan. Een "tester" geeft namelijk waardevolle informatie aan een opdrachtgever, indien de opdrachtgever hem de kans biedt deze op een gestructureerde wijze boven water te krijgen. De skills die nodig zijn om deze waardevolle informatie boven water te krijgen zorgen ervoor dat de mensen die binnen het testvak opereren een lot uit de loterij zijn.

En nu wil ik wel een opmerking plaatsen in het geval dat het vak testen nooit had bestaan. Hoe zou deze informatiemaatschappij hebben uitgezien als al die benodigde programmatuur niet direct op juiste functionaliteit
wordt gecontroleerd. Denk eens aan bancaire software, identificatieprocedures, boardcomputers, en gemeentelijke heffingsystemen.
Niemand en dan ook niemand die dan zegt tegen mij: "Jij bent een zeikerd." Testmethode "TMap" is overigens o.a. ontwikkeld bij de overheid en zo zie je dan we ons best doen om aan de wensen "burger" te voldoen.

Dit artikel resulteerde in 3 findings.
Test report:
 
1. Blocking finding
2. Disturbing finding
3. Documentational finding
 
Advise : Negative
 

:-D

Toch maar goed dat er meerdere mensen Remco heten.

Remco,
 
Jij bent denk ik iemand die totaal geen kennis heeft van IT.

1 bevinding gevonden door een tester kan het neerstorten van een Apollo ruimtetoestel behoeden. En je weet zelf wat zo'n ding kost. In die zin is een goede tester inderdaad een lot uit de loterij... :)
(Misschien dan meer op besparing ipv directe inkomsten)... maar een goede manager weet:
als je maar genoeg kosten bespaart...