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:
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:
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:
|
| 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.
