Testen van een "Kopieer data" functie, niet zo simpel als het lijkt

Snel data invoeren. Met grote regelmaat wordt hier een kopieer functie voor gebruikt. Kopieer een al eerder ingevoerd record. Waarom is dit niet simpel te testen? Technisch blijkt dit vaak vrij ingewikkeld, door alle verschillende koppelingen en tabellen. Maar in de specificaties is het regelmatig 1 zin: "Kopieer alle data in een nieuw record". Zo wordt het vaak niet gebouwd. Door technische beperkingen of door slechte controle door de ontwikkelaar (oh ja, dat veld moet ook). En dat maakt het zo'n lastige functie om te testen. De beschrijving klopt bijna nooit, maar de gevolgen van fouten kunnen wel heel groot zijn.

De basistest

De basis voor het testen van een "Kopieer data" functie is heel simpel: Vul alle velden met een andere waarde, dan de waarde die standaard gekozen wordt. En vul alle tabellen met minimaal twee records. Controleer vervolgens of al deze gegevens goed overkomen bij het kopiëren.

De kwaliteit van de kopie

Hoewel bijna elke "Kopieer data" wordt omschreven als het kopiëren van alle data, maak je hier een gebruiker bijna nooit blij mee. Als je hiermee al niet een onwerkbaar record creëert. En daarnaast geeft het niet goed aan waar je als tester op moet letten. Om dit uit te leggen, val ik in de titels een beetje terug op database termen, maar ik zal elke onderdeel toelichten aan de hand van een voorbeeld gebaseerd op een werknemer.

Primary key

Bijna altijd als je data kopieert, is er sprake van een unieke waarde per record. Bij een werknemer is dit vaak een werknemersnummer. Deze unieke waarde mag NOOIT letterlijk gekopieerd worden. Het mag leeg zijn, tot het moment van opslaan. Het mag opnieuw bepaald zijn. Maar controleer of de waarde in dit veld nog steeds een unieke waarde is en niet gelijk aan de oorspronkelijke kopie. Zeker als het veld ook nog eens niet gewijzigd mag worden, wat vaak het geval zal zijn.

N:N relatie

In bijna elk datarecord kan je data invoeren, die terugkomt in andere soortgelijke datarecords. Denk bijvoorbeeld aan de bedrijfsmiddelen, die een werknemer tot zijn beschikking krijgt. Dit kan een tabel in je scherm zijn, waarin je kan zien dat de betreffende werknemer een telefoon, een laptop en een sleutel tot het kantoorpand heeft gekregen. Maar deze keuzes zullen bij veel andere werknemers ook terugkomen. Ga goed na of deze gekopieerd worden (altijd minimaal 2 rijen in een tabel). En als dit niet het geval is, ga na of dit een bewuste, goed doordachte keuze is.

1:N relatie
Bepaalde data in tabellen is uniek voor dat betreffende datarecord. Er is echt wel meer van deze invoer, maar elke invoer is uniek voor dat datarecord. Denk hierbij aan een contract. Je kan als werknemer aansluitend meerdere contracten hebben. Maar dat contract zal slechts gekoppeld zijn aan 1 werknemer. Over het algemeen is dit data die je niet wil mee kopiëren. De gegevens zijn per werknemer zo verschillend, dat de invoer toch overnieuw moet.

Maar als het toch meegekopieerd wordt, controleer dan zeer goed of er echt sprake is van nieuw aangemaakte data. En controleer deze extra data op precies dezelfde manier als je het datarecord zelf controleert. Controleer op de primary keys en op de verschillende relaties. En vul ook hier alle velden in en vul alle tabellen met minimaal twee rijen. Als dit soort data meegekopieerd wordt, is dit een plaats waar het vaak misgaat. Omdat juist aan dit deel vaak minder aandacht wordt besteed, dan aan het oorspronkelijke datarecord.

N:1 relaties
Bovenstaande twee relatie beschrijvingen gingen over tabellen. Maar je hebt ook regelmatig comboboxen of andere manieren van selecteren, waarbij je kiest uit een standaard lijst met keuzes. Denk aan de functie van een werknemer of een manager van een werknemer. Het testen hiervan is niet zo moeilijk. Maar bij het testen zal je merken, dat hier regelmatig een veld zal missen. Al of niet om de kopie technischer makkelijk te bouwen. Besteed hier dus wel aandacht aan en vraag na waarom een veld niet gekopieerd wordt.

Speciale situaties

Bij elkaar horende gegevens

Om het kopiëren technisch eenvoudiger te maken, worden vaak besluiten genomen om bepaalde data niet in de kopie op te nemen. Dit kan, maar let wel of het eindresultaat nog genoeg kwaliteit heeft. Het gebeurt regelmatig dat gegevens eigenlijk bij elkaar horen. Als een deel hiervan wel en een deel hiervan niet gekopieerd wordt, kunnen vreemde situaties ontstaan.

Denk bij een werknemer aan de bankgegevens. Het rekeningnummer is eenvoudig gekopieerd en gaat vaak mee. Terwijl elke werknemer eigenlijk een uniek rekeningnummer heeft, dus kopiëren heeft geen waarde. De bank kan echter een combobox zijn, die is overgeslagen. Je krijgt dan de situatie waarin wel het banknummer staat, maar de bank niet wordt ingevoerd. In deze situatie is het verstandiger om alle bankgegevens leeg te laten en niet alleen de bank.

