Q&A webinar 'Het effect van Agile en DevOps op de rol van de testspecialist' | Polteq, specialist in software testen
Delen Printen E-mail

De  vragen die werden gesteld tijdens en na afloop van het webinar ‘Het effect van Agile en DevOps op de rol van de testspecialist’ (30 september 2021) en de antwoorden daarop:

Q : Er is veel discussie over de rol van specialisten en generalisten binnen Agile en DevOps teams. Dit gaat zo ver dat er stemmen zijn die generalisten dan wel specialisten als ‘niet ideaal/ wenselijk’ bestempelen binnen een team. Hoe zien jullie dit?
A :

 

De algemene consensus op dit moment lijkt te zijn dat een team van specialisten normaal gesproken altijd een team van generalisten zal outperformen. Uiteraard heeft een team bestaande uit enkel specialisten ook haar tekortkomingen, echter wegen deze op tegen de nadelen van een team bestaande uit enkel generalisten. Desondanks zien we deze discussie meer als een puur theoretische discussie dan als een praktische discussie. Dit omdat het in de praktijk vrijwel niet voorkomt dat organisaties beschikken over enkel specialisten of enkel generalisten. Enkele factoren die hier op inspelen zijn:

  • Op dit moment is er een groot tekort aan bekwaam IT-personeel (de vraag is groter dan het aanbod). Kortom: het is juist van belang om zoveel mogelijk mensen te includeren in IT-ontwikkeling om te kunnen blijven voldoen aan de vraag vanuit de markt. Het is dan ook geen keuze is of je enkel generalisten of enkel specialisten wilt, maar je moet op zoek naar de optimale balans.
  • Ieder perspectief kent haar eigen voor- en nadelen: zo zijn generalisten vaak minder in staat om de beste oplossing aan te dragen en tegelijkertijd beter in het duiden en definiëren van het achterliggende probleem. Specialisten zijn vaak beter in het concreet oplossen van deze problemen. Beide vaardigheden zijn nodig in een succesvol team of project.

 Vanuit Polteq vinden we het vooral belangrijk om in te spelen op deze discussie door de definitie van ‘testspecialist’ te veranderen. Je blijft specialist in softwaretesten en softwarekwaliteit, echter zijn we van mening dat je je hierbij op z’n minst ook moet ontwikkelen op andere disciplines binnen het team (i.e. het zogenoemde ‘T-shaped’-profiel). Dit betekent bijvoorbeeld dat je als testspecialist meer ‘development skills’ opdoet, je specialiseert binnen het marktdomein, of je – naast het zijn van testspecialist – ook de rol van scrum master kunt vervullen. Niets voor niets haalden we tijdens het webinar de volgende quote aan:

“DevOps means you should care about your job enough to want to learn all the parts and not just your little world”, #DevOpsDays, 2014

   
Q : Wat is het grootste verschil tussen het meer klassieke (waterval) testen en het testen nu binnen een Agile en DevOps context en wat vraagt dit van (test)specialisten?
A : Waar we bij waterval testen uitgingen van een vaste, vooraf opgestelde en onveranderlijke testbasis, die leidde tot een testplan en tests, is deze testbasis bij Agile/DevOps testen vaak afwezig en aan verandering onderhevig. We stellen daarom vaak in de praktijk geen vast testplan meer op, maar werken met een teststrategie, die ook blijvend geëvalueerd en bijgesteld wordt. Daarnaast moeten we als team nu snel opleveren, waardoor we vaker en sneller testen. Daarvoor kiezen we andere testmethodieken, bij voorkeur met een groot deel automatische tests, en een klein(er) maar noodzakelijk deel handmatig/exploratory tests. Dit houdt in dat je als testspecialist vaker aan het coderen bent.
   
Q : Denken jullie dat de opkomst van Micro Services architecturen bij organisaties ervoor hebben gezorgd dat Agile en DevOps hun positie hebben veroverd? Met andere woorden: als we nog met monolieten hadden gewerkt, hadden Agile en/of DevOps dan ook de posities gehad die ze nu hebben?
A :  Het is lastig om specifiek één factor aan te wijzen die andere trends en/of ontwikkelingen één-op-één verklaren. Vaak zijn er meerdere factoren die elkaar versterken en voor een evolutie/revolutie zorgen in de wijze waarop we als maatschappij werken. In welke richting dit causaal verband loopt (oorzaak <> gevolg) is dan ook vaak niet eenduidig te definiëren.

