QA for blockchain: Why I break things before someone else does

When things go wrong with blockchain applications, the situation can get really ugly, really fast.

In the past year, it’s estimated that $500 million has been lost due to bad code, and around half of that figure involved Ethereum. The most notorious case was the Parity bug which led to $168 million of ether being rendered permanently inaccessible, though there have been plenty of smaller incidents where inexperienced or inattentive developers have been caught out.

At Dispatch Labs, we’re taking these past calamities on other platforms to heart, even before the launch of our own token. I know I would be quite upset if all of a sudden my hard earned tokens would just disappear into ether (no pun intended) because of a technical issue. That’s why I joined the team earlier this month as Quality Assurance Director, at the invitation of our chief technology officer, Zane Witherspoon, who knew me from our collaboration on previous projects.

My brother Dmitri, an experienced QA engineer himself at places like Visa, Tibco, and Intuit, has also joined the team. Both of us previously worked together on other projects and have created an open source test automation framework called RedwoodHQ. With more than 40 years of experience, we’re ramping up this area of our development as a high priority early on.

For me, the blockchain represents a fascinating new technical challenge, even after 20 years specializing in QA, including stints at big corporate shops like IBM and Hitachi as well as various startups. I do find the bedrock principles and methods of QA are still very much the same:

• Build tests based on requirements.
• Automate and execute them.
• Provide risk assessment of the software to the team at any given point of development cycle.

Of course, it’s important to realize that not all bugs in all applications are created equal. If your favorite mobile game didn’t record a correct high score that you just got, it sucks but won’t impact your life.

On the other hand, some bugs can cost people and companies millions of dollars, as happened in 1999 when NASA embarrassingly lost a $125 million Mars orbiter. The reason: One set of programmers working on the project had used metric measurements in their instructions to the craft, another had used English measures.

Some software bugs can even cost lives, as happened with a 1994 helicopter crash in Scotland due to systems error. The tragedy killed 29 people.

At Dispatch, we view what we’re doing as closer to the helicopter or orbiter in importance, than the mobile game scenario. People put their money at risk — sometimes even their life savings — when trading in cryptocurrency. It is our job to ensure that it is fully safe to use our system to conduct their trading.

Being a completely open source project, with a transparent development process, allows for additional layer of QA which typical enterprise level software company can’t match. By engaging our community early on, we can gather their feedback on possible failure points as well as any bugs they might find. To me this makes this project even more interesting since it gives additional point of information to asses the risk.

The various parts of our platform so far, including our Go client, mobile wallet, and other tools, are posted on GitHub. Please do give the software a try, let us know about any issues you experience, or issue a pull request to help us improve the product for everyone.