Relatie met zichzelf
Het komt zelden voor, maar het gebeurt wel: bij een van de velden kan je het ingevoerde datarecord zelf invoeren. Een voorbeeld hiervan kan zijn bij de urencontrole. Sommige werknemers mogen hun eigen uren invoeren en bevestigen, anderen moeten hun uren door een ander laten bevestigen. Bij de eerste groep kan dan in het veld "Controleur uren" de werknemer zelf worden ingevoerd.

Hoe weinig dit ook voorkomt, dit zijn heel gevaarlijke velden bij een kopieer test. Want de waarde, die hier staat, is te vaak de waarde van het oorspronkelijke datarecord, waar de kopie op gebaseerd is. Test dit daarom goed. Zo'n veld moet bij het kopiëren leeg zijn of moet al bij het aanmaken naar zichzelf verwijzen. Hier zal je speciaal op moeten testen. Doe dat ook!

Samenvatting

Dus hoe test je een "Kopieer data" functie?

• Voer alle gegevens in en vul alle tabellen met twee rijen
• Controleer goed of de primary key niet wordt gekopieerd en of de gekopieerde relaties de juiste kwaliteit hebben
• Controleer of bij elkaar horende gegevens allemaal wel of allemaal niet gekopieerd worden
• Controleer extra op velden waarin het datarecord zelf als keuze kan worden ingevoerd

Waar het op neer komt, is dat je juist bij een functie als deze niet zozeer controleert of het volgens specificaties is. Maar controleer of de kwaliteit van de gebouwde functie goed is.

Testen in een Agile team: "Vertrouw niemand, maar vertrouw iedereen"

Als tester is het je taak om alles en iedereen te controleren. Er niet vanuit te gaan dat iemand altijd goed werk levert. Als Agile teamlid is het je taak om je team te vertrouwen. Ervan uit te gaan dat iedereen altijd goed werk wil leveren. Hoe werk je binnen deze tegenstrijdigheid? Wanneer vertrouw je iemand en wanneer niet?

Het woord "Vertrouwen" is wel veelgebruikt, maar niet altijd in dezelfde betekenis. Je kan er bijvoorbeeld op vertrouwen, dat iemand altijd voor je klaar staat. Maar tegelijkertijd er niet op vertrouwen, dat deze persoon goede code oplevert. Het belangrijkste vertrouwen van een tester is gericht op het opleveren van goed werk. En dan maakt het niet uit of dit een deel van de applicatie of een document is.

Zelf kom ik tot een lijst van drie manieren van vertrouwen, die voor een tester van belang zijn:

1. Het vertrouwen dat iemand goed werk oplevert
2. Het vertrouwen dat iemand goed werk WIL opleveren
3. Het vertrouwen dat iemand goed werk KAN opleveren

Het vertrouwen dat iemand goed werk oplevert

Wat moet je hierover aan een tester uitleggen? Het werk van een tester is controleren. Controleren of een ontwikkelaar goed werk heeft geleverd. Controleren of de specificaties goed zijn opgeleverd. Dus zelfs als je dit vertrouwen hebt, moet je handelen alsof je het vertrouwen niet hebt.

Het vertrouwen dat iemand goed werk wil opleveren

Een Agile team kan alleen goed werken als de teamleden elkaar vertrouwen. Maar als je er niet op mag vertrouwen, dat iemand goed werk oplevert, waar vertrouw je dan op binnen een team? Simpel: je vertrouwt erop dat iemand goed werk wil opleveren. Dat er niemand in het team als doel wil hebben om een slecht product op te leveren. Dat iedereen in het team er alles aan doet om het product zo goed op te leveren als mogelijk is. Als het niet lukt, vertrouw je erop dat hier redenen voor zijn. Redenen, die in de ogen van de ander goed zijn. Of anders oorzaken, die een ander niet wist bij het maken van het eindproduct. Dit vertrouwen is centraal, zonder dat kan een Agile team geen team zijn. Dus zelfs als je dit vertrouwen niet hebt, moet je doen alsof je het vertouwen wel hebt.

Dit is echter niet zo simpel als bij het vorige onderwerp. Niet alleen is het vaak moeilijk op te brengen, zelfs als je het hebt is het soms moeilijk te bewijzen aan de ander. Want hoe toon je het vertrouwen dat iemand goed werk wil opleveren?

Het antwoord ligt in je woordgebruik. Voorkom zinnen als "Je bent fout", "Je hebt je vergist", "Je hebt slecht werk geleverd". En vervang ze door zinnen als "Ik snap niet waarom", "Kan je me uitleggen waarom". Combineer dit bij voorkeur met een compliment als "Ik zie dit soort fouten anders niet bij je", "Ik weet dat je X ook belangrijk vind", "Ik weet dat je een goede X bent". En daarna: luisteren, doorvragen, luisteren, doorvragen. Net zo lang tot je het besluit begrijpt. Je hoeft het er nog steeds niet mee eens te zijn, maar zorg ervoor dat je het begrijpt. En als je het begrijpt, maar nog niet overtuigd bent, dan is het moment om te vertellen wat jij had gewild. En vergeet dan ook vooral niet te vertellen waarom.

Centraal staat een positieve benadering, waarbij de wil om goed werk te leveren niet ter discussie wordt gesteld. Wat wel ter discussie wordt gesteld is het resultaat en het proces naar het resultaat. Maar het vertrouwen blijft onbesproken en daarmee overeind. Uit eigen ervaring kan ik je vertellen: je zal vaker overtuigd worden, dan je van tevoren verwacht.

Het vertrouwen dat iemand goed werk kan opleveren

