Testing of smart contracts in the blockchain world
2017 is predicted to be the year that the Blockchain technology moves towards main stream implementation.
To visualize this, let us consider a use case of a credit card processing giant, that facilitates new commerce opportunities for the digital transfer of value by allowing businesses and financial institutions to facilitate transactions on a distributed ledger. In this use case, the distributed digital ledger will be shared within a network of computers held by the participating businesses and financial institutions. The participants in the network will have copies of the existing Blockchain, and approval for any new transaction is subject to the decision of the majority of the participants. The new block is added to the Blockchain once the transaction’s validity is authenticated.
The heart of the Blockchain validation technology is a Smart Contract. A Smart Contract is a set of rules in the form of programmable constructs that are capable of automatically enforcing themselves when pre-defined conditions are met. An example of a pre-condition could state that transactions beyond a certain limit will undergo additional validations.
From a technology standpoint a Smart Contract is an API. It has public functions which might be called by anyone registered on the Blockchain network. However, unlike a traditional API, a Smart Contract cannot call external web APIs.
The reason why testing is very critical is that when a contract is created, it is immutable; once deployed to the Blockchain it stays there forever. If you find a defect in production, a new version of the contract has to be created and deployed. When you deploy a new version of an existing contract, data stored in the previous contract isn’t automatically transferred – you have to manually initialize the new contract with the past data which makes it very cumbersome. Similarly, updating a contract is not possible and neither is rolling back an update; this greatly increasing the complexity of implementation and places a huge responsibility on the quality assurance team to get it right the first time. Three critical steps in testing a smart contract have been defined below; it is crucial to keep these in consideration when testing Blockchain.
Step 1: Validating the methods in a Smart Contract: This is essentially similar to API testing where one would use method validations, boundary value analysis, decision tables, test driven development and behavior driven development techniques.
Step 2: Validating encryption and transmission of Smart Contracts: This refers to the validation of the encrypted Smart contracts sent out to other computers via a distributed network of ledgers (i.e. Distributed Ledgers). Two validation scenarios are possible: facilitated via public permission less Blockchain (you do not need a previous relationship with the ledger) such as bitcoin, the contract is sent out similar to the way that a network update of a bitcoin transaction would occur. This can also be done in a permissioned (recognized by ledger) hybrid distributed ledger platform such as R3.
Step 3: Validating Processing of Smart Contracts: This is the most complicated part. Once the computers in this network of distributed ledgers, in this case financial institutions, receive the executing code(Smart Contract api), they each come to an individual agreement on the code execution.The network would then update the distributed ledgers to record the execution of the contract and ending with monitoring for compliance within the terms of the smart contract. In this type of system, execution is no longer in the hands of a single party. Validation is a very manual intensive process requiring a great deal of understanding of the business process of the participating financial institutions behind the Smart Contract .Other things that will come into play are regulatory tests, performance tests and business impacts of downstream systems.
Smart Contract testing is complicated and in the nascent stage; forward-thinking QA teams need to future-proof by building specialized capabilities for validating Smart Contracts. Testers will need to learn API skills, regulatory, security, data and business process domain skills. Those who can bridge the gap between business, domain and technology will be highly sought after in the near future.