Dat is nog al een stelling voor je eerste column op TestNieuws.nl en toch is het een gedachte die vaak door mijn hoofd gaat. Wat ik bedoel te zeggen, is dat er eigenlijk best veel testers zijn die vaak te veel doen en de dingen die ze doen zijn vaak nog saai ook.
Ons vak bestaat uit veel te veel herhalende werkzaamheden. Denk aan regressietesten of het maken het van testscripts. Waarom voeren we die nog zo vaak handmatig uit? Of beter gezegd, waarom nemen we na twee keer hetzelfde te hebben gedaan niet de beslissing het te automatiseren?
Vorige week sprak ik een tester bij een grote bank in Nederland die enorm veel verschillende test tooltjes gebruikte. Voor alles was er een scriptje, een stub of een tool om de uitkomsten te vergelijken en rapportages te draaien. Niet alleen gebonden aan de grote namen als bijvoorbeeld Quality Center en Rational maar ook allerlei gratis tools. Zo werd er gebruik gemaakt van op z’n minst 6 verschillende Firefox plugins.
Is de genoemde tester lui? Dat ligt er aan hoe je het bekijkt maar in de goede zin van het woord wel. Echter wel met het doel om alles wat repeterend is te vermijden. Het gevolg, veel meer uitdaging in het werk door elke keer opzoek te gaan naar wat kan er eenvoudiger kan. Een wijze les vanuit de praktijk.
Soms moeten we als testers maar eens wat luier zijn. Mogelijk helpt dat om ons werk vele malen aantrekkelijker te maken. De saaie dingen de deur uit, de tools naar binnen en de productiviteit omhoog.
Het is eigenlijk verbazingwekkend hoe weinig effect de crises op onze manier van testen heeft gehad. Natuurlijk zijn er wel veel projecten gesneuveld, maar is aan het einde van de rit de productiviteit nou echt omhoog gegaan? Zijn er ontwikkelingen gaande die zorgen voor een hogere productiviteit? Ga eens in de leer bij ontwikkelaars. Er zijn er die daadwerkelijk alles automatiseren, zelfs als het simpelweg meer tijd kost om het handmatig te doen.
Terugkomend op mijn allereerste stelling: ‘waren alle testers maar lui’, wil ik er toch iets anders van maken. Hadden alle testers maar wat eigenschappen van luie ontwikkelaars om zo mogelijkheden te spotten die het testen effectiever maken.
Het is allemaal niet zo moeilijk, ik zal je wat op gang helpen. Daarom hier in ieder geval een mooie bundeling van plugins voor Firefox, netjes op een rij. Plugins die te gebruiken zijn voor het testen van software. Heb je er meer laat het me weten dan voeg ik ze toe.
Hoe lui ben jij?
Note 1: als ik het heb over testers, bedoel ik niet een specifieke rol, maar alle verschillende rollen. Ik schaar mezelf ook onder de testers die veel meer moeten automatiseren.
Note 2: Welke ontwikkelingen zie jij die het testen drastisch hebben veranderd gedurende de crisis?
————————————————–
Andréas Prins is testconsultant, lid van het R&D team bij Software Control Sogeti en houdt een blog bij op TestingTheFuture.net
Andréas,
Ik ben erg lui! Althans in de zin die jij bedoeld! Testautomatisering werkt, mits op een juiste manier gebruikt. Testers zouden het zich inderdaad veel makkelijker moeten maken door tools te gebruiken. Ik ben van mening dat iedere serieuze tester zich zou moeten bekwamen in het schrijven van scripts/macros/etc. Testbestanden editen in notepad is voor 1 keer handig, maar bij de 2e of 3e keer moet je echt gaan nadenken of je niet een excel-marco of een tooltje zou kunnen gebruiken om dit sneller te doen. En kan je het niet zelf, vraag de developer in de buurt om een tooltje in elkaar te knutselen. Dat doen ze graag!
Dus ik ben het eens met je stelling “Hadden alle testers maar wat eigenschappen van luie ontwikkelaars om zo mogelijkheden te spotten die het testen effectiever maken”!!
Welke ontwikkelingen ik zie die het testen drastisch hebben veranderd gedurende de crisis? Geen enkele geloof ik. Best jammer eigenlijk!
Ik ken vreselijk veel luie testers! En ook testers die graag wat meer lui zouden willen zijn….
Daar bedoel ik mee dat niet iedereen het (technisch) inzicht heeft of wil ontwikkelen om repeterende zaken te automatiseren.
In mijn testteam probeer ik dan ook altijd 1 of meerdere kanjers van testautomatiseerders op te nemen. In veel gevallen doen ze niet onder voor een programmeur maar hebben ze net even iets meer affiniteit met testen dan een gemiddelde programmeur.
Het zorgt er ook voor dat het testteam veel minder afhankelijk wordt van het bouwteam.
Aan het einde van de dag zorgen deze kanjers ervoor dat het hele team lui kan zijn!
Het gaat m.i. dan ook om de ideale teamsamenstelling.
Is die moeilijk te realiseren doordat teams te klein zijn? Zorg dan voor een groep testers die kunnen automatiseren en op meerdere projecten ingezet kunnen worden.
Bjorn van den Brink
Leuk en inspirerend artikel! Ik kijk uit naar je volgende stellingen, artikelen, blogs.
@Huib,
daar stel je nog al wat “Ik ben van mening dat iedere serieuze tester zich zou moeten bekwamen in het schrijven van scripts/macros/etc. ”
Ik deel die mening volledig maar hoeveel testers doen dit? Overigens zijn tooltjes als Ultraedit daar ook al geschikt voor.
Het werken met modellen zie ik wel als grote verandering van vorig jaar waarvan we verwachten dat het komend jaar echt enorm zal gaan groeien.
En ja ik weet het, dat klinkt al jaren veel belovend maar ik kan wel een paar concrete voorbeelden geven. Model Driven Quality Improvement op youtube kun je een uitleg vinden
@Andreas: Grotendeels wel mee eens, maar wel altijd in ogenschouw houden dat het automatiseren niet een doel op zich is, een gestructureerd testproces (in welke vorm dan ook) blijft het belangrijkst, daarna automatiseren als dit de beste oplossing is. En daarbij nog kiezen voor het juiste tool is voor velen een uitdaging… ;-) Niet als het aan de Sales ligt, zie mijn blog: http://goo.gl/vomS
Gr, Marcel
@Bjorn,
Je zou dan in kleine teams eigenlijk iemand willen hebben die breder inzetbaar is. Hem vanuit de lijn inzetten en zorgen dat hij elke keer allemaal kleine en grote zaken automatiseerd… Vind ik wel een goed idee, vaak gaat dat wel met proces verbetering maar mogelijk is hiervoor ook de business case snel rond.
@Marcel, automatiseren is absoluut geen doel op zich, daar ben ik het volledig mee eens, maar wat is jou menining? Nu wordt er toch wel heel weinig geautomatiseerd? Ja het komt wel eens voor maar dat teams er zich bewust van zijn, misschien komt het wel door wat @Huib zegt dat sommige testers niet voldoende skills hebben op dit vlak… Ik zal je blog eens lees
@M thanks
Test automatisering kan een hoop tijdswinst en kwaliteit opleveren (herhaalbaarheid van testen gaan enorm omhoog), maar let op dat het op een juist manier gebeurd. Om echt voordeel te hebben van test automatisering, moeten een aantal punten in acht genomen worden:
de geautomatiseerde testen moeten onderhoudbaar zijn. Wijzigingen in het systeem onder test betekenen bijna altijd wijzigingen in de test scripts. De moeite die het kost om test scripts aan te passen moet opwegen tegen de voordelen van het uitvoeren van geautomatiseerde testen. Collega’s moeten een geautomatiseerde test makkelijk over kunnen nemen zonder dagen ingewerkt te worden
de houdbaarheid van de geautomatiseerde testen moet lang genoeg zijn. Als er veel tijd nodig is voor een test set die na bijvoorbeeld twee runs niet meer werkt door een nieuwe release, is het het overwegen waard handmatig te testen
alleen die usecases die vaak herhaald moeten/kunnen worden zijn het waar te automatiseren. Een usecase als “het opvoeren van een nieuw land in een CRM systeem” zal typisch niet keer op keer uitgevoerd worden
Kort samengevat: er zijn veel voordelen van test automatisering, maar er moet niet geautomatiseerd worden om het automatiseren.
A fool with a tool is still a fool. Testautomatisatie kan in bepaalde zaken een handig hulpmiddel zijn, maar je moet wel weten waarvoor het dient en hoe je het moet gebruiken.
Regressietesten zijn een dankbaar voorwerp voor automatisatie, maar het heeft weinig zin om de hele boel te automatiseren als je steeds dezelfde scripts gaat runnen, kom je vroeg of laat het zogenaamde pesticide paradox tegen. Hetzelfde geldt eigenlijk voor alle andere tools. Je kan een test design tool als Classification Tree Editor gebruiken om test cases te creëren, maar dan schakel je meteen ook alle domeinkennis uit bij het vervaardigen van testgevallen.
Dat neemt natuurlijk niet weg dat test tools een erg waardevol hulpmiddel kunnen zijn bij het uitvoeren van testen. Vooral op het terrein van het zoeken en creëren van test data is er volgens mij nog veel progressie mogelijk.
@martijn,
Die mening deel ik volledig, het doen om het doen is onzin. Dank voor je aanvulling aangaande de aanpak, ik zeg altijd maar pak het automatiseren van testen aan alsof het een project is met alles wat daarbij hoort. Denk aan overdracht, onderhoudbaarheid en dergelijke zaken. Maar wat vind jij? Mag het wel eens wat meer in Nederland?
@Gert, kun je voorbeelden noemen buiten test data selectieom waar we het ook meer kunnen gebruiken?