Testers zijn niet blij met hun slechte imago. Dat blijkt uit de reacties op het artikel ‘Gezocht: creatieve zeikerds’ dat Computable vorige week publiceerde.
Computable’s artikel van vorige week leverde veel reacties op. Dat het imago van testers wel wat verbetering kan gebruiken, daarover zijn de lezers het eens. ‘Je kunt testers zeikerds noemen, maar je hebt ze nodig.’
"De opmerking dat een tester een zeikerd is, lijkt mij behoorlijk overtrokken", luidt de eerste reactie op het bericht. Een dag later las Jaap Koop het artikel. Ook hij is niet te spreken over de slechte reputatie van testers. Uit zijn reactie blijkt dat hij ook zelf tot die groep behoort. "Dat we een imagoprobleem hebben, onderschrijf ik wel", zegt hij. Toch is er volgens Koop op dat gebied de laatste jaren vooruitgang geboekt. Dat zou komen doordat hogescholen meer aandacht besteden aan het vak dan eerst.
Veel van de lezers die op het artikel reageerden, onderstrepen het belang van goed opgeleide testers. ‘Een goede tester is tegenwoordig een lot uit de loterij’, is een van de reacties. Net als de mening dat het belangrijk is ‘het testvak volwaardig te maken en aandacht te besteden aan het opleiden van testers’. Dat is nu nog niet zo, aldus iemand die schrijft onder de naam ‘Tester’. "Het is iets wat je een tijdje doet als je net bent afgestudeerd en niets anders kunt vinden", schrijft hij.
Onterecht, vindt tester Hans Hallebeek. ‘Je kunt testers ‘zeikerds’ noemen, maar je hebt ze nodig’, schrijft hij op de website van Computable. Volgens Hallebeek is het ontbreken van een goede tester direct zichtbaar. Zo zou geregeld aan aangepaste applicaties te zien zijn dat ze niet goed zijn doordacht.
Volgens Koop is het daarom belangrijk programmamanagers te laten zien wat er gebeurt als testen achterwege wordt gelaten. Reageerder Egbert Bouman lijkt het nuttig ‘te blijven roepen hoe leuk en interessant het testvak is’. De mening van Jaap Koop sluit daarbij aan: ‘Ik denk dat wij alleen zelf ons imago kunnen verbeteren’.
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.