Testautomatisering kan je alleen aan testprofessionals overlaten. Binnen softwaretrajecten staat het testen altijd onder druk. Alle betrokkenen zullen het belang van testen benadrukken aan het begin van het traject, maar zodra de deadline begint te naderen is de test vaak de meest voor de hand liggende kandidaat om tijd te besparen.
Voorstellen voor testautomatisering worden vaak enthousiast ontvangen. Het idee is dat geautomatiseerde testen tijdwinst opleveren omdat ze sneller uitgevoerd kunnen worden. Met een druk op knop wordt de immers de test uitgevoerd en vervolgens worden de resultaten keurig in een rapportage getoond. Daarnaast kan de test uitgevoerd worden zo vaak als je wilt en is de uitvoer foutloos, terwijl testers tijdrovende fouten maken. Dit is allemaal waar, maar er zitten ook een aantal haken en ogen aan testautomatisering.
Het doel van geautomatiseerd testen is om een tijdrovend, zichzelf herhalend proces te automatiseren. Hierbij moet rekening gehouden worden met een groot aantal afhankelijkheden, tijdsdruk en hoge kwaliteitseisen. Dit maakt testautomatisering tot een lastig te beheersen proces. De invoer vraagt om een aanzienlijke initiële investering die vervolgens volledig teniet gedaan kan worden door gebrek aan onderhoud. Als testscripts eenmaal verouderd zijn, zal het een grote inspanning vragen om deze weer relevant te maken. Er moet dus ook voldoende tijd gereserveerd worden voor onderhoud. De gekozen strategie en de gemaakte afspraken met betrekking tot testautomatisering moeten worden vastgelegd in de generieke testafspraken, omdat testautomatisering een traject is dat niet ingezet wordt voor een release, maar voor meerdere releases
Dit alles maakt dat succesvolle invoer van testautomatisering alleen mogelijk is als het wordt gezien als integraal onderdeel van gestructureerd testen en niet als mogelijk middel tot tijdwinst in een project onder druk. Gestructureerd testen is werk voor testers. Testen is een vak, testautomatisering is dat ook.
De kop is een beetje kort door de bocht.
Het maken van testdesigns, testplannen, teststrategie, testcases en dergelijke moet je aan testers overlaten
Automatiseren aan automatiseerders.
Testscripts is een grijs gebied. Ik heb in een omgeving gewerkt waar testers zelf testscripts schreven in Java, welke qua complexiteit soms niet onderdeden voor de code die ze ermee moesten testen. Dat kan niet de bedoeling zijn.
Op dit moment zit ik in een omgeving waar een clubje programmeurs een test-raamwerk heeft gemaakt en bijhoudt. De testers hebben een soort modelleer-taal tot hun beschikking waarmee ze hun testen kunnen beschrijven. De comibinatie van de beschrijving en het raamwerk wordt vervolgens gebruikt om automatisch te testen. Hierdoor kunnen de testers zich veel beter bezig houden met het testen zelf, in plaats van moeilijke dingen in Java te programmeren om te kunnen testen.
Maar, zoals de schrijver opmerkt: dit alles moet gezien worden als integraal onderdeel van het project en organisatie
Ik sluit me aan bij PaVaKa.
het schrijven van testscripts (testdesigns) moet door de tester gedaan worden.
Echter de testautomatisering moet je overlaten aan anderen.
Ik ben 3 jaar werkzaam geweest op het gebeid van geautomisteerd testen. het maken van geautomatiseerde testscripts is in feite puur programmeren. Een tester is echter geen programmeur.
geautomatiseerd testen wordt ook vaak als marketinginstrument gebruikt door bedrijven om zich naar de buitenwereld te kunnen profileren. Iets wat een totaal verkeerde insteek is.
De volgorde is niet voor niets: Eerst een gestructureerd testproces dan testautomatisering. Zoder gestructureerd testproces goef je niet een aan geautomatiseerd testen te beginnen.
Het bepalen van de teststrategie en daarmee de keuze voor testautomatisering moet bij de testverantwoordelijken liggen. Vaak wordt er door andere automatiseringsdisciplines gedacht dat zij beter en sneller kunnen testen dan de testers en dat levert de bekende voorspelbare problemen op. (Matthew Heusser beschijft dit bijzonder kernachtig op zijn blog: http://xndev.blogspot.com/2009/07/brief-unfair-and-wrong-history-of.html)
Ik vraag me af wat Ronald bedoelt met “testverantwoordelijken”
Zijn dat de testmanagers? Of de uitvoerende testers?
Ik heb in de 15 jaar dat ik in de automatisering zit en het testen niet meegemaakt dat andere disciplines denken dat ze beter kunnen testen.
Waar het probleem zit is dat het management testautomtisering enerzijds ziet als middel om tijd en geld te besparen, wat niet waar is.
Anderzijds wordt testautomatisering als marketing en verkoopinstrument gebruikt om naar de buitenwereld goede sier te maken en zogenaamd vooruitstrevend over te komen. Wat er dan uitkomt is minder van belang.
Ik heb het in meerdere organisaties meegemaakt en overal is het mislukt.
Wat mij betreft doet diegene die het het best kan gewoon de klus. Of-ie nou tester, programmeur of fietsenmaker op zijn visitekaartje heeft staan.
Alleen kijken naar rollen is jezelf blind staren. Kijk eens naar competenties, attitude, kennis, ervaring. Vele malen belangrijker dan je rol!
Testautomatisering dient de testdoelen, de enige partij die dus kan aangeven wat de testautomatisering moet doen zijn de testers. Of dat betekend dat je een testmanager een paar programmeurs geeft of dat testers zelf programmeren hangt af van de mensen die je tot je beschikking hebt. Vergeet alleen niet dat het testdoel het belangrijkste is, nu rommelige code (gemaakt door testers) en aan het einde van de dag een testresultaat (en later extra tijd kwijt zijn aan onderhoud) kan dus de voorkeur hebben boven goede strakke (professionele) code waar je nog een week op moet wachten.
Zoals zo vaak in testen, hoeveel tijd en geld mag je besteden en hoe levert dat het meeste op.
@CeEfT, met testverantwoordelijken bedoel ik de personen/rollen die verantwoordelijk zijn voor het testresultaat dus in de eerste instantie de testmanager. Dat is degene die zou moeten bepalen of er behoefte is aan testautomatisering. Ik ben diverse malen tegengekomen dat projectmanagement op basis van adviezen van de developmentafdeling (wij scripten wel even zo’n testje) wordt besluit een deel van de testactiviteiten te automatiseren. Met als achterliggende gedachte dat er tijd bespaard moet worden. En de TA trajecten met deze aanpak zijn inderdaad altijd mislukt.
@ Anko het gaat niet om de uitvoerende persoon maar om de verantwoordelijke rol. Testautomatisering onderdeel zou een uitvloeisel moeten zijn van de teststrategie en is het de verantwoordelijk van de testmanager om die strategie op te stellen. Of het competente testmanager is wordt inderdaad niet bepaald door wat er op zijn visitekaartje staat maar door zijn competenties, attitude, kennis, ervaring.
Verder ben ik het helemaal eens met Richard, wie er verder invulling geeft aan programmeerwerk is afhankelijk van de omstandigheden en ook dat is een afweging die in de teststrategie moet worden gemaakt
“Wat levert testautomatisering op?” Dat is de eerste vraag die je moet stellen. Een kort geleden uitgevoerde kosten-baten – analyse leverde als resultaat dat testautomatisering duurder was dan handmatig testen. Waarom? Precies wat in het artikel staat: onderhoud. Dat kost (heel veel) tijd en geld. Bovendien moet tbv een geautomatiseerde test ihkv testanalyse veel meer worden beschreven dan bij handmatig testen. Zoveel tijd zelfs dat je die, zo is mijn ervaring, met een geautomatiseerde testuitvoering nooit meer terugverdiend. En als de klant dik tevreden is met de kwaliteit obv handmatig uitgevoerde tests, dan is de conclusie snel duidelijk: “Testautomatisering? Bezint eer ge begint.”. En tot slot: wie test eigenlijk de code van de geautomatiseerde test…?