Soms wil je wel, maar kan je niet geloven dat iemand goed werk op wil leveren. Want als hij het wil en hij kan het, waarom gebeurt het dan niet? Om het makkelijker te maken, kan het handig zijn om na te gaan of iemand het wel echt kan. Heeft iemand de kennis en vaardigheden om goed werk te leveren? Als je weet dat iemand een junior developer is, is het ook veel logischer als er meer fouten in het opgeleverde werk zitten. En als iemand pas sinds kort aan het product werkt, is het makkelijker te geloven dat deze persoon iets over het hoofd heeft gezien. Maar het gaat hier ook om andere factoren. Wanneer de druk hoog is, bijvoorbeeld door een harde deadline, voelen mensen zich vaak gedwongen stappen over te slaan. Stappen, die de kans op een goed product niet ten goede komen.  Als mensen een opdracht hebben gekregen, die tegenstrijdig is met een goed product, bijvoorbeeld "Doe gewoon wat er staat", kan dit ook de kwaliteit niet ten goede komen.

Het vertrouwen dat iemand goed werk op kan leveren kan dus terecht zijn, maar er kunnen zaken spelen die je niet weet. Zaken waardoor een persoon nog moet leren hoe je goed werk oplevert, zich gedwongen voelt slechter werk op te leveren of misschien zelfs andere prioriteiten heeft. Deze zaken weten, maakt het makkelijker een persoon te begrijpen. Waar het op neerkomt, is dat je weet hoe je teamleden aankijken tegen organisatie en werk. Hoe lang ze werken in hun functie, in het bedrijf en in het team. En tegen welke problemen ze aanlopen. Hier interesse in tonen geeft anderen al meer het gevoel dat je echt deel van het team wil zijn. Maar daarnaast kan jij ook hopelijk beter begrijpen, wat er speelt, als het werk niet het gewenste niveau heeft. En dat kan flink schelen in emoties, als je onverwachts slecht werk onder ogen krijgt.

Testdata management als al je klanten anders zijn

De testdata beschikbaar in de database is belangrijk. Zowel om je testen betrouwbaar, als om je testen reproduceerbaar te houden. Als je slechts 1 klant heb, kan je de data van deze klant eenvoudig als basis gebruiken. Als je klanten veel overeenkomsten hebben, kan je de deze overeenkomsten als basis gebruiken. Maar wat als al je klanten uniek zijn? Door een applicatie met een oneindig aantal mogelijkheden? Hoe kom je dan tot een basis?

Bepaal de datagroepen

De testdata is te verdelen in vier groepen. Elke groep vraagt een andere aanpak. Het is daarom van belang om eerst goed te beseffen welke data in welke groep hoort.

De gebruikersdata met regelmatig onderhoud
Het aanmaken van opdrachten of het opstellen van een planning. Het zijn werkzaamheden die regelmatig plaatsvinden. Aan de data van deze groep wordt minimaal een keer per week wel data toegevoegd, data gewijzigd en data verwijderd. Ze bevinden zich vaak in de hoofdprocessen van de applicatie, juist door hun regelmatige gebruik. En het is daarom ook van groot belang dat juist deze processen altijd goed blijven werken, ongeacht wat de gebruiker invoert.

De gebruikersdata met incidenteel onderhoud
Voor deze groep is het moeilijker om voorbeelden te geven. Waar het ene bedrijf een vaste groep klanten heeft, waardoor deze nauwelijks onderhouden worden, zal het andere bedrijf elke dag klanten toevoegen, wijzigen of verwijderen. Waar het ene bedrijf een vaste groep producten heeft, zal een ander bedrijf bijna elke week de producten moeten onderhouden. Maar het gaat hier om data die door de gebruikers van de applicatie zelden ingevoerd worden. Mocht er zich een probleem voordoen, is dat zeker lastig, maar een probleem in deze groep zal niet snel blokkerend zijn voor het gebruik van de applicatie.

De systeemmanagementdata met regelmatig onderhoud
Een systeembeheerder, applicatiebeheerder of iemand anders in een soortgelijke functie kan vaak data invoeren, waar andere gebruikers niet zomaar bij kunnen. Hierbij gaat het om zaken als modules, parameters, instellingen en gebruikersrechten. Hoewel ook hier het onderscheid tussen regelmatig en incidenteel van belang is, liggen de periodes wel anders. De data met regelmatig onderhoud in deze groep, kan rustig een keer in de paar maanden zijn. Het is data, die gebruikt wordt om de processen te optimaliseren. Of data die gebruikt wordt om een bedrijf te laten groeien of inkrimpen. Of misschien data, die gebruikt wordt om processen aan de wensen van klanten of andere belangrijke partijen aan de passen. Denk hierbij aan de velden, die je op je scherm ziet. Dit kan voor iedereen slechts eenmalig ingesteld worden. Maar er kan ook behoefte zijn om hierin flexibel te zijn, zodat het scherm niet het werkproces bepaald, maar het werkproces het scherm. En je regelmatig kan kijken of de huidige indeling nog naar tevredenheid is.

De systeemmanagementdata met incidenteel onderhoud
In de meeste gevallen is dit data die na installatie eenmaal wordt ingevoerd en daarna (bijna) nooit meer wordt aangepast. De ingevoerde data is de werkelijkheid en daar kan vaak ook niet van afgeweken worden. Bijvoorbeeld door regels, wetten of voorschriften. Of omdat aanpassingen niet alleen vraagt om een aanpassing in data, maar ook vraagt om een hele andere werkwijze of proces. Of men besluit natuurlijk gewoon dat de huidige situatie voldoet, waardoor er geen behoefte is aan aanpassing. Een typisch voorbeeld hiervan is de modules, die in een applicatie staan ingesteld. Dit wordt vooral bij installatie bepaald en zal daarna nauwelijks meer wijzigen.

