Category Archives: IT

Blockchain and Elections

Recently Donald Trump stated he lost the popular vote in the USA 2016 presidential elections due to the enormous scale of fraud with unregistered voters and multiple registered voters. He proposed improvements that would make the voting process more reliable. By introducing a voter identification (a means to prove that the person is rightfully eligible to vote) and additional measures the process of the allowance of voters should become more trustworthy.

In the 2018 local municipal elections in Amsterdam, one of the  participating political parties, Forum Voor Democratie, raised  questions about the accuracy in which the citizens votes were counted. As they went to inspect a site where the voting of counts was in progress, they were shocked by what they witnessed.

These stories of voter/ voting irregularities and fraud regularly appear in the media. As the examples above illustrate, they are not limited to countries with a questionable reputation in respect to the democratic and election process. A potential improvement could be introducing a blockchain ledger as part of the election process. A blockchain public ledger should contribute to a more fair, transparant way of voting and casting electronic ballots and this would strengthen the democratic process. There is no centralised authority responsible for determining what is true or what is false because multiple distributed parties come to consensus. The result of this consensus (in our case verified and approved votes)  is added to the ledger and is immutable (there is no way of modifying the data once it has been recorded).

In this article I will go shortly how such a voter/voting blockchain ecosystem would look like, without going too deep into the technical details.

The working of the blockchain ledger

The transactions (digital representations of cast ballots from voters) are being recorded on a blockchain ledger. The advantage of such a ledger is that the information of the recorded data is transparant (for everyone to be viewed) yet the votes are securely recorded, non-editable, verified and anonymous (not retraceable to the identity of the voter).

As described earlier the differenties parties come to consensus about the votes and therefor need intensive -decentralised- computer processing power enabling the election process. They should be financially rewarded as an incentive to supply the necessary processing power.

With many cryptocurrencies like Bitcoin and Ethereum these financial rewards come from a process called mining. The situation with an election is rather different than with a system based on payment transfers or smart contracts. Elections only happen once in a while but when they run they cause heavy network load and therefor need intensive computer processing power. The costs associated with network traffic and computer processing power are the digital variant of the organising costs of conventional elections with paper cast ballots.

Because of the special character of elections a mining construction as used by crypto currencies does seem  less useful and not applicable: the ledger will be hit with sudden, incidental ‘spikes’ in time because  the voting process takes time in a limited amount of time (typically a 12-24 hour time frame) and has irregular -long- intervals, depending on a nation’s constitution regarding when the elections take place. Another question who would be the most appropriate party to deliver the blockchain infrastructure. If the government does it is another step to centralisation (we will go deeper into this later). Other (commercial) parties look like a better alternative as they are much more capable of delivering the needed services in a timely and secure manner.

Voters

The voter population varies over time. New voters are added because of citizens that gain legal voting rights (because of age, residence permit after immigration). On the other hand voters die or lose their legal rights to vote (emigration, imprisonment). The only institution that can determine the correct voter base is a -national or local- government. So like conventional voting there has to be a process in place that a/ attends the rightful voters for an upcoming election, b/ gives instructions on the election process and c/ informs the voter about access to the electronic election system in order to use their electronic cast ballot. A/ and b/ will depend on the ways the government communicates with its citizens and are outside the scope of this article. I will concentrate here on c/, the access to the election system.

In the Netherlands the DigiD system acts as the government’s identity management system. It is my estimate that by now every developed nation has a similar identity system. I see no way that an independent source, related to the blockchain ledger will be capable of delivering something comparable. Therefor DigiD could operate as a gateway to the electronic election environment (just like it functions now as a gateway to the Tax and Custom Administration or healthcare institutions). So this is gateway needs to be there in any situation, whether there is a blockchain in place or whether the data is being recorded in a centralised database system.

As described earlier the voters should have access to cast their vote for a limited period of time for a certain election. This is rather critical from a point of processing power. Even within this limited period there will be spikes noticeable within this limited period. Most voters for example will enter the system and cat their vote before or after working hours.

Election, voting and votes

For example we have election X. There is a blockchain ledger in place. The government has provided its citizens the rightful communication about the election X’s rules. Through its identity management system it will grant access to the rightful, granted voters. An election can come into a variety of forms: it could be a simple referendum style, where the voter only has to choose between ‘yes’ or ‘no’ or ‘A’ and ‘B’, it could be a more complex form where one or more candidates has to be chosen from a list or even a combination of referendum and candidate choosing. There will be the need for an application with data and interface specifically designed to support an election event.

As these prerequisites are in place the election X can start. Within the given timeframe the voter logs in to the application and casts his vote/ votes for the election X. This vote takes the technical shape of a transaction where the choice or choices are being recorded to the public ledger taking into account the security and privacy of the voter.

