Tester, kom uit je kreukelzone als je nog watervalt of kom uit je testautomatiseringstechniek. Vooral als je wel software test, maar weinig focus hebt op de toegevoegde waarde voor de business.
Er gaapt een diepe kloof tussen echte gebruikers en IT, deze kloof moet een tester niet vergroten. Waar en wanneer moet jij als tester je toegevoegde waarde leveren? Welke acties kan jij uitvoeren? Lees hieronder wat je hieraan kan doen!
Op basis van twee verschillende ervaringen in twee onvergelijkbare omgevingen zien wij overeenkomsten in de aanpak en toegevoegde waarde van analyse voor testuitvoering.
Het eerste voorbeeld betreft een gefuseerd ziekenhuis waarin twee afdelingen samen verder moeten in één administratie, waarbij een conversie uitgevoerd moet worden. Het tweede voorbeeld komt uit de financiële wereld, waarin een oud maatwerkpakket wordt vervangen door een standaardpakket in de cloud.
In een traject, of dat nu een product increment, sprint, epic of project is, is het van belang dat iedereen hetzelfde doel en de weg er naar toe voor ogen heeft. Zeker in trajecten met een aantal interne en externe belanghebbenden is dit nogal eens lastig. Als daar ook verschillen in kennis, ervaringen en belangen een rol spelen, voegt dit ook extra complexiteit toe. Dan wordt het samen vaststellen van het doel eens zo belangrijk. Dit kan bijvoorbeeld in een pressure cooker sessie.
Een testexpert kan hierin een begeleidende rol spelen door verschillende partijen samen te brengen. Hij kan regie voeren zonder doel en kwaliteit uit het oog te verliezen. Als de belanghebbenden het eens zijn over het doel, kan gezamenlijk bekeken worden waar we nu staan en wat de weg wordt om het doel te bereiken.
Bijvoorbeeld, als doel “het zorgen dat klantverzoeken correct verwerkt worden in het beheersysteem en de klant geïnformeerd wordt”. Daarbij moeten generiek voor klantverzoeken afspraken gemaakt worden over hoe en waar het verzoek geregistreerd en verwerkt wordt.
Dus hoe komt het klantverzoek in het beheersysteem, hoe ziet de medewerker dit in het workflow systeem en hoe integreert dit met het documentmanagementsysteem en documentoutput systeem. Dit leidt tot een interactiepatroon of blauwdruk.
We hebben de blauwdruk, maar nu het specifieke klantverzoek, bijvoorbeeld ‘wijzigen rekeningnummer’. Op basis van een inkomend bericht ziet de medewerker in de werkbak, of workflow, dat hij de taak ‘wijzigen rekeningnummer’ moet uitvoeren. De klant krijgt hiervan een bevestiging. Als tester heb je hier de rol om de acceptatie- of succescriteria uit te vragen. En zo kan per processtap, user story of use case de acceptatiecriteria helder en meetbaar gemaakt worden. Zo nodig kan je dit prioriteren. Dit is een referentie voor je testresultaat: is het goed, fout of iets er tussenin? Vaak ten onrechte blijken acceptatiecriteria ondergeschoven kindjes te zijn. Ze verklaren de eisen of requirements en voegen het acceptabele en verwachte resultaat toe. Daarnaast leiden ze tot meer inzicht in de requirements.
Bij een conversie is dit niet veel anders. Ook daar moeten de neuzen dezelfde kant op en culturele verschillen onderkend worden.
Ook moeten acceptatiecriteria afgeleid worden van de eisen of requirements. Hierbij zitten business en IT samen met de testexpert. Als tester zal je kritisch moeten blijven of requirements en criteria helder en haalbaar en gehaald zijn.
Als doel, aanpak, requirements en acceptatiecriteria helder zijn, dan kan de testexpert een leidende rol spelen in de risicoanalyse. Niet alleen de technische risico’s en testrisico’s, dus in het traditionele domein, maar ook in de implementatie, organisatorische risico’s. Als het technische gereed is, is de organisatie dan ook klaar voor gebruik? Kan de organisatie de verandering aan en opvangen? Zeker na een fusie en conversie is het van belang aandacht aan deze risico’s te besteden.
Testexperts John Peter Ram en Ard Vialle
Meestal moet een proces of migratie meerdere stappen doorlopen voordat het eindpunt bereikt is, het proces afgerond of de migratie geslaagd is. Het valt aan te bevelen om voor de start van de realisatie van de oplossing in een virtuele ketentest te gaan “droog oefenen”. Voordeel hiervan is dat de gehele keten, dan in mensen en niet in software, leren samenwerken alsof ze software zijn. Testscenario’s, nieuwe inzichten, begrip en issues zullen het resultaat zijn. Nieuwe inzichten en issues kunnen voortschrijdend inzicht en bevindingen later in het traject voorkomen.
Dus tester, ga voor je gaat testen kijken of je aan het begin kan borgen dat een ieder hetzelfde doel en aanpak voor ogen heeft om vervolgens de acceptatiecriteria helder te krijgen. Vervolgens kan je als tester focussen op risico’s en een virtuele (keten)test. Dan ben je er klaar voor om je testcases voor te bereiden, te automatiseren als je dat wilt en ze uit te voeren.
Ard Vialle en John Peter Ram