Bepaal de data

De gebruikersdata met regelmatig onderhoud
Het onderhouden van deze data is zo belangrijk, dat het verstandig is weinig gebruik te maken van testdata in de database. Juist om zoveel mogelijk varianten in onderhoud te testen, maak je de data zoveel mogelijk keer op keer opnieuw aan. Gebruik makend van je kennis, ervaring of testtechnieken kan je bepalen wat er nodig is. Om tijd te besparen bij handmatig testen of om een automatische test niet te lang te maken, kan het toch verstandig zijn om wat data beschikbaar te hebben. Deze data is dan het gevolg van opgestelde testcases en kan dan ook volgens deze criteria in de database worden opgenomen.

De gebruikersdata met incidenteel onderhoud
Omdat het niet altijd belangrijk is dit in de test mee te nemen, is het wel verstandig hiervoor een goede set in je database te krijgen. Wat hiervoor van belang is, is dat je weet welke data effect heeft op de andere gebruikersdata of hun bijbehorende schermen. Een logische gedachte is een relatie waar instellingen ingevoerd kunnen worden hoe de factuur eruit moet zien. Maar denk ook aan verschillende varianten in namen, zoals wel of geen tussenvoegsels en de keuze tussen Dhr. of Mevr. Als deze belangrijke varianten in je database voorkomen, kan je snel en flexibel testen.

De systeemdata met regelmatig onderhoud
Deze data hoort eigenlijk niet te bepalen hoe de database bepaalt wordt, maar vooral hoeveel testdatabases je eigenlijk tot je beschikking wilt hebben. De redenering rond deze data is eigenlijk gelijk aan de redenering rond gebruikersdata met incidenteel onderhoud. Dus als dit mogelijk is, kies voor verschillende varianten. Maar systeemdata is vaak maar op 1 plek in te stellen, waardoor het niet mogelijk is deze varianten toe te voegen. De varianten zijn echter zo belangrijk, dat je ze uitgebreid mee wil testen, zonder steeds veel tijd aan voorbereiding kwijt te zijn. De meest verstandige keuze is daarom hiervoor meerdere databases te maken. B.v. per belangrijke groep klanten (overheid of particulier) of grootte van de klant (veel of weinig medewerkers). Mocht dit niet mogelijk zijn, zal je geen keus hebben om de voorbereiding toch in je testcases te doen.

De systeemdata met weinig onderhoud
Hier gaat het vooral om het neerzetten van een goede basis. Belangrijke variaties in deze instellingen, zoals de keuze of een veld wel of niet verplicht is, moeten worden opgevangen als aanpassingen/voorbereidingen in je testcases. Maar de basis moet zoveel mogelijk voldoen aan de instellingen van zoveel mogelijk klanten. Noem het de database van de "gemiddelde klant". De instellingen, die het meest gebruikt worden. De waardes, die het meest ingevoerd worden. Dit zorgt ervoor dat, als het werkt, de kans ook het grootste is dat het werkt voor het grootste deel van je klanten.

Het vervolg

Besef dat dit onderwerp altijd aandacht blijft vereisen. Je klanten veranderen, je applicatie verandert, je bedrijf verandert. Dit is dan ook geen eenmalige actie, waarna je er nooit meer bij stil hoeft te staan. Als je je testen uitvoert, blijf dan regelmatig stilstaan of je data nog voldoet. Als de applicatie wordt uitgebreid of aangepast, kijk of de data in de huidige database nog steeds alle groepen goed afdekt. En besef ook dat je de eerste keer vergissingen kan maken, hoe zeer je ook je best doet. Blijf hier aandacht aan besteden en blijf er goed over nadenken. Zodat jouw testdata in de database je optimaal blijven ondersteunen bij je testen.

Handmatig regressietesten in een Scrumtraject - Is daar wel tijd voor?

Handmatig regressietesten is waardevol, maar tijdsintensief. En als je kijkt naar wat regressietesten inhoudt, wordt het nog veel tijdsintensiever. Waar je je bij gewone functionele test kan concentreren op datgene wat is aangepast of toegevoegd, kijk je bij regressietesten of dat deel wat juist niet aangepast zou moeten zijn, ook inderdaad niet aangepast is. En het deel wat niet aangepast is, is eigenlijk altijd veel groter dan het deel wat aangepast is. Dus het niet aangepaste deel handmatig testen is een zeer tijdsintensieve klus.

En dan heb je Scrum, met korte sprints. Sprints, waarin de tijd dus al beperkt is. Bij een sprint van twee weken heeft een regressietest van twee dagen een flinke impact.Maar als je alles wil testen in een grote applicatie, is twee dagen zelfs vaak nog te weinig. Niet voor niets wordt vaak gezegd dat handmatig regressietesten en Scrum gewoon niet samengaan. Je hebt de tijd er niet voor. Dus heb je meerdere opties: de regressietest overslaan en gokken dat de kwaliteit toch goed is, de oplevering uitstellen tot een sprint waarin je een hele lange regressietest plant of natuurlijk de regressietest automatiseren.

Waarom zou je hierover nadenken?

