This is a guest posting by Michael Solomon PhD CISSP PMP CISM.
Blockchain technology is one of the most discussed topics in technical domains today. Many say that blockchain will disrupt a growing number of industries, and we’re already seeing more and more companies begin to adopt this new technology. Disruption is a key term in the blockchain ecosystem: It means that blockchain will change how we do things, including how we test this new class of applications.
By definition, blockchain applications are distributed applications, where part of the code lives with the data as smart contracts. Testing blockchain applications will require not only traditional software testing skills, but also new abilities to address the novel characteristics of this new technology.
Get TestRail FREE for 30 days!
There are lots of resources that explain blockchain technology, so I won’t go over the basics. In simple terms, blockchain technology is a shared ledger that exists on a number of peer computers. The number of ledger copies can become quite large, and there is no central copy or governing authority. Each peer stores a complete copy of the ledger. The only change allowed to a blockchain is to add new blocks, and that can only be done if at least half of the peers in a blockchain environment agree to it.
The takeaway here is that no single entity controls a blockchain application. Also, the blockchain itself is immutable — you can’t change anything that is already on the blockchain. Well, technically, it is possible to change data on the blockchain, but it is extremely difficult and essentially infeasible. The reason is directly related to the cryptographic assurance of integrity built into blockchain technology.
Each block contains a hash value of the previous block, so if you change any block, all subsequent blocks on the blockchain are invalid. To change any data on a blockchain, you would have to recalculate the hash values of every block after the one you changed, then convince more than half of all peers in the blockchain environment that your change is acceptable and correct. That feat in and of itself is difficult, but remember that you also have to do this before any new block is added to the blockchain. In an active environment, such a task becomes next to impossible.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Testing blockchain applications requires extensions to traditional testing tools and techniques. At its core, every blockchain application is a software application, so you’ll need to conduct the same types of test throughout the development process as you would with any other applications. However, when testing blockchain applications, you’ll have to do more.
Blockchain applications are distributed applications. That means they don’t run or store data in a centralized location. The blockchain is distributed to all nodes that participate in the application, and each node is a peer to all other nodes. There is no master node that controls how the application operates.
Because the blockchain environment calls on each peer to agree to additions to the blockchain, your tests will need to validate that the consensus protocol operates properly and keeps every copy of the blockchain in sync. While that is hard enough in a controlled environment, it becomes quite challenging in a peer-to-peer environment in which not all peers are continuously active. Regardless of peer participation, the blockchain integrity must be maintained.
One of the more powerful features of blockchain technology is the ability to store transaction-related application software, called smart contracts, in the blockchain itself. Smart contracts execute automatically based on developer-defined criteria. For instance, the transfer of funds from one account to another can only occur when the two account identities have been authenticated and the source account contains sufficient funds to transfer the requested amount.
Smart contracts make it possible to encapsulate data and actions in a single container. In effect, smart contracts define self-contained objects on a blockchain and ensure that the blockchain governs whether blockchain additions are valid — not external entities.
Testers must be vigilant to thoroughly test smart contracts. You must carefully examine edge cases and unexpected input and conditions. Although these are requirements for general purpose software testing, the stakes are higher for smart contracts. Because smart contracts are part of the blockchain, and the blockchain cannot be changed, smart contract code cannot be changed if bugs are discovered after deployment.
If software defects do propagate into production, the only way to address them would be to release a new version of the smart contract code. However, this can be problematic. Current smart contract code must be able to handle all existing data, as well as any new data. If new smart contract code results in a data format change, care must be taken to delineate the “before change” data with the “after change” data. This is often referred to as a “fork” in the blockchain. This can be a mess, so it is best avoided through thorough testing.
The last main category of special testing for blockchain applications is performance and scalability. Public blockchains can consist of nodes around the world, with wide variances in computing power — a blockchain environment could include Raspberry Pi devices connected to the internet via a slow connection. Testing must include real-time performance assessment to ensure that minimum performance requirements are met.
The blockchain itself can also impact performance and scalability. Blocks in the chain each have fixed maximum sizes. For instance, the bitcoin blockchain has a maximum block size of 1MB. Testing should include assessments of reaching or exceeding the maximum block size. Is your blockchain’s maximum big enough for data growth? What happens when a block exceeds the maximum size?
The length of the blockchain is another area that you’ll need to test. Regardless of the block size, the blockchain will grow. Can your application handle very large blockchains? How often will your application have to start at the beginning of the blockchain to calculate current data values? Can it carry out such operations within performance goals?
Once you have a testing plan in place, you need to carry out the tests in some environment. Most existing blockchain environments provide some ability to deploy applications into test blockchains. If you are deploying a private blockchain, you only need to set up a test environment. If you’re deploying to a public blockchain, you can either test using a supported test environment or deploy to the real world. In either case, there is a cost associated with testing.
Unlike with other applications, miners are required to carry out the complex cryptographic calculations necessary to validate blocks before they are added to the blockchain. They do this for a fee, so even when testing, you’ll have to pay miners to validate blocks when using a public blockchain. Make sure that you explore the cost of testing when planning for tests.
First off, adhere to the overall software testing best practices. Those don’t go away for blockchain applications.
In addition, learn as much as you can about your blockchain environment. If your application is using an established blockchain environment, see what tools are available for testing. For example, if you’re deploying an Ethereum blockchain application, get to know Truffle, a suite of software designed to help develop and test smart contracts. Most blockchain environments have their own sets of tools to help with testing. This article lists more of the common testing tools and digs a little deeper into blockchain testing.
The best way to prepare to test blockchain applications is to learn about what makes blockchain so unique. Then all you really have to do is to apply the skill you already have, and you’ll be ready to take on the new wave of disruptive apps.
Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.
Test Automation – Anywhere, Anytime
Help us improve this page!
What problem are you trying to solve?
By integrating Global App Testing with TestRail, you can launch unscripted and scripted tests and receive results in as little as 15 minutes.
Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.
Organizations need conceptual and QA has crucial strengths to effect that change. Here are three winning action plans to change your QA culture and integrate it with the rest of your SDLC.