Met die nuance, kun je zeker stellen dat de opkomst van ‘Micro Services’-architecturen heeft bijgedragen aan de opkomst van Agile en DevOps (en vice versa). Desondanks, zie je ook in organisaties met ‘monolithische’ systemen, dat ook zij ‘Agile’ principes hanteren en aanpalende systemen en/of processen op een ‘Agile’ werkwijze aanpakken. Eén van de manieren om dan rond zo’n ‘monolithisch’ systeem te werken, is het opknippen van de business in ‘value streams’ (waardeketens), waarbij elk (agile) team een deel van de monoliet onder haar verantwoordelijkheid krijgt (als onderdeel van de value stream). Uiteindelijk wordt zo’n ‘monolithisch systeem’ toch een keer vervangen.

   
Q : Wordt tegenwoordig ook getest of de automatische testen oude bugs blijven vinden? Dus bewust (oude bekende) fouten terugzetten?
A : Jazeker, maar niet altijd op die manier. Bekende methodes zijn ‘fault seeding’ (waarbij een automatische tool fouten veroorzaakt in de software die getest wordt) en ‘fault injection’ (waarbij een automatische tool foute input stuurt). Daarna kijken we of de automatische tests deze nieuwe fouten detecteert. We moeten als ontwikkelaars van automatische tests ook blijven kijken naar onze controles en deze bewust aanpassen zodat ze falen om te zien of ze goed werken. Belangrijk is ook om ‘flaky tests’ (tests die soms slagen, soms niet) niet te accepteren of uit te zetten, omdat dit een vals gevoel van veiligheid kan creëren. Tests die op bestaande bugs blijven falen moeten erin te blijven zitten, zodat we bewust blijven van de bestaande kwaliteit. Het gaat hierbij niet specifiek om het terugzetten van een bekende oude bug, maar om algemene technieken om de kwaliteit van de automatische tests te waarborgen.
   
Q : Schuift het coderen van automatische tests niet steeds meer richting developers met tools als Cypress?
A : Even los van Cypress of andere tools, kan dit een oplossing zijn als de technische kennis die nodig is voor het transformeren van functionele tests in geautomatiseerde tests ontbreekt bij de testspecialist in het team, óf de developer(s) binnen het team waardevolle optimalisatieslagen kunnen maken in het testframework (wat vaak zo is vanwege het specialisme van de developer). We zien niet de algemene trend dat ‘testautomatisering’ opschuift richting developers. Dit bijvoorbeeld omdat:

  • Testautomatisering, zoals aangegeven tijdens het webinar, begint bij het opstellen van een testset met goede testdekking. Testprofessionals/-specialisten kijken hiernaar met een ander perspectief/mindset.
  • developers – vanuit het Agile principe – de meeste waarde toevoegen door zich te focussen op het ontwikkelen van werkende software en niet op het automatiseren van testscripts.
  • we in de praktijk vaak zien dat het automatiseren van tests – ondanks dat dit ook programmeren is – toch vaak een ander speelveld betreft, bijv. testdata, testtools, etc. hetgeen extra ten koste gaat van de aandacht voor ‘development’.

Wat we vaak zien is dat wij als testspecialist juist worden ingezet om onze kennis van zowel het testvak in het algemeen als onze technische expertise in het bijzonder, en dat de business kennis wordt opgevangen door interne (test)medewerkers. Zij hebben minder kennis van de technische kant van het testen, maar zijn juist goed in het maken van de business specifieke testcases.

   
Q : Bij DevOps lopen de rollen wat meer in elkaar over. Dit houdt in dat testers al meer (moeten) programmeren dan voorheen. Hoe gaan jullie hiermee om, met bijvoorbeeld junior testers?
A : Deze vraag kan op meerdere manieren geïnterpreteerd worden:

  1. Het opleiden van (junior) testprofessionals: we blijven dé expert in software testen c.q. kwaliteit en, zoals Sara ook in haar presentatie toelichtte, kijken we als (junior) testprofessional toch met een andere bril naar IT-oplossingen. Dit (specialisme) blijven we bevorderen en stimuleren. Wat we anders doen is dat we onze (junior) testprofessionals ook de Agile en DevOps principes en werkwijze bijbrengen, zodat zij goed op de hoogte zijn van wat er van hen verwacht mag worden. Als derde werken veel van onze medewerkers ook aan een tweede of zelfs een derde discipline (bijv. Developer, Scrum Master, Requirement engineer, Dev of Ops Engineer). Dit staat los van de mate waarin de medewerker junior/senior is. Dit geldt voor ieder van onze testprofessionals.

