Auteur: Gilbert Smulders ● gilbert.smulders@viqit.nl
Gisteren werd ik door de redactie van TestNetNieuws geattendeerd op mijn video review voor dit kwartaal. Als ik maar kort de tijd heb om een video op te zoeken voor een review, kijk ik vaak bij een aantal personen die mij eerder geïnspireerd hebben. Daarom vond ik deze video van Alan Richardson over Software Testing. Aangezien deze teruggrijpt naar de basis, waarom we überhaupt testen, leek me dit een mooi onderwerp voor een review.
De spreker
Alan Richardson is een Brit die zichzelf ten doel heeft gesteld om teams beter te laten opleveren, automatiseren en testen. Hij is ook bekend onder zijn pseudoniem Evil Tester. Onder die naam publiceert hij regelmatig blogs, podcasts en video’s. Daarnaast verzorgt hij trainingen en schrijft hij boeken. Alan heeft ervaring als softwaretesting consultant bij diverse financiële instellingen, gaming, media, luchtvaart, energie en telecombedrijven. Daarnaast is hij actief als spreker op conferenties over de hele wereld. Daarbij heeft hij uiteraard ook op TestNet gesproken. Ook toen wist hij mij al erg te inspireren. Net als later gedurende een aantal video reviews.
De presentatie
Alans presentatie is gericht op het in gezond verstand en normale taal uitleggen wat software testen is en waarom wij eigenlijk testen. Daarbij probeert hij het vooral kort en bondig te houden.
Hij begint met de vraag ‘Waarom testen we?’ Deze vraag is eenvoudig te beantwoorden. We ontwikkelen software en we maken fouten bij het ontwikkelen van software. Die fouten kunnen tot problemen lijden op productie. Problemen zoals fouten, performance problemen, slechte gebruikerservaring, etc. We proberen die fouten eerder te vinden dan op productie. Daarom testen wij. Daarbij willen wij leren van de werkelijkheid en niet van de verwachting. We hebben namelijk de verwachting dat er geen fouten in onze software zit. De werkelijkheid is echter weerbarstiger.
De tweede vraag is Wat is software testen?’ We moeten problemen kunnen vinden. We moeten weten hoe we de software bedienen om de fouten te vinden. We moeten ook verschillende werkwijze hanteren om verschillende fouten te vinden. Om die fouten te kunnen vinden moeten we eerst een model maken van wat de software doet. Vervolgens vergelijken wij wat de software in werkelijkheid doet met wat wij verwacht hadden op basis van ons model. Tijdens het testen leren we van wat er in werkelijkheid gebeurt. De vraag is continu of de software klopt of dat ons model klopt. Hij legt dit uit aan de hand van een simpele test met de Google zoek functie. Het model dat hij hierbij verzint is dat als je een zoek term opgeeft in Google dat je resultaten krijgt.
Hij gaat daarbij dieper in op het leren. Als wij aan het testen zijn constateren wij allerlei dingen die wij nog niet wisten. Feitelijk zijn dat gaten in ons model. Van die gaten moeten wij leren en ons model uitbreiden. In zijn voorbeeld benoemt hij de paginering. In ons oorspronkelijke model hadden wij nog niets over paginering gezegd. Maar omdat wij onderaan meerdere pagina’s zien, passen wij ons model aan. Wij verwachten nu dat als wij op de volgende pagina klikken dat er nieuwe resultaten komen. En als wij weer terug gaan naar de eerste pagina dat de oude resultaten weer tevoorschijn komen. Zo blijven wij ons model continu bijstellen en dat is feitelijk wat testen betekent.
Alan benoemt daarna verschillende soorten modellen die wij gebruiken. Modellen zoals requirements, risico’s, bevindingen, performance, fysieke modellen en allerlei andere modellen kunnen wij gebruiken bij het testen. En tijdens het testen bouwen we steeds nieuwe modellen. Onderzoekende modellen met dingen die wij willen proberen en waar wij nog naar willen kijken. En exploiterende modellen waarbij we functionaliteit bekijken en bedenken wat het allemaal wel en niet zou moet kunnen doen. En allerlei andere maatwerk modellen om ons werk goed te kunnen doen.
Daarna richt Alan zich op de manier waarop wij tot modellen komen. In de traditionele manier bedenken wij de modellen vooraf. Waarbij bijvoorbeeld de requirementsmodellen vooraf helemaal moeten zijn gemaakt en niet meer gewijzigd kunnen worden. En soms gaan we nog verder door vooraf onze strategie en aanpak om die modellen te vergelijken met de software ook willen fixeren. Dat is een hoop werk en vertraagd het leerproces. En er is het risico dat ons model niet klopt of dat onze aanpak om die te controleren niet klopt. En als dan blijkt dat het model niet klopt hebben we een hoop werk om ons model bij te stellen. Andere organisaties gebruiken een meer Agile aanpak. Daarbij wordt minder tijd gespendeerd aan het maken van het model en de aanpak om dit te controleren. We leren terwijl wij bezig zijn, daar zijn testers bekwaam genoeg voor.
Alvorens af te sluiten heeft hij het over de evolutie van testen. Wij hebben geleerd om modellen te hergebruiken. Om te identificeren hoe we die modellen moeten gebruiken zijn we tot testtechnieken gekomen. Hij benoemt allerlei testtechnieken en koppelt dit aan de modellen die daar bij horen. Deze technieken leren ons hoe wij de software moeten bekijken om een bepaalde dekking te krijgen. De technieken geven ons richting over hoe we moeten testen.
Alan besluit zijn presentatie met het kort beantwoorden van de twee gestelde vragen. Waarom testen wij software? Omdat software ontwikkeling mensenwerk is en daar fouten gemaakt kunnen worden. Wat is software testen eigenlijk? Het maken van modellen en die vergelijken met de software. Veel ingewikkelder is het niet!
Mijn visie
Alan legt het allemaal heel eenvoudig uit. Over het algemeen zijn wij als testers gewend om ons vak heel ingewikkeld uit te leggen. Het is namelijk iets wat niet iedereen kan. Daarvoor hebben wij allerlei ingewikkelde methoden en technieken geleerd. Bovendien vraagt het heel veel van onze vaardigheden. Als het dan zo simpel wordt uitgelegd als Alan doet is dan toch even slikken. Maar eigenlijk heeft hij wel gelijk. En natuurlijk is zijn voorbeeld veel simplistischer dan in werkelijkheid. Maar de basis klopt. Testen is je verwachting reflecteren op het werkelijk resultaat. En klopt het werkelijke resultaat of klopt de verwachting of komen ze met elkaar overeen? En zoals Alan het verteld klinkt Agile testen veel logischer dan het traditionele waterval testen. Je wilt zo snel mogelijk je model verifiëren en bijstellen op basis van wat je van de werkelijkheid leert. En zeker met zo’n simpel voorbeeld dat Alan schetst past die exploratory aanpak. Echter er zijn ook complexere situaties die vragen om een nauwgezet model. Dat vraagt om meer voorbereiding en een gedegen model vooraf. En daar ligt volgens mij de kracht van de tester. Welke zaken moet ik vooraf heel nauwkeurig modelleren op basis van requirements en risico’s en welke zaken kan ik modelleren tijdens het testen. Uiteindelijk gaat het om software die de organisatie toegevoegde waarde levert. En wat wij daarvoor binnen het softwareontwikkelproces allemaal moeten doen is ons vak. Daarbij helpt het als wij ons vak simpel weten uit te leggen aan de organisatie. Dat zorgt voor inzicht, begrip en vertrouwen.
Al met al een video van Alan Richardson die zeker de moeite waard is om eens te bekijken.