April 23, 2018

Blockchain Testing: Revival of the Test Technique!

BY :     April 23, 2018

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!

Ben Visser

About

Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing. More on Ben.

More on Ben Visser.

Related Posts

Your email address will not be published. Required fields are marked *

1 + 7 =


  1. Harry · April 24, 2018 Reply

    Hi Ben,
    Beautiful peace about Testing. Thanks for that. I know you are a Real test expert. But sometimes the best solution is not in the detecting part of the problem. For This I should recommend formal programming. To be sure that the software is bug Free. The Testing should only proof the correct software.
    Be well.
    Harry

*Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group