De vragen die werden gesteld tijdens en na afloop van het webinar ‘Assessing and Pushing the Quality of Software Development’ (24 juni 2021) en de antwoorden daarop:
| Q | : | Ik werk bij een bedrijf dat nog niet Agile is. Wat nu? |
| A | :
|
Op zich hoeft dit geen issue te zijn. De eerste vraag die klanten zichzelf in zo’n situatie moeten afvragen, is: tegen welke problemen loop je aan en wat wil je verbeteren? Ook op dit vlak hebben we veel ervaring. Een Test Process Improvement (TPI® Next) assessment zou hier prima bij kunnen helpen om dit inzicht te verkrijgen.
In de praktijk zien we geregeld dat organisaties over gaan op Agile Scrum, CI/CD2 of DevOps, omdat het een nieuwe trend is. Dit raden wij af. Er zijn prima situaties denkbaar waar een traditionele waterval methode goed geschikt voor is. |
| Q | : | Wim ten Tusscher had het in zijn presentatie over ‘Dot Voting’. Wat is dat? |
| A | : | Dat is een simpel prioriteringsproces voor teams. Elk teamlid krijgt een aantal votes (zeg 5) die hij kan verdelen over b.v. verbeterpunten die uit de retro zijn gekomen. Je kunt dit in de echte wereld doen door stippen op het papieren issue te zetten, vandaar de naam ‘dot voting’. Het is toegestaan om meerdere votes aan één verbetering te geven. Het verbeterpunt met de meeste team votes kan dan als eerste worden opgepakt. |
| Q | : | Hoe kun je de kosten van niet verbeteren zichtbaar maken? Als een verbetering die niet wordt doorgevoerd voor iedere wijziging een kwartier extra kost is de waarde snel duidelijk, maar wat als het minder duidelijk is? |
| A | : | Door de pijn concreet te maken in metrieken en die transparant te communiceren. Als voorbeeld: aantal showstopper bevindingen in productie. Aantal niet-opgeleverde story punten als gevolg van verstoring door ad-hoc werk. Als je analytics in productie hebt draaien kun je hier ook prachtige metrieken uit halen als het aantal “niet conversies” op bv een web shop. Dit zijn het aantal bezoekers dat uiteindelijk niets koopt. |
| Q | : | Waar staat ‘TI’ voor in jullie producten, bijvoorbeeld TI4Agile? |
| A | : | Robin: ‘TI’ staat voor ‘Test Improvement’ om aan te duiden dat deze producten assessment methodieken zijn voor bepaalde toepassingen, zoals in dit voorbeeld ‘Agile’. We hebben ook assessments op het gebied van bijvoorbeeld Mobile Testing (TI4Mobile) en Automation (TI4Automation). |
| Q | : | Welk percentage development capaciteit adviseren jullie om te reserveren voor testen? |
| A | : | Dit is context afhankelijk. Als je veel last krijgt van slechte kwaliteit zul je meer moeten investeren in kwaliteit en testen dan wanneer dat minder is. Is er sprake van een groot afbreukrisico, dan is veel investeren in kwaliteit en testen raadzaam. Daarnaast is het kwaliteits- c.q. volwassenheidsniveau van het team van invloed. Een vaak gehoord ‘over de duim genomen’ gemiddelde: op een team met een laag ontwikkeld kwaliteitsniveau van 6 developers horen 3 testers (+/- 50%). Als het kwaliteits- c.q. volwassenheidsniveau stijgt (= goede software testers en meer ownership voor kwaliteit door het gehele team) dan zou een team bestaande uit 6 developers met 2 testers kunnen werken (33% van de development capaciteit). |
| Q | : | Hoe creëer je draagvlak binnen een organisatie? Het ligt meestal niet aan de ideeën die men al inbrengt. |
| A | : | De ideeën zijn vaak goed en getuigen van een wil om te verbeteren/veranderen. Wat binnen een organisatie echter leeft, is dat een verandering ook negatief kan uitpakken. Bovendien is veranderen eng en spannend. Het is daarom belangrijk om het draagvlak te creëren door de stakeholders te wijzen op de huidige situatie en wat voor problemen dat oplevert. Vervolgens doe je een voorstel om te veranderen en daarmee creëer je een nieuwe situatie waar de problemen niet spelen. Als een huidige situatie niet per se problemen oplevert, dan is het de zaak om de stakeholders te laten zien wat de nieuwe situatie oplevert. |
| Q | : | Valt het testproces onder het ontwikkelproces en het ontwikkelproces onder kwaliteitsproces? Of is dit te kort door de bocht? |
| A | : | Beetje kort door de bocht, testen begint, als het goed is, al voor het eigenlijke ontwikkelproces in de idee fase. Maar kort door de bocht kun je stellen dat het testproces onderdeel is van het ontwikkelproces. Naast het testproces heb je dan het coderingsproces (het maken van code). Het ontwikkelproces valt niet onder het kwaliteitsproces. Het kwaliteitsproces is een ondersteunend proces aan het ontwikkelproces.
|
| Q | : | TI4 doet vermoeden dat het alleen om testen gaat of wordt er binnen deze dienst ook verder gekeken dan alleen het testproces? Dus over de totale keten (en dus ook het ontwikkelproces en kwaliteitsproces)? |
| A | : | TI4Agile kijkt veel breder dan alleen testen. Alle randvoorwaarden die van invloed kunnen zijn op de kwaliteit van het testen zijn ook in scope. Denk daarbij aan stakeholder involvement, aan team samenstelling en dynamiek en aan gedrag en interactie van mensen. TI4Mobile en TI4Automation zijn wel wat meer gefocust op testen. Dit zijn meer verdiepingsmodellen op mobile en automation context. |
De presentatoren van het webinar ‘Assessing and Pushing the Quality of Software Development’ Van links naar rechts: Wim ten Tusscher, Kasper Faber en Robin Oduber.
Kijk voor meer informatie: onze blogreeks over Context Driven Testverbetering of kijk welke TI4 aanpakken wij ontwikkeld hebben voor testverbetering.
Wilt u het webinar nog eens terugzien, of heeft u het gemist, dan kunt u HIER de replay bekijken.
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 4 keer per jaar wordt verzonden.