When using a blockchain with a public ledger another effect occurs. Because the transaction information is online and real time available, the need for exit polls is no longer there. The benefit is that when reaching the time limit of the election (the possibility to vote has come to a close), the result of the election is immediately available. However this also means that voters might be influenced by preliminary ranking and adjust their votes accordingly as the information of the voter data is available in real time. This is very different from conventional voting where only a rough indication is available during the election time interval through exit polls.

A blockchain based election can be organised, yet it will difficult to directly abolish the conventional, paper ballot casts directly. There will have to a transition period to let the voters get used to the new system. This transition means however that another issue will arise: how to avoid double voting (one vote electronically, one vote the conventional way). There are different methods to deal with such scenarios but it is something that has to be taken into account.  

Conclusions

Elections using a voting system on the blockchain does little about Trump’s problem. If the government does not have its administration in order than the voter base will remain unreliable. Within the reality of a nation state the government is the only institution able to provide a correct voter data administration. A special ID does more look like introducing a symptom than take away the root cause, but a deeper discussion is outside the scope of this article

A general challenge as we look into the possibilities using a blockchain for elections: a blockchain fares best when there is the smallest need for centralisation or a central institution, the so called principle of MVC (Minimal Viable Centralisation). Decentralisation  is difficult to realise within the setting of a government based election system: the government manages the identities, manages the election procedures and the consequences of the results of elections. So there is little room for decentralisation.

The blockchain itself could be set up and maintained by the government, but that would be another stepping stone towards centralisation. The specific characteristics of using the blockchain (long intervals, but with intensive spikes) would make it more attractive to host such a blockchain with a commercial organisation that can spread the use of the blockchain more efficiently and economically (compare it to commercial parties who deliver cloud based solutions).

An electronic voting system in general (with or without a blockchain) obviously has tremendous benefits over conventional ballot casts. The need for manual counting ballots disappears, although other concerns about security and hacking will become manifest (in which the blockchain could play a favourable role compared to centralised database solutions). The organisation of elections will become so much easier. New forms of elections and voting come into reach and could be the start of a democratic reform process. The old paradigm of representatives of the people deciding for the citizens would become superfluous to a certain extend. The opinion of the citizens could be monitored interactively and immediately.

It looks almost certain that disruptive changes in the election process will be imminent. At least  these changes will allow the voters to vote electronically. The election process however will largely remain centralised because of the enormous influence of the government in almost every part of the process. The use of a blockchain is therefor less obvious within an electronic election system. Yet the strength of using a blockchain would be the accuracy, security and reliability of the registration of votes versus a centralised solution. The manual counting of votes (with all its perks and potential mistakes) disappears, yet the immediate precise publishing and availability of voting results on a blockchain might lead to side effects that were not present in a conventional system, like the immediate availability of voting results.

Challenges of testing when using Scrum

Recently I dived into the merits and challenges of software development (or more generic IT products for that matter) in Agile based settings, in particular using Scrum.  Scrum is one of those methodologies that are part of a wave of Agile based methodologies (LEAN, extreme programming among others) that emerged in the 90’s and in 2001 united for the so called Agile Manifesto. Although Scrum is around for some time, it seems that in recent years Scrum has taken its place in countless organisations as the preferred method of developing software. While studying the Scrum approach I kept a focus on the inclinations for the testing process. I will not go into lengths to give a full description of the Scrum framework in this article but instead focus on possible weaknesses and strengths in relation to the testing process.

A clearly positive aspect of Scrum is that it is not hard to understand. Scrum is defined as a process framework, it does not prescribe an in depth approach on every aspect of the software development. Scrum contains a comprehensive workflow and its own taxonomy (with concepts like SprintIncrementDefinition of Done) is limited. The essential of the Scrum approach could be defined as: transparant software development based on a just-in-time workload, the effort to ensure all involved have a clear picture of the products that will be delivered and the benefit of a team based operation where the group effort is more important than individual success of the team member.

Because the scope of a development iteration (the Sprint) is limited (usually 2 weeks and maximum 4 weeks) the chances of deviation between the mutual understanding of the work to be done and the actual performed work could theoretically not be a too big surprise. Along the path of the Sprint there are mechanisms in place (Daily ScrumSprint Review and Introspective Review) to eliminate risks even further. As -in general- testing activities are based around inventorying and addressing the potential risks, the Scrum approach from a testing perspective is a step in the right direction to deliver quality products.