Aan iedereen, die altijd de volledige regressietest handmatig uitvoert, zou ik het volgende willen vragen: reken uit hoeveel uren je aan de regressietest besteed hebt. En kijk daarna naar de bugs die je hebt gevonden. Als deze bugs nu via de helpdesk of via de klant binnen zouden komen, hoeveel uur zou je er dan aan mogen besteden? Een validatiefout is zeker belangrijk, maar als je 8 uur nodig zou hebben om hem op te lossen, zou dat mogen? Waarschijnlijk zou er vaak gezegd worden: als het meer dan 4 uur is, dan kunnen we onze tijd beter besteden. Doe is een schatting van de tijd, die je aan het oplossen van de gevonden bugs zou mogen besteden. En vergelijk dit aantal uren met de tijd, die de regressietest heeft gekost. Als de tijd voor de regressietest lager is of ongeveer even hoog, dan moet je vooral zo door blijven gaan. Als de tijd overduidelijk hoger is, vraag je dan het volgende af: als ik deze tijd niet mag besteden aan het oplossen, waarom zou ik die tijd dan wel willen besteden aan het vinden van de bugs?

En dan de vraag voor de groep, die de regressietest maar overslaat: hoeveel tijd kost het eigenlijk om de regessietest niet te doen? Hoe vaak wordt er een bug door de klant gemeld, die je met een regressietest had kunnen voorkomen? Hoeveel tijd kost het om deze bug te analyseren en en om de bug met de klant te bespreken? Hoeveel tijd is het team als geheel kwijt met klachten van klanten over de kwaliteit in het algemeen? Hoeveel tijd zou je besparen als je zelf de bug zou ontdekken en de bug niet van een klant af hoeft te komen? Zou regressietesten dan uiteindelijk geen tijd besparen?

Maar hoe moet je dan handmatig regressietesten?

Binnen het testen is risk based testing vrij normaal. Je kijkt naar testsoorten, dekkingsgraden, etc. En mede op basis van de kans op een fout en de gevolgen als de fout optreedt, bepaal je hoever je gaat met je testen. Waarom zou je zo'n soortgelijke techniek niet bij regressietesten toepassen?

Er zijn onderdelen, die altijd moeten werken. Die onderdelen test je daarom altijd met een regressietest. Maar vaak geldt wel voor regressietesten: als het fout gaat, gaat het vaak altijd fout. Daar bedoel ik mee: als een knop eerst werkte, is bij de regressietest de kans groot dat de knop nu altijd werkt of altijd niet werkt. De kans dat de knop soms wel en soms niet werkt, is meestal niet zo groot. Dus een groffe handmatige regressietest, waarbij je alle belangrijke functies 1 keer raakt, kan met minder tijd al een flinke vermindering in risico opleveren.

Wanneer een knop toch plotseling soms wel en soms niet werkt, is er vaak sprake van enig raakvlak met een uitgevoerde aanpassing. De knop was bijvoorbeeld in hetzelfde scherm als de aanpassing. Of de algemene functionaliteit voor het actief en inactief maken van elementen is aangepast. Of het scherm voorafgaande aan de scherm met de knop is aangepast. Stel dat er dus een aanpassing in een scherm is geweest. Dan kan het zeer verstandig zijn de regressietest voor dit scherm wel uitgebreider te doen. Het kan ook verstandig zijn om een werkproces, waar dit scherm een onderdeel van is, wat uitgebreider te regressietesten. Overleg eventueel met het team en de productowner hoe ver je wil gaan? Hoe groot is het risico dat de aanpassing iets onverwachts heeft geraakt? Welke onderdelen of processen hebben het grootste risico op een fout? En hoe ernstig is dat?

Durf te beginnen

Risk based regressietesten is makkelijker beschreven, dan uitgevoerd. Maar durf te beginnen. Als je nu in een sprint geen regressietesten doet, heb je weinig te verliezen. Al begin je maar met de story's, waar je zelf een groot risico ziet op het veroorzaken van onverwachtse bugs. Al begin je maar met het grof regressietesten van de drie belangrijkste schermen in je applicatie of je belangrijkste proces. Al begin je maar met 2 uur per sprint. Probeer het uit, zeg voor ongeveer drie sprints, kijk of het bevalt en kijk wat het resultaat is. Bevalt het, breidt verder uit. Bevalt het niet, breng het terug. De hoeveelheid regressietesten, dat nuttig is, verschilt per bedrijf, per team, per applicatie. Dus dat zal je zelf moeten uitvinden. Maar als je het lukt, maak je wel een flinke kwaliteitssprong en wordt je als team een stuk flexibeler.

Testverbetering - Maak het meer Agile

Dat Agile een zeer goede manier van werken is voor het bouwen of onderhouden van applicaties, is iets wat langzaamaan steeds meer wordt geloofd. Men beseft steeds meer dat het verstandig snel een resultaat op te leveren, zodat deze voor de klant veel sneller een positief effect heeft en geëvalueerd kan worden. Dat, wanneer je het belangrijkste eerst bouwt, je het belangrijkste resultaat ook het eerst kan inzetten. En het belangrijkste bepaal je niet voor de klant, maar met de klant.

Vele bedrijven hebben ook regelmatig een gefaald verbeterproces achter de rug. In de testwereld gaan bijvoorbeeld vele verhalen van gefaalde testautomatiseringsprojecten. Maar ook testers, die worstelen om van T-Map waterval naar een Agile manier van testen te gaan. Exploritory testing, dat in de praktijk betekend dat iedereen maar wat doet. Een achterstand in regressietesten, in wat voor vorm dan ook, omdat de kennis van het product niet voldoende is om ook maar te starten. Een belangrijk aspect voor het falen "Ik heb geen tijd" wil ik even buiten deze blog laten. Als je de tijd wel krijgt, wat dan?

