Blockchain Testing: Revival of the Test Technique!

Can we approach Blockchain testing as if it were ‘normal’ Agile testing? Only if Blockchain development can be considered as ‘normal’ Agile development. And the answer is: “No, it cannot!”.

The bigger part of any blockchain development will be ‘business as usual’: designing user interaction, paying attention to functionality, security, performance, networking and so forth. But every blockchain solution also addresses persistency of immutable and valuable assets. These assets often are subject to business rules in a smart contract. How do you test ‘immutability’? How thoroughly do you test a smart contract? These are some of the questions that pop up when you start thinking about testing a blockchain solution.

There is a nice disaccord between the course of present-day test practices, that are rooted in Agile principles and the essence of a Blockchain solution. Agile engages short, iterative development cycles with just-enough-testing, whereas blockchain development requires thorough testing of the assets and smart contracts in the blockchain. Once in, they cannot be altered anymore!

Most of the Blockchain key concepts can be developed and tested in the usual way, but smart contracts are the exception. We cannot accept errors in that code. Already we’ve seen too many examples of failing smart contracts, costing up to tens of millions of Bitcoins or Ether. But didn’t we always insist that bug-free software is a Utopia, so we should practice risk-based testing and prepare for the worst? Isn’t Agile development an answer to our inherently flawed software development practice!? Short feedback cycles that allow for immediate recovery. So, what are we to do when Agile isn’t the answer in this respect?

The answer lies in the past, in risk-based testing principles. From a testing perspective, smart contracts qualify as ‘high risk’ components in a Blockchain solution. Depending on the nature of the implemented business rules we can rely on good old Test Design Techniques.

Warning: the following sections contain large amounts of old-school test jargon. If you’re not a tester by profession, just skip it and fast forward to the final section with conclusions!

 When the smart contract implements process-flow-like business rules, then let’s bring in the process cycle test technique and apply a test depth beyond the usual ‘2’, let’s go for 3, 4, 5 or even higher. Go as deep as you seem fit.

When the business rules implement decisions, then go beyond the good old MCDC (Modified Condition Decision Coverage) and apply MCC (Multiple Condition Coverage).

When a data-centered approach is followed, then accept that pairwise testing won’t do the trick and freshen up your orthogonal array testing for multimode faults, with ‘n’ having the value 3, 4, 5 or even higher.

One thing does not change: quality cannot be an afterthought, it needs to pro-actively built-in, practicing ‘value by design’ principles. The better part of a blockchain solution can and should be built and tested as ’any other business solution’, following current Agile principles. But the quality requirements for smart contracts are such that stricter, more formal test practices should be applied. And these more formal test practices are rooted in the well-formulated test techniques from the good old waterfall development days!