Blockchain en de uitdaging voor het testen

| Peter Logtenberg en Manuela Krull-Mancinelli over trends en ontwikkelingen

Hoe gezellig wij het bij Immune-IT ook hebben met elkaar, zo nu en dan kijken wij ook graag naar buiten. Naar trends en ontwikkelingen in IT die zich afspelen net buiten de grenzen van het eigen test-bedrijf. In de reeks: “De blik naar buiten”: Manuela Krull-Mancinelli (Blockchain Entrepeneur en Digital Transformation Manager) en onze eigen Peter Logtenberg (gelouterd testmanager bij Immune-IT) over Blockchain en de uitdaging voor het testen.

“Bitcoin” was tot voor kort de nieuwe technologische ontwikkeling waar iedereen over sprak. Het concept: meerdere computers bepalen bij consensus of een transactie geldig is of niet, was baanbrekend. En fraude was onmogelijk  door het gebruik van encryptie. Opeens waren er geen instituten meer nodig om een financieel systeem overeind te houden.

Inmiddels is de technologie al weer verder. Het protocol achter de munt, de “blockchain” blijkt namelijk ook toepasbaar voor het opslaan van gegevens en contracten. Het kan daar zelfs bewerkingen op uitvoeren, zolang de aanleiding maar in een registratie controleerbaar is. Deze bewerkingen worden gewoonlijk door batchprocessen, medewerkers of de klant zelf gedaan. We spreken dan van “Self Executing Contracts”.

Deze ontwikkeling heeft grote gevolgen voor testers. De testprofessional zal zijn werk anders moeten gaan doen dan nu. Daarvoor zijn een aantal redenen:

  • Een programmeerfout in een Self Executing Contract leidt sneller dan nu tot een testblokkerende bevinding. We kunnen niet meer handmatig ingrijpen binnen het proces.
  • Strikter dan nu zal in de testvoorbereiding aandacht gegeven moeten worden aan het creëren, lezen, updaten  en verwijderen (CRUD) van testdata tijdens de testuitvoering. Testdata kan niet even snel meer worden veranderd. Voor het testen wordt doorgaans gebruik gemaakt van een testnetwerk.
  • Een transactie kan in eerste instantie worden goedgekeurd, maar kan in een opvolgend blok met terugwerkende kracht alsnog worden afgekeurd. Bitcoin hanteert de stelregel om minimaal twee blokken af te wachten voordat je kunt aannemen dat de transactie is goedgekeurd.
  • Autorisatie wie welke gegevens mag inzien of wijzigen wordt nu door de blockchain gedaan waarbij wordt gecontroleerd of de juiste encryptiesleutel wordt aangeleverd. Dit is afhankelijk van de implementatie, de foreign - of de private key. De autorisatielaag in de voorkant-applicatie moet hier goed rekening mee houden. Zeker als er door de OTAP-straat heen, bij oplevering van software, data wordt meegeleverd.
  • Het wordt nog complexer als gegevens uit andere blockchains worden geraadpleegd. Een voorbeeld: Voordat een overlijdensrisicoverzekering mag worden afgesloten, wordt in het geboorteregister gecontroleerd of de betrokkene is geboren en meerderjarig is. In het overlijdensregister moet eerst worden gecontroleerd of de betrokkene wel is overleden voordat mag worden uitgekeerd. In deze situatie is  een hoge mate van regie noodzakelijk. Op dit moment is het echter onduidelijk of de dynamiek van het periodiek definitief maken van een block (de heartbeat), dit soort regie überhaupt toestaat.

Van de andere kant wordt het werk van testers op een aantal punten ook makkelijker. Een aantal testsoorten zijn voor de blockchain zelf niet meer nodig, tenzij het een private blockchain is. In dat laatste geval is het controleren of de architectuur juist is neergezet, belangrijk. Gaan wij er van uit dat er een publieke blockchain wordt gebruikt, dan lijkt men het over eens te zijn dat:

  • Performancetesten een heel andere betekenis krijgen. De performance wordt deels bepaald door de snelheid van het netwerk. Deels wordt de performance bepaald door de accorderingswijze van de transacties. Proof of Work heeft bijvoorbeeld een heel andere verwerkingssnelheid dan Proof of Stake. Testen van de performance van de voorkant-applicatie blijft gelijk.
  • Backup&Restore test niet nodig is, omdat het een Blockchain database is. Data is altijd op meerdere plaatsen beschikbaar en kan bovendien niet gemanipuleerd of verwijderd worden.
  • Failovertest van de ene database naar de andere niet nodig is, omdat de blockchain gedistribueerd is. Wanneer een node in het netwerk uitvalt is er simpelweg minder capaciteit beschikbaar, de database als zodanig blijft in werking.
  • Uitwijktest niet nodig is als de verschillende nodes geografisch verspreid zijn.
  • Securitytest op de database beperkter wordt omdat alle gegevens encrypted worden opgeslagen en alleen met een foreign - of private key kunnen worden gelezen, afhankelijk van de implementatie. De sterkte van de encryptie wordt in de code van de blockchain afgedwongen.

Functioneel testen

Functioneel testen van het Self Executing Contract is natuurlijk altijd noodzakelijk, of het nu een publieke of private blockchain is, net als de applicaties waarmee de gegevens in de blockchain geraadpleegd en gewijzigd kunnen worden. Sommige wijzigingen zullen namelijk altijd handmatig blijven, zoals bijvoorbeeld contractbeëindigingen omdat de klant naar een andere leverancier gaat. Er zijn ook toepassingen die bewust met menselijke tussenkomst gedaan zullen blijven worden om te voorkomen dat iemand bijvoorbeeld onder druk een waardevol object als zijn huis verkoopt.

De uitdagingen bij het functioneel testen van een systeem dat gebruik maakt van blockchains zijn onverkort geldig bij andere testsoorten zoals de Gebruikers Acceptatietest, de Usabilitytest, de Securitytest, en de Productie Acceptatietest van de keten als geheel. De tijd zal leren hoe deze uitdagingen het hoofd geboden kunnen worden.