Yet besides these positive aspects, Scrum also will introduce some trade offs. Before diving into these trade offs, some perspective is needed on how to judge whether something might be considered a weakness or strength when we look at the Scrum process and its intertwining with testing. Over the past decades the most clear contraposition to the Scrum approach of software development has been the waterfall method. The waterfall method implies that there is strict sequential order of activities in the process: it is -for example- uncommon to start coding before the functional and technical requirements are completely set and approved by the stakeholders. An implication of this method is that the time to bring a product to the market might be taking a (too) long time. When the analysis phase within a waterfall project is carried out, internal or external (market) situations might have changed and/or the set requirements have changed. New requirements could be added, old ones could be not longer applicable. In an ever more competitive business world the rise of Agile based methods became new, interesting ways to overcome the waterfall method’s shortcomings. A less positive track record for timely delivered waterfall based projects also contributed to a rise in interest for agile methodologies and Scrum in particular.

Yet for testing purposes the waterfall method unmistakable has its advantages. The well known V-model for testing represents this.

A test strategy could be plotted against the deliverables (or project phases) in the waterfall based project. It gives the test manager time and opportunity to carefully plan and carry out the test strategy, changes never come too abrupt. And if changes come they could be easily adapted into a refined or updated test strategy.

In the Scrum world things work different. The Sprint is short cyclic iteration with a predefined outcome of the Sprint, usually defined as ‘working software’. This approach offers challenges in the testing process. First of all the testing effort has a tendency to become inefficient compared to a waterfall based approach. A test process needs to be in place within each Sprint leading to some inherent overhead (like writing test scripts, setting up test environment, inviting testers for the User Acceptance Test). It is still easier and less time consuming to perform a test process once for a larger number of tasks than numeral times with each Sprint for a specific or small number of tasks. The members of the Development Team (usually between 3 to 9 members) have no specific role within the team and should be able to take on the tasks of another team member. So a team member who develops software should also be able to test the software. This might lead to effects of tunnel vision (approving one’s own work) and a lack of segregation of duties.

The outcome of a Sprint does not necessarily has to be a piece of software that is implemented in the live environment. Preferably it is, but in the Definition of Done it also can be determined that the Scrum Development Team has no role in implementing the software in a live environment. This might be the case when that specific task is to be performed by the IT Operations Department. From a test manager’s perspective this caveat needs attention because it leads to non-addressed risks in the period between the deliverance of the Development Team versus the actual implementation in a live environment.

To overcome these potential trouble with the testing process different ideas have been introduced to deal with potential shortcomings. We will have a look at two of them: Agile Testing Quadrants and Test-Driven Development.

Agile Testing Quadrants

Developed by Brian Marick it places different tests in different quadrants based on their relevance (technology driven versus customer driven, supporting the team versus product critique). An advantage of this visual representation is that the Development Team is aware of the tests that support the quality of their products.

Test automation is an important aspect of trying to solve issues of reducing the testing time it will take from the resources of the Development Team or stakeholders to perform tests. We need to be aware though that test automation is not the ultimate cure for time related issues. Tests have to be coded, so it takes time to complete them before the test automation can facilitate the products that emerge in Quadrant 2. Test ware needs to be maintained as well. For example external factors like an organisation upgrading to a new version of a browser or a fixed security leak need to be taken in account when keeping the test ware up to date.

In Quadrant 4 tests like Performance, Load and Security Testing are positioned. These type of tests require special expertise that is not necessarily available by default within the Development Team. Also the same as for test automation is applicable: the test ware for Performance, Load and Security Tests needs to be initially produced and afterwards actively maintained in order to keep them relevant or simply working in future Sprint iterations/ increments . With Security Tests you might even ask if it is desirable to run these test from within the team due to their delicate nature and from a perspective of segregation of duties.

Test-driven development (TDD) has its origins in extreme programming, an other Agile method. With TDD the developer starts his work by writing the actual test before writing the software code for the product to be delivered. Although TDD has a lot to be said about that goes beyond the scope of the article the clear advantage is that it solves issues raised in previous paragraph. The creation and maintenance of test ware becomes an integral part of the work by the Development Team.

Conclusion
Scrum needs an organisational change of mentality to gain the best results. If only the IT software development is isolated and using Scrum, while other parts of the organisation (Marketing, Finance, Purchase, HR) do not participate, Scrum will be less relevant or even fail to work. But even within the IT department itself the integration of Development Team with the Operations organisation, becomes unavoidable and mandatory to tackle the problem of the possible gap between the Scrum product according to the Definition of Done and the ‘real’ live implementation date.

Test automation is necessary to keep control over the time aspects concerned with testing. But as test automation needs its own level of maintenance it is certainly not the answer to all challenges that the Development Team faces. Especially the tests in Quadrant 4 (Performance, Load, Security) require special expert knowledge that will not always be present by default from the Development Team. If that is not the case it will need to be planned with the required resources and might lead to more planning or product related issues that are difficult to match with the short cyclic iteration of the Sprints.