Ondanks de waardering voor Agile, zijn verbeterprocessen meestal nog heel erg waterval. Een, twee, maximaal drie mensen gaan samen als team het hele verbeterproces op papier uitwerken. Of een geheel automatiseringsproject wordt gebouwd door een of twee experts. Deze personen zijn vaak ingehuurd en/of deel van het management. Soms, als je gelukt hebt, aangevuld met iemand uit de praktijk van het bedrijf. Het contact met de mensen, die werkelijk moeten gaan werken met de verbeteringen, is zeer beperkt. Zo niet volledig afwezig. Als het traject volledig is uitgedacht of de automatisering volledig is gebouwd, wordt het met een grote big bang gestart. Vaak wordt in één keer een grote groep wijzigingen doorgevoerd. En de automatisering wordt in één keer in productie gezet. Dan zijn de experts klaar. Soms is er nog een beetje tijd voor de eerste begeleiding. Maar al snel gaan de externe experts door naar een andere klus en de interne experts weer door naar een ander project of volledig terug naar hun dagelijkse werk.

Hoewel de testers en eventueel ontwikkelaars weinig keus hebben, zie ik ze in dit proces wel als de klanten. Zij zijn, hoe vrijwillig of onvrijwillig ook, de personen die de verbeteringen afnemen. Die ermee moeten werken. En met grote regelmaat zijn zij ontevreden. Het fantastisch bedachte automatiseringsproduct kunnen ze niet onderhouden. Er wordt van de gevraagd om hun oude gewoontes weg te gooien, voordat de nieuwe zich bewezen hebben. Evalueren is vaak geen optie, net zo min zijn aanpassingen bespreekbaar. Want het project is eigenlijk al afgerond. Wat laatste klusjes kan misschien nog, maar verder houdt het op.

Als we het niet meer vreemd vinden dat waterval automatiseringsprojecten falen? Waarom zijn we dan nog steeds verbaasd dat waterval verbeterprojecten falen? En waarom zoeken we in de eerst situatie de oorzaak vaak bij de leverancier en in de tweede situatie vaak bij de "klant"?

Hoe moet het dan?

Er zijn drie belangrijke principes, die ik aanhoud, ongeacht of ik test of verbeter:

• Het belangrijkste moet het eerst
• Er moet zo snel mogelijk resultaat zijn
• Er moet draagvlak zijn

 Het belangrijkste moet eerst

Waar dit eigenlijk op neer komt is dat je een backlog maakt. Een lijst met problemen en/of een lijst met zaken die geautomatiseerd moeten worden, geprioriteerd op belangrijkheid. Een goede backlog is van groot belang. Daarom is het verstandig om juist hier al uitgebreid met de "klant" te praten. Welke problemen zien zij? Wat willen zij bereiken met automatisering? Is er eerder een project geweest, dat faalde? En zo ja, waarom denken zij dat het faalde?

Als in de backlog de belangrijkste problemen van de "klant" niet hoog staan, is de kans groot dat je project faalt. Ten eerste, omdat je "klant" niet zal geloven dat het gaat werken. Hun grootste problemen worden namelijk niet opgelost. Ten tweede, omdat je "klant" kennis en ervaring heeft, die jij mist. Deze zomaar negeren, leidt meestal niet tot een betere oplossing.

Hier is wel een groot verschil met verbeteringen op organisatie niveau en testverbeteringen. Bij grote verbetertrajecten geldt vaak het argument "Ik kan toch niet iedereen betrekken". Maar als je het hebt over testverbeteringen, gaat het vaak niet over groepen testers van 30 man of meer. Iedereen erbij betrekken, of anders minimaal iedereen erbij betrekken die wil, is daarom eigenlijk bijna altijd wel een optie.

Er moet zo snel mogelijk resultaat zijn

Zo snel mogelijk resultaat is een moeilijke stap en te uitgebreid om hier tot in detail te bespreken. Er zijn echter wel twee zaken, die je moet loslaten, voor dit een echte optie wordt. Ten eerste moet je er niet naar streven het project zo snel mogelijk af te ronden. Dit leidt vaak tot een situatie waarin je met zo weinig mogelijk mensen en overleggen probeert om zo veel mogelijk zo snel mogelijk te bedenken, schrijven en programmeren. En het snelst werk je nu eenmaal in je eentje, in een kamer, met de deur op slot, waar je alles achter elkaar kan doen. Als het klaar is, kom je dan de kamer weer uit. En is het zoveelste waterval project afgerond.

Ten tweede  moet je de gedachte loslaten dat invoering pas zinvol is, als alles is bedacht en afgerond. Als je de belangrijkste testen heb geautomatiseerd, kunnen deze al meteen hun waarde bereiken. Als je voor de belangrijkste problemen een oplossing hebt bedacht, dan kan dit je "klant" al flink helpen. Zelfs als de rest nog in de pijplijn zit. Je kan nog niet alles automatisch testen en niet al je problemen zijn opgelost. Maar alle kleine beetjes helpen.

Er moet draagvlak zijn

