Weet jij het verschil tussen (uit)proberen en testen? Wees gerust, we gaan hier geen semantische discussie voeren. Maar wat we wel kwijt willen is dat we ruwweg twee smaken zien als het gaat om applicaties testen. Namelijk bedrijven die applicaties (uit)proberen en bedrijven die applicaties testen. En daar zit een wereld van verschil tussen!
Verontrustend
Het is eigenlijk ernstig te moeten constateren dat veel organisaties in onze zwaar geautomatiseerde maatschappij software niet testen maar het (uit)proberen. Nog ernstiger is dat het hoger management vaak geen beeld heeft van applicaties testen. Het wordt als hinderlijk of te kostbaar gezien. Pas als er iets misgaat worden er kritische vragen gesteld.
Applicaties testen vraagt eigenaarschap, procesbeschrijvingen, planning & coördinatie, testkennis, tijd, discipline en professionele tooling. Echter, zodra er sprake is van incidenteel toetsen van (nieuwe) software, verslaglegging in spreadsheets en gebrek aan wil en uitvoering, is er sprake van applicaties (uit)proberen.
Gek genoeg blijkt het (uit)proberen van applicaties nog veelal de praktijk te zijn. Verontrustend vinden we dat. Het Testersuite team komt deze situatie dagelijks tegen. En zeker niet bij de MKB-er om de hoek. In tegendeel.
Nog verontrustender
Een fenomeen wat nog verontrustender is, is het delen van testresultaten. Hierbij zien we dat twee of meerdere organisaties die dezelfde applicatie gebruiken tegelijk releases testen. Dit werkt schijnzekerheid in de hand. Hoe kun je er namelijk op vertrouwen dat een voor jou relevante module goed getest is door een collega-bedrijf? Goed, je gebruikt dezelfde modules van een applicatie maar is de configuratie exact gelijk? Liggen de kwaliteitseisen op hetzelfde niveau? Zijn de testers wel van het kaliber zoals je die zelf hebt opgeleid? En zo kunnen we nog wel een aantal vragen bedenken.
Stel dat bedrijf A,B en C tegelijk eenzelfde release van een applicatie testen. De testresultaten worden gedeeld tijdens het testtraject. Bij de inschatting van risico's wordt de focus voor een groot deel bepaald door de testresultaten van de collega bedrijven die ook aan het testen zijn. Modificaties die al zijn getest door de collega bedrijven en die geen bugs hebben opgeleverd krijgen vanzelf minder focus. Hier komt het risico van schijnzekerheid om de hoek kijken wat kan leiden tot een verkeerde focus. Het kan goed zijn dat de inrichting van de applicatie verschilt of dat er niet goed is getest door de collega bedrijven. Een modificatie krijgt onvoldoende aandacht in het testtraject en in productie ontstaan de problemen. Neem gerust van ons aan dat wij veel praktijkvoorbeelden kennen waarbij dit flink is misgegaan.
Verstandig omgaan met delen van content
Ook wij zien in de praktijk dat het zinvol kan zijn om content (bijvoorbeeld testscenario's) en testresultaten te delen met collega bedrijven die dezelfde applicaties testen. Testersuite biedt ook functionaliteit om dit te doen. Overschat alleen niet de toegevoegde waarde. Ieder bedrijf zal nog altijd zelf een risico inschatting moeten doen en de modificaties uit een release moeten testen. Waak daarbij over het risico van schijnzekerheid!
Niet te licht denken over applicaties testen
Onze boodschap is ‘denk niet te licht over testen’. Applicaties testen is een vak en geen kwestie van (uit)proberen. Iets wat ze in de luchtvaartindustrie langgeleden al ontdekt hebben. Gelukkig spreken wij veel testcoördinatoren en testmanagers die weten waar ze het over hebben. Wij zien hun dagelijkse strijd tegen het hoger management. Bij deze willen we ze dan ook een hart onder de riem steken.
