De rol van testers bij het bouwen van software is sterk aan het veranderen. Met die boodschap trok ict-dienstverlener en testbedrijf Sogeti zevenhonderd Nederlandse testers naar 't Spant in Bussum voor de jaarlijkse TMap-dag met als thema ‘Testen is dood, leve de tester’. In de zijlijn van het evenement gaf divisiedirecteur Marco van den Brink van Sogeti antwoord op acht vragen van Computable over het testvak. Hij geeft leiding aan de zeshonderd testers van de grootste divisie binnen Sogeti.
Welke trends zie je op dit moment op het terrein van testing?
Softwaretesten wordt een integraal onderdeel van het ontwikkelproces van applicaties. Waar voorheen het testen een proces was dat separaat van het ontwikkelproces liep, wordt de functionaliteit nu al vanaf de start van de applicatie-ontwikkeling getest. Verder is de rol van volledig geautomatiseerd testen een belangrijke trend. De ontwikkeling van nieuwe tools zorgt ervoor, dat steeds minder handen nodig zijn voor het testen van applicaties. Bovendien wordt de periode van testen aanzienlijk korter. En kan met deze tools meer functionaliteit worden getest.
Wat betekenen deze ontwikkelingen voor testers?
De nieuwe generatie testers verschuift van de laatste man-positie naar verdedigende middenvelder. Of in sommige gevallen zelfs naar de rol van spelverdeler in het speelveld van applicatie-ontwikkeling. Deze veranderende rol van de tester vraagt om aanvullende competenties op het vlak van samenwerking en kennisverbreding en – verdieping. In zowel het algemene ict-vak als testing expertise. Daarnaast vragen steeds meer organisaties om professionals die ervaring hebben in een agile omgeving.
Is de toekomst aan Model Based Testen, of zijn er alternatieven?
Model Based Testen is een belangrijke ontwikkeling die niet meer weg te denken is in een testomgeving. Ontwikkeling van nieuwe applicaties gaat in een rap tempo in een wereld waarin verandering de enige constante is. Tegelijkertijd is er niet meer geld beschikbaar. Dus meer met minder betekent dat Model Based Testen een absolute must is.
Wat voegen die alternatieven toe?
Alternatieven zijn nauwelijks aan de orde. De gebruiker zal nog wel steeds een acceptatietest moeten doen na Model Based Testen. Dus vaststellen dat hij of zij de applicatie heeft gekregen die volledig voldoet aan zijn of haar behoefte. Deze acceptatietest wordt niet ondervangen met Model Based Testen. Dit proces zal net als de ketentest blijven bestaan.
Maakt scrum (en agile in brede zin) testen overbodig?
Met de inzet van scrum wordt testen niet overbodig. Testen krijgt een andere rol in het proces van applicatie-ontwikkeling. Ontwikkelaars en testers trekken samen op. In een scrumteam zijn alle teamleden verantwoordelijk voor het opleveren van een kwalitatief goed product. In zo’n team kan een teamlid met de testrol heel goed als kwaliteitskatalysator werken. Dus naast door zelf te toetsen en testen, ook de andere teamleden ondersteunen bij het uitvoeren van toetsen en het maken en uitvoeren van tests.
De kosten van testen lopen op, blijkt uit het WQR-onderzoek. Waardoor?
Onze samenleving doet steeds meer beroep op ict. De afhankelijkheid en complexiteit van applicaties, te ontsluiten via verschillende (mobiele) platformen nemen daarmee enorm toe. Veranderingen volgen elkaar in een rap tempo op. Dit alles vraagt om applicaties die tegelijkertijd snel en zorgvuldig getest moeten worden. De impact van slecht functionerende of onveilige software is immers groot. Zowel in bedrijfsresultaat als imagoschade. Tegelijkertijd is aangetoond dat bij effectief testen veel geld bespaard wordt in het herstellen van fouten in software die al in productie is.
Zijn er slimme manieren om te besparen op testen?
Met de inzet van onze PointZero aanpak kan tot 30 procent kosten worden bespaard op testen. Deze methode gaat uit van het principe dat testen al vanaf het begin deel uitmaakt van het applicatie-ontwikkelingstraject. Sogeti was de eerste ict-dienstverlener die deze aanpak heeft ontwikkeld. Ook marktanalisten hebben inmiddels bevestigd dat dit de meest effectieve manier van testen is, samen met slimme inzet van goede testing tools.
Wat betekenen deze ontwikkelingen voor Sogeti? Gaat Sogeti ook dood?
De huidige ontwikkelingen betekenen nieuwe kansen voor Sogeti. Testen is belangrijker dan ooit. Zo blijkt uit verschillende onderzoeken. Organisaties stellen wel andere eisen aan de rol van Sogeti als marktleider op het gebied van softwaretesten in bijvoorbeeld een agile-omgeving. We zullen blijven investeren in de kennis en kunde van onze medewerkers. Daar profiteren onze klanten van.
Testen is pas dood als de IT het voor elkaar krijgt om “test by incident” te realiseren.
Op dat moment is de tester een kwaliteitsregisseur.
“Test by incident” betekent zoveel als: pas als er fouten optreden in productie zal er weer even getest worden om lek te dichten en daarna weer terug naar business as usual.
Maar tot die tijd voorzie ik in integratietesten en de ontbinding van alle legacy nog een hoop testwerk.
Ee snelle oplossing zou kunnen zijn dat er nieuwe bedrijven komen, die het wel voor elkaar hebben, veel goedkoper kunnen werken en de oude bedrijven failliet laten gaan. Dat idee doortrekkend zouden bestaande overheidsbedrijven allemaal vervangen moeten worden. Kwestie van een paar wetten afschaffen en nieuwe maken. Dat klinkt allemaal wel erg onwaarschijnlijk, maar is zeker in de private sector niet onmogelijk.
Lang leve de tester, die zich blijft aanpassen.
Beetje jammer dat de gegeven antwoorden zich vooral richten op Agile en applicaties.
Maar wil je slim kunnen testen, ook in complexe omgevingen, moet je daar al voordat je gaat nadenken over een ontwikkelmethode naar kijken, namelijk in je architectuur.
Aspecten als modulaire opbouw, zuivere interfaces, goede stubs en emulatoren, modules die een eigen onafhankelijke levenscyclus hebben etc. gaan je veel meer helpen bij slim testen dan welke methodiek dan ook.
Interessant om te zien dat de rode draad van EuroSTAR 2011: “Testen is dood” weer wordt aangehaald. Zoals in het artikel al wordt uitgelegd, is hier natuurlijk geen sprake van. Testen zal in een wereld die steeds meer afhankelijk wordt van software een belangrijk onderdeel van ontwikkeling blijven.
Ik ben wel benieuwd waarom Model Based Testing nu ineens wel een vlucht zal nemen. 10 jaar geleden volgde ik vakken op de universiteit die over Mobel Based Testing gingen, maar in de praktijk kom ik het nog zelden tegen. Er is mij toen verteld dat iemand die goed modellen kan maken en bijhouden goud geld kon verdienen. Helaas blijkt het in de praktijk moeilijk om goede modellen te maken. Wat al aangeven wordt er is een “rap tempo in een wereld waarin verandering de enige constante is” en juist dit tempo en de verandering zorgen er voor dat de modellen niet, of niet correct gemaakt worden.
Daarnaast denk ik dat de investering die nodig is om de modellen goed en up-to-date te houden, veel van de kostenbesparing op testen teniet zal doen.
Ik ben het eens met Jeroen, er worden al 10 jaar pogingen gedaan om MBT van de grond te krijgen, maar volgens mij is het te ingewikkeld en te arbeidsintensief. Methodes zijn prima, maar als je het niet kunt uitleggen aan anderen dan testers, dan is de acceptatiegraad laag en zul je in de meeste organisaties de handen niet op elkaar krijgen om het zo te gaan doen. Ook botst het teveel met de Agile/Scrum aanpak.
Dat de rol van de tester zich verplaatst is niet iets van de nieuwe generatie testers, deze beweging is al jaren bezig, vooral ook in de wat kleinere organisaties waar budgetten kleiner zijn en je dus het testen op een creatieve en effectieve manier moet organiseren.
Mijn succesvolle aanpak in een notendop is:
– creëer draagvlak in je organisatie, met name bij management, beheer en gebruikers
– vul alle randvoorwaarden in zoals testproces, tooling, testomgevingen e.d.
– betrek beheer en gebruikers al vroeg in de aanpak en geef ze een duidelijke verantwoordelijkheid in het testen (acceptatie is geen ICT feestje)
– werk vanuit risico´s. Geen risico is niet testen.
– pas de methode toe die past bij de organisatie en het project. Kun je testen voorbereiden doe het dan, kan het niet gebruik dan b.v. exploratory testing of pair testing. Er is een keur aan methodes en een goed testtraject valt of staat met de juiste toepassing op het juiste moment. Dit vereist een ervaren testmanager/coordinator.
– begeleid de beheerders en gebruikers actief bij de testen
– gebruik testers die bovenstaande kunnen toepassen en dus naast tester ook communicatief sterk zijn richting zowel beheerders als gebruikers alsook ontwikkelaars
Conclusie: testen is niet dood en het is belangrijk om het ook apart op de kaart te laten staan, maar het testen kan niet overleven als je het niet ziet als een integraal deel van het totale ontwikkel- en acceptatieproces
De conclusie aan het einde van de dag was dat Testen helemaal niet dood was, ten zij je als een kip zonder kop TMap toe past van a tot z. Als je test op basis van een PRA en de juiste technieken past binnen de juiste omgeving dan is testen verre van dood.
De laatste presentatie die ik heb bijgewoond die dag had te titel evolve or die en dat is wat er in testland aan de hand is, we moeten mee gaan met het tijdsgewricht, de ontwikkelmethoden en de eisen en wensen die er aan de testprofessional wordt gesteld.
Wat betreft model based testing, ben ik wat meer sceptisch dan
wat de interviewer aangeeft. Ik denk dat het een zelfde lot is
beschoren als geautomatiseerd testframeworks in de jaren 90. Maar voor
de systeem- en functionele testen zie ik het in de nabije toekomst
wel als een mogelijke aanvulling op het testspectrum.
De vraag die bij MBT gesteld moet worden: “wie geeft de garantie dat het model correct is gecreëerd?” en daar heb ik niemand nog een antwoord op horen geven.
Tom, ik kan het niet laten om even te beginnen over je laatste vraag: “wie geeft de garantie dat het model correct is gecreëerd?”. Is het niet een retorische vraag en is die niet gelijk aan de volgende vraag: wie geeft de garantie dat je testgeval correct is? En hoe controleer je dat? Als je die vragen beantwoord dan heb je ook antwoord op je vraag mbt MBT.
Zeer eens met voorgaande reacties waarin de nodige scepsis wordt uitgesproken ten aanzien van Model Based Testing.
Mijns inziens valt MBT in de categorie: waarom gemakkelijk doen, als het moeilijk kan.
Waarbij dat “gemakkelijk” al ingewikkeld genoeg is..
Het is duidelijk dat de geïnterviewde nog niet is doordrongen van “the End of Control as we know it”. Nog eens weer worden hier, maar ook al in de eerder verschenen infomercial “MBT: revolutie of oude wijn in nieuwe zakken”, stroomdiagrammen en pseudocode uit de kast gehaald voor het opzetten van eenduidige en formele modellen in een laatste poging het testvak alsnog een wetenschappelijke allure te geven. MBT kan haar pretentie: “uit modellen testgevallen geautomatiseerd afleiden en uitvoeren” op geen enkele wijze waarmaken.
In de eerste plaats is het afleiden van testgevallen een heel andere bezigheid dan het uitvoeren van testgevallen. Inderdaad wil je beide activiteiten ondersteunen met testtooling, en handmatige werkzaamheden zoveel mogelijk automatiseren. Maar de suggestie dat uit de specificatie van de testgevallen ook de complete testscripts gegenereerd kunnen worden, waarmee deze testgevallen kunnen worden uitgevoerd, is misleidend. Hiervoor is verschillende tooling noodzakelijk.
Voor het geautomatiseerd afleiden van proefgevallen beschikken testers al sinds jaar en dag over een uitstekende testspecificatietechniek in de vorm van beslissingstabellen. Met één druk op de knop kan uit een aantal gekoppelde tabellen een opsomming van benodigde testgevallen worden gegenereerd en hiervoor zijn bepaald niet complexe tools benodigd. Wat dat betreft is er niet zoveel mis met pseudocode, zolang dit maar wordt toegepast in beslissingstabellen en niet in hopeloos geneste ALS..DAN-constructies. Om nog maar te zwijgen van het afleiden van testgevallen uit flowchart-spaghetti.
Met de misplaatste aandacht voor MBT de afgelopen jaren, vooral vanuit de academische hoek, heeft de testwereld aanzienlijke kansen met betrekking tot het gebruik van beslissingstabellen laten liggen.
Te denken valt aan het gebruik van conditie-subtabellen, waarbij de expliciete verwijzingen tussen tabellen (Ga naar tabel x) zijn vervangen door impliciete verwijzingen: conditie’s in tabellen kunnen tevens conclusies zijn in andere tabellen, die dan conditie-subtabellen worden genoemd. Deze aanpak sluit naadloos aan bij het testen van SOA’s, vooral als deze tot een minimum zijn gecombineerd met BPM. Want: binnen een service georiënteerde architectuur (SOA) is het goed mogelijk dat zo’n subconditie wordt geëvalueerd binnen een andere applicatie op een ander platform.
Ook ten aanzien van het geautomatiseerd uitvoeren van testgevallen heeft men stevige kansen laten liggen. Hierbij valt te denken aan het genereren van testscripts op basis van testscript-templates. Zoals al eerder gesteld is het een illusie te denken dat testscripts gegenereerd kunnen worden uit de testspecificatie; hiervoor is grondige kennis van de applicatie en de onderliggende platforms nodig, en dan kun je de produktiviteit van testers enorm verhogen als je die kennis borgt en beschikbaar stelt door middel van testscript-templates.
Het is interessant om te zien dat er in bijna ieder bericht over Applicatie ontwikkeling onmiddellijk een link gelegd wordt met Agile. Alsof dit de enige methode is waarmee ontwikkeld KAN worden. Laat ik beginnen om te zeggen dat ik een voorstander ben van Agile Development. Er zitten enorme voordelen aan deze manier van ontwikkelen. Maar er zijn ook zaken waar we onze ogen niet voor moeten sluiten. Niet iedere ontwikkelaar is geschikt om in een agile team te werken. Ten tweede kunnen de eindgebruikers niet bij iedere applicatie de actieve rol spelen die van hen verwacht wordt bij Agile Development. We lijken te vergeten dat er nog legio “legacy” applicaties zijn die onderhouden moeten worden en waaraan nieuwe functionaliteit toegevoegd moet worden. En als deze nieuwe functionaliteit in strak omlijnd plan past is het vaak onzin om dit als Agile proces uit te voeren. Zeker niet als laatste, maar wel een belangrijk argument is de zogenaamde “creeping scope” die we vaak zien bij Agile projecten. Omdat we flexibel KUNNEN zijn, wordt vaak verwacht dat we wel heel ERG flexibel moeten zijn.
Terug naar de testers. Hoe goed een tester ook is, hij is geen eindgebruiker. En juist omdat tijdens een agile proces vaak met erg strakke deadlines gewerkt wordt moet er veel getest worden en helaas vaak met deelgebiedjes van een applicatie. Het overzicht ontbreekt dus in veel gevallen. Daarnaast is er vaak minder aandacht voor documentatie, terwijl dit juist voor testers van enorm groot belang is. Zonder goede documentatie is goed testen eigenlijk onmogelijk. Het bewijs voor dit alles is eigenlijk simpel; veel grote organisaties werken nog steeds met (mainframe) applicaties die 20+ jaren geleden ontwikkeld zijn. Zo goed geschreven, gedocumenteerd en getest dat het te lang duurde en we naar andere design- ontwikkel en test methodes zijn gaan zoeken. Maar de Software Life Cycle management die in deze omgeving al decennia in gebruik is zorgt er wel voor dat deze applicaties tot op de dag van vandaag nog steeds werken. Gelukkig is er tegenwoordig DevOps en de software en technieken die daar nu gebruikt worden zorgen er voor dat het proces van ontwikkelen, testen en in productie nemen sterk verbeterd is. Maar veel belangrijker is dat goede DevOps tools vooral een aantal zaken afdwingen die de kwaliteit van het uiteindelijke product ten goede komen. Zo zien we dat Agile Development een beter en betrouwbaarder eindproduct oplevert juist door technieken toe te passen die we op het mainframe al tientallen jaren hebben gebruikt.
Testen is een vak. En iedere methode waarmee ontwikkeld wordt vereist niet alleen een andere aanpak van testen, het vereist in veel gevallen zelfs een ander soort persoonlijkheid. Waar een verbeterde versie van een legacy applicatie door iemand getest wordt die het geheel moet kunnen overzien zijn bij het testen van een applicatie die Agile ontwikkeld is vooral goede communicatieve eigenschappen erg belangrijk.
Zoals bij alles is de opmerking “het hangt er maar net van af” ook op dit onderwerk van toepassing. One size fits all is (helaas) ook op het gebied van software development een droom.
Testen is een vak, lang leve de tester.
Er is nog steeds veel waterval ontwikkeling gaande. Overigens: volgens ons bestaat er zeker geen standaard “agile” aanpak. welke hartbeat wordt gehanteerd, wanneer de Q&A slag wordt doorgevoerd, re-work in de sprint of na de sprint, alles meteen in productie ofwel aparte release-sprints (met de legacy keten erachter??). De standaard bestaat niet.
Vrijwel alle systemen die ontwikeld of ingericht worden maken deel uit van een keten. Het is dan vooral interessant om naar de hele keten te kijken. op die manier beschouwd kan in een agile ontwikkel traject prima op verschillende manieren getest worden, handmatig, geautomatiseerd ofwel MBT; in feite is dat een afweging die te maken heeft met houdbaarheid, duurzaamheid, kosten en strategische keuzes.
Belangrijk blijft idd de user acceptance test. Echter, er zijn daarnaast nog meer testen die wij als noodzakelijk zien; binnen de keten zal ook getest moeten worden. Ook zien we vaker in de OTAP straat een separate integratietest, aangezien meer en meer (cloud)services geintegreerd worden in applicatie. Omdat veel omgevingen online gaan, ofwel intern binnen organisaties via een web-interface ontsloten worden komen hier oon non-functionele testen bij kijken, platform compatibility en responsiveness testen.
Kortom: leve de tester!!
Overigens mag die tester wat (klanten van) ons betreft ook een tester met autisme zijn.
Zo lang ik me kan herinneren worden de testers bij ons al vanaf het begin van een ontwikkeltraject betrokken. Zeker in een Agile omgeving is het relatief eenvoudig om testers en ontwikkelaars dicht bij elkaar te zetten. De opgeleverde (deel)componenten in een sprint of iteratie kunnen zo snel worden meegenomen in het test traject. Op deze manier worden problemen al op een vroeg tijdstip gevonden, en hoe eerder problemen worden gevonden hoe minder tijd (en geld) het kost om ze te verhelpen.