Als er draagvlak is voor de verbeteringen, dan is men bereid zich daarvoor ook in te zetten. En om de verbeteringen echt een kans te geven. Wanneer je bovenstaande voor elkaar hebt gekregen, dan het je op twee punten vaak al hulp voor draagvlak bij de "klant": hun belangrijkste problemen worden snel opgelost en ze zien dat het project wat oplevert. Door de eerdere oplevering, kan je je "klant" nu ook betrekken bij evaluaties en verbeteringen. Het project loopt nog, dus als er echt iets is, dan kan dat in de backlog worden opgenomen. Als het belangrijker is dan een stukje "nieuwbouw", dan pak je het dus ook eerder op dan de "nieuwbouw".

Maar er is nog een belangrijke manier van werken om het draagvlak te vergroten: maak niet alle keuzes in je eentje of met je team. Draagvlak is vaak te herkennen, wanneer men niet meer spreekt over "hun project", maar "ons project". En één van de eenvoudigste manieren om van "hun" naar "ons" te gaan is: laat ze hun eigen bijdrage aan het project leveren. Kies hiervoor momenten, waarin de keuzes niet gaan tussen "goed" of "slecht". De mogelijke opties leiden altijd tot een goede weg, alleen de ene wat beter dan de ander. Hierbij is wel belangrijk: je moet bereid zijn om de slechtere keuze te accepteren. Mijn ervaring is: een slechtere oplossing met draagvlak heeft een beter effect dan een betere oplossing zonder draagvlak. Omdat in het tweede geval de inzet, het vertrouwen en het geloof in de oplossing zullen ontbreken. Wat regelmatig zorgt voor een "self fulfilling profecy".

Nee, dit is niet alleen een techniek om iedereen blij te houden. Je resultaat zal er ook flink beter van worden. De verbeteringen zijn vaak op initiatief van een manager, scrummaster, testcoordinator of senior tester. En met grote regelmaat ook op initiatief van iemand die vrij nieuw in het bedrijf is. Hoe veel deze personen ook zien, ze zien zeker niet alles. Ze weten niet alles, ze horen niet alles. Hoe is het om als junior tester in dit bedrijf te werken? Welke problemen loop je tegenaan als je wil groeien en leren? Grote kans dat je verbetertraject dezelfde problemen gaat ondervinden. Dus waarom zou je een junior tester niet betrekken bij je beslissingen over leer- en overdrachtstrajecten? Bijna elke groep heeft een of meer "vertrouwenspersonen", een persoon waar mensen zeer snel naar toestappen als ze problemen hebben. Zij kennen de organisatie vaak beter dan de officiële managers. Dus waarom zou je ze niet betrekken bij besluiten over informatiebijeenkomsten en andere communicatiemiddelen? Om de meest logische categorie "ze hebben gewoon van hun vakgebeid heel veel kennis, meer dan jij" nu eens niet als eerste te noemen.

Dus...

Verbetertrajecten moeten, net als bouw- en onderhoudstrajecten, het doel hebben de "klant" tevreden te stellen. Daarom wil je ze snel resultaat geven, om te bewijzen dat het werkt en ze de kans te geven zaken te verbeteren. Voor het beste resultaat, doe je het het belangrijkste het eerst. En zorg je voor draagvlak bij je "klant". Het blijft simpeler geschreven, dan gedaan. Maar ook voor deze blog geldt: elke kleine verbetering in je verbeteringstraject kan al helpen. Lukt niet alles in een keer, doe de volgende keer wat meer. En als dit allemaal teveel is, begin gerust alleen met het belangrijkste.

"Dat doen onze gebruikers niet" - Het belang van betrouwbaarheid bij testen

De meeste testers zijn wel voor goed geprioriteerd testen. En dat mag zeker op basis van een goede risico-analyse. En zeker geen onbelangrijk onderdeel van zo'n risico-analyse is: Hoe vaak wordt deze functie op deze manier gebruikt? Veel tijd besteden aan het testen van een functie, die nauwelijks gebruikt wordt, zal vaak onverstandig blijken. En uitgebreid gegevens invoeren, die in werkelijkheid nooit ingevoerd zullen worden, is vaak ook niet het meest nuttig. Wel moet je hierbij stilstaan bij een factor: er is een groot verschil tussen niet testen en minder testen.

Ik heb zelf regelmatig als tester te horen gekregen, als ik een fout vond: "Maar dat doen onze gebruikers niet." Wat inhield dat ik mijn tijd aan het verspillen was. Want hoeveel fouten ik ook zou vinden, hoe ernstig ze ook zouden zijn, ze zouden toch niet worden opgelost. De gebruiker zal ze niet tegenkomen, dus er zullen geen klachten over komen, dus men kan de tijd wel beter besteden. Ik kon mijn tijd wel beter besteden.

Testen heeft meerdere doelen. Maar het doel om de applicatie te laten werken, zoals je gebruikers dat nodig hebben, is zeker een hele belangrijke. Juist als functionele tester, wil ik eigenlijk altijd een stapje verder gaan. Bij mij is betrouwbaarheid altijd een zeer zwaar meetellende factor. Als een gebruiker plotseling een uitzonderingssituatie invoert, moet de gebruiker niet opeens grote fouten tegengekomen. Als er een nieuwe gebruiker is, die net even anders werkt, moet de applicatie niet opeens onwerkbaar blijken te zijn. En als een nieuwe klant of afdeling ook de applicatie gaat gebruiken, moet deze niet opeens onder je vingertoppen omvallen. Hoe je de applicatie ook gebruikt, er mogen eigenlijk geen grote fouten inzitten. De gebruiker moet altijd op de applicatie kunnen vertrouwen. Dus als iets oplossen of testen de moeite niet waard is, omdat onze gebruikers dat toch niet doen? Dan heb ik liever dat je die functionaliteit of situatie verwijdert, dan dat je er een grote fout in laat zitten.