Hoe ga je om met teamsamenstelling, bijvoorbeeld door het inzetten van junioren: zoals gezegd zijn in Agile, het samenwerken binnen het team en het duiden van feedback vanuit de eindgebruiker, twee fundamentele zaken. Kortom: het gaat om het bereiken van een optimale teamsamenstelling of mix aan goed IT-personeel (balans tussen generalisten en specialisten). Niet elk team of klantorganisatie heeft direct een senior testspecialist nodig en men heeft vaak al een gevoel over welke disciplines ondervertegenwoordigd zijn binnen het team. In dergelijke gevallen kan het best zijn dat een junior testspecialist met generalistische kennis een betere aanvulling is dat een doorgewinterde testspecialist met development skills.

   
Q : Schuilt de kracht van testers er niet in dat, voordat er ook maar iets gebouwd is, defects zijn gevonden (e.g. reviewen van requirements) of zaken goed gebouwd gaan worden (e.g. input geven bij de acceptatiecriteria)?
A : Absoluut, hoe eerder in het proces een bevinding wordt gedaan, hoe goedkoper het is om deze op te lossen. Maar, na het reviewen en input geven op documentatie vooraf houdt ons werk niet op. We moeten ook verifiëren dat de vastgestelde wensen op de juiste manier zijn uitgevoerd. Het gaat daarbij niet alleen over dat iets foutloos werkt, maar ook dat het is wat er origineel gevraagd werd.
Q : We hebben het nu wel veel over de werkzaamheden van Dev’s erbij nemen, maar sommige mensen hebben betere skills om bijvoorbeeld de scrummaster rol op te pakken. Hoe denken jullie daarover?
A : Vanuit onze ervaring kunnen we dit bevestigen. We zien enerzijds dat testprofessionals zich meer bezighouden met testautomatisering (c.q. de rol van testautomatisering wordt steeds groter). Dit komt met name door de behoefte en vaak ook noodzaak om zoveel mogelijk testen te automatiseren, om zoveel mogelijk tijd over te houden voor werkzaamheden die de toegevoegde waarde verder vergroten (bijv. Handmatig en/of exploratory testen van zaken die niet te automatiseren zijn). Anderzijds waren en zijn we als testspecialist de ‘spin in het web’, omdat we als testprofessional een centrale rol vervullen in verifiëren en valideren van business eisen en wensen in de daadwerkelijk ontwikkelde oplossing. Door deze centrale positie binnen teams of in de organisatie, zien we ook vaak de combinatierol van testprofessional en Scrum Master voorbijkomen. Afhankelijk van het profiel van de testprofessional/-specialist worden we ook gevraagd voor andere combinaties (bijv. requirement engineer, (UX) designer en in sommige gevallen zelfs Product Owner.

Heeft u vragen over dit webinar, of wilt u nog eens wat uitgebreider praten over dit onderwerp, neem dan contact op met een van onze accountmanagers of stuur ons een e-mail.

Wilt u op de hoogte blijven van komende webinars en andere Polteq evenementen, abonneert u zich dan op Polteq Vaknieuws, onze e-mail nieuwsbrief die maximaal 8 keer per jaar wordt verzonden.

Meer informatie

Heeft u een vraag of wilt u een vrijblijvende afspraak maken? Laat hieronder uw gegevens achter, dan nemen wij zo snel mogelijk contact met u op. U kunt ons natuurlijk ook bellen:

+31 (0) 33 277 35 22 (Nederland)
+32 (0) 16 39 48 04 (België)

Hoe wij dat doen?
Lees meer
Focus
Focus
Vakmanschap
Vakmanschap
Kennisdeling
Kennisdeling
Persoonlijk
Persoonlijk
Lokaal
Lokaal
Oprecht
Oprecht
Plezier
Plezier
Meer
Deze website is gerealiseerd door Webheads.

Neem contact op!