Het doel van een goede functionele test is het streven naar goede kwaliteit. Kwaliteit, die zo min mogelijk afhankelijk is van nu, van de huidige gebruikers, van de huidige klanten en/of afdelingen. Je testen moeten daarom ook zeker niet alleen gericht zijn op de meest voorkomende situaties. Maar juist ook op de "nu misschien nog niet, maar je weet maar nooit" situaties. Hier hoeft niet 90% van je testtijd in te zitten, maar 0% is te weinig. Een goed evenwicht vinden, dat is en blijft het streven.

Agile Review - Wanneer is het logsich? Wanneer weet iedereen het?

De ouderwetse review van documenten was duidelijk: alles moest erin staan. Als je iets miste, voegde je het toe. Niemand deed het graag, maar er was nauwelijks discussie mogelijk. Toen kwam Agile en daarmee de reden om minder te documenteren. Argumenten die vroeger bij een review niet van toepassing waren, worden nu opeens belangrijk. Nu hoor ik bij een review vaak argumenten als: "Maar dat is toch logisch?" en "Maar dat weet iedereen toch?". Hoe Agile deze argumenten ook klinken, te vaak heb ik meegemaakt dat juist deze argumenten kunnen leidden tot niet werkende software. Omdat wat de schrijver logisch vond, voor de bouwer onlogisch was. En wat bij de schrijver bekend was, bij de bouwer niet bekend was. Juist binnen Agile is een goede review door een objectief persoon van groot belang. Maar ook een stuk moeilijker. Want wat voor criteria kan je gebruiken om te bepalen wat bekend is en wat niet?

Ervaring van het team

Ervaring van het team is de meest logische om mee te nemen in je review. Wanneer je een team hebt, wat al jaren aan de software werkt, dan kan je rustig van heel veel kennis uitgaan. Standaard berekeningen zullen bekend zijn. En standaard uitzonderingen zullen automatisch worden meegenomen. Zo zal iemand werkend aan verkoop binnen de vervoerssector waarschijnlijk uit zijn hoofd de meeste vervoersabonnementen op kunnen noemen. Met de meest belangrijke kenmerken voor de prijsberekening. Dit vermelden zal dan vaak niet nodig zijn. Heb je echter een team met veel mensen die de software nog maar kort kennen, zal je meer moeten vastleggen. Ze zullen geholpen moeten worden, door alle belangrijke situaties en uitzonderingen te noemen. Want zelf zullen ze er niet zo snel bij stilstaan.

Achtergrond van het team

Je staat er soms niet bij stil hoeveel kennis als Nederlander vanzelfsprekend is. Een postcode heeft vier cijfers en twee letters. Een telefoonnummer bestaat standaard uit 10 cijfers. Volwassenen zijn 18 jaar of ouder. Ouderenkorting is bijna automatisch 65+. In een Nederlands team kan je dit rustig als bekende informatie beschouwen. Maar in een internationaal team, wat steeds vaker voorkomt, zijn dit zaken waar je bij stil moet staan. Is bij iedereen in het team een volwassenen dezelfde groep personen? En worden de invoercontroles bij een adres niet te ruim of juist te krap vastgelegd, als je die niet hebt vastgelegd?

Frequentie van aanpassing

Wat echter zeer regelmatig vergeten wordt, is de frequentie van aanpassing. RFS's en/of story's worden regelmatig door mensen geschreven die dagelijks, en anders zeer regelmatig, te maken hebben met een bepaald scherm, een bepaald rapport of een bepaald proces. Zelfs als dit niet het geval is, heeft de schrijver vaak al weken een bepaald onderdeel bekeken en geanalyseerd. Zijn kennis van dit onderdeel is zo groot, dat wat voor hem logisch is en algemene kennis is geworden, voor anderen zeer onbekend kan zijn. Dit gebeurt dan ook vooral bij onderdelen in de applicatie, die bij bedrijven zeer vaak of zeer intensief gebruikt worden, maar nauwelijks worden aangepast. 

Denk bijvoorbeeld aan het invoeren van uren door medewerkers in het bedrijf. Dit proces zal bij iedereen in het bedrijf zeer bekend zijn. Urenregistratie is echter ook vaak een proces, wat niet zo vaak verandert. Ontwikkelaars hebben misschien al jaren niet meer aan dit onderdeel gewerkt. Dus dan kan het zijn, dat "Voer een extra controle in voor de manager" voor de schrijver automatisch betekend, dat zowel de tweestapscontrole als de driestapscontrole met een stap moet worden uitgebreid. Terwijl de ontwikkelaar niet eens weet dat er ook een driestapscontrole is.

En misschien is er nog meer...

Wat het belangrijkste is bij een review, zeker nu, is dat je de lezers kent. Dat je hun kennisniveau en hun achtergrond kent. Dat je weet hoe ze werken en bij voorkeur hoe ze lezen. Als het even kan, weet je ook precies hetzelfde van de schrijver. Zodat je ook de verschillen weet tussen de kennis van de lezer en de kennis van de schrijver.

Juist het verschil in kennis tussen lezer en schrijver wordt steeds belangrijker, wanneer je niet meer alles tot in de puntjes vastlegt. Wat voor verschillen dit ook zijn. Het maakt de review misschien een stuk moeilijker. Maar tegelijkertijd ook een stuk uitdagender.