Correct code can still fail

a flowchart that is correct

When my code fails, its not always the code that has the failure. Sometimes it can be quirks in the framework, programming language, or even the hardware itself. My code will need to deal with these quirks, for the problem to be fixed.

Small values

Lets take the following algorithm:

Flow chart: if value is greater than 100, then do A, else do B.

The algorithm is correct and working as intended, but the foundation has a quirk, that needs to be taken care of.

In Python, JavaScript, and other languages, the calculation “1005/1000*100” gives 100.49999… and not 100.5 because of a floating point error. The difference may seem minimal, but Math.round(1005/1000*100) will give 100 instead of 101, which will make the algorithm above fail.

A quick fix could be to switch the *100 with the /1000, so
1005/1000*100 would become 1005*100/1000.

But what if the 1005 is replaced with a x? Will this fix work for all values of x?

Large numbers

Lets take a very large floating-point number such as 1e17, which is 100.000.000.000.000.000 (1 with 17 zeros)

1e17 + 8 = 1e17 because 8 is to small a number to influence 1e17 in any way! Even 1e17 + 8 + 8 will still give 1e17.

9 on the other hand is large enough: 1e17 + 9 = 1.0000000000000002e+17.

64 is not large enough to influence 1e18, but 65 is.

A million is not large enough to influence 1e22, but 1.048.577 is. 

If you keep on increasing a value by the same number, then there is a point where the value will stop growing, because the number becomes too small to influence the value.

Correct code can still fail

My point here is that we shouldn’t only test our algorithms and our implementation of our algorithms, but also the foundation of the implementation. 

Test Expo 2019

Bartek presenting at Test Expo 2019

Bartek presenting at Test Expo 2019

Today I presented “The Unified Model Of Regression (TUMOR)” at Test Expo 2019.

I would like to thank the people arranging this incredible conference and the people who complimented my presentation.

If anyone is interested, then I will gladly present it in your organization.

Blog Series: Behavior Driven Development in LEAPWORK

bdd i leapwork

Introduction

Concepts such as “Behavior Driven Development (BDD)”, the “Page Object Model”, “Unit-testing”, and “Context Driven Automation” are important for automation:

  • BDD is used to include non-technicians in the software development process.
  • The Page Object Model is used to encapsulate an interface (for example the interactive elements in a web page).
  • Unit-testing is used to secure, that changes made to the units (parts of code), will not introduce any unexpected breaking changes.
  • Context Driven Automation is used to reduce the maintenance cost of automation by 99%.

#BDD, #PageObjectModel #UnitTesting #ContextDrivenAutomation #ContextDrivenTestAutomation #Testing #RPA #LEAPWORK

The blog is written in four chapters, that:

  1. Examines these concepts.
  2. Why are these concepts beneficial to use in LEAPWORK?
  3. How to implement them in LEAPWORK? (with examples).

You can read the chapters here:

Blockchain – explained in 10 min.

blockchain title

What is a blockchain? What is a smart contract? It’s really not that complicated.

#blockchain #smartcontract #bitcoin #ethereum #eos

Bitcoin – a database

Bitcoin can be perceived as a very secure database, containing who have access to which part of the database.

Imagine:

  1. Person A can access a part of the Bitcoin database, with private key 0000…001.
  2. Person B can access a different part of the Bitcoin database, with private key 0000…002.
  3. If A wants to trade with B, then a part of the A’s Bitcoin database can be decrypted with private key 0000…001 and encrypted again with private key 0000…002.

This process can be seen here:

If a person without any Bitcoin wants to buy some Bitcoin, they can generate a new private key (0000…006) and receive access to the Bitcoin database:

blockchain transcation to a new user

Decentralization – peer-to-peer

The Bitcoin database is decentralized and can be compared with peer-to-peer file sharing.

Imagine:

  1. Four people sharing files on a peer-to-peer network.
  2. If one person shares a file.
  3. Another person will download the file (get synced)
  4. Now two persons can download the file from the previous two people. 
peer-to-peer

If a person loses the data, then the data can be restored from the other persons.

The same goes for the Bitcoin database, where persons are replaced by miners:

peer-to-peer as blockchain

It means, that you don’t hold your Bitcoins on your USB, but all the miners do.

You can access your part of the Bitcoin database with your private key. Nobody else can access your part without your private key. This is why the Bitcoin is so secure.

When someone loses their private keys, the part of the Bitcoin database becomes inaccessible (and lost forever).

You could take your own copy of the Bitcoin database on a USB key, but your version would become out of date if it is not connected to the peer-to-peer network. Also, you would need a large USB key, since the size of the Bitcoin database was 197 gigabytes in Q4 2018 and it is growing all the time.

The Bitcoin database could be used to store data but is not used to do so, because it only has 8 transactions per second.

Ethereum & EOS – Smart contracts

Ethereum was the first blockchain to support smart contracts.

Kick-starter works almost like a smart contract, except that it is governed by the Kick-starter company, while a smart contract is governed by it’s blockchain.

Imagine:

  1. A product team wants to create a product.
  2. They put up a “smart” contract on Kick-starter with a money requirement.
  3. Supporters will donate money to the Kick-starter project.
  4. When the money requirement is fulfilled.
  5. Then the product teams produce and deliver the product.
smart contract from kickstarter

It’s the opposite for a blockchain smart contract:

  1. Customers want a product.
  2. They put up a blockchain smart contract with product requirements.
  3. They put money into the smart contract as “finders fee”, when someone fulfills the requirements.
  4. Multiple product teams can try fulfilling the requirements.
  5. When one product team succeeds, they get paid by the smart contract.
smart contract as blockchain

The idea is fantastic, but Ethereum is too slow to be used for anything with only 16 transactions per second.

The EOS blockchain is much faster than Ethereum with 3000 transactions per second, leading the race to reach one million transactions per second.

Limitless possibilities

As is: The police governs peoples driving, by punishing those, who drives to fast, with fines.

To be: A smart contract will govern peoples driving, by rewarding those, who have driven safely for a whole year.

Testing skills will be in demand for writing good smart contracts.

—-

If you want to know the status of blockchain in 2019, then read my SogetiLabs article: https://labs.sogeti.com/status-of-blockchain-in-2019/

Or if you want to know more about something else, then please write a comment.

Avoiding Complexity and Chaos

A model of complexity and predictability

Introduction

Software development (but also the development of Machine Learning and AI) is a combat against chaos and complexity. It is bad enough, when software becomes chaotic and does unexpected things, but it is even worse, when software becomes too complex to be fixed.

#softwareDevelopment #ML #AI #complexity #chaos #testing #functionalTesting #operationalTesting #developmentalTesting

I created a model that illustrates both phenomena, because they need to be dealt with in different ways.

Two examples:

A function that randomly outputs 1’s and 0’s is:

  • simple (because it is easy to understand) and
  • chaotic (because the results are random).

If the function breaks (it’s not random anymore), then it easy to fix, because it is simple.

A chat bot is:

  • complex (because nobody understands its neural configuration) and
  • predictable (because we expect it to give specific answers to specific questions).

If the chat bot breaks (its not giving the expected answers), then it is almost impossible to fix it, because it is so complex. An example of this is Tay, the Microsoft chat bot that became racist.

The model

A model of complexity and predictability

Software that is:

  • Simple and predictable is good
  • Simple but chaotic is usable in for example cryptography.
  • Complex but predictable is not good, but necessary to solve complex problems (like winning Chess and Go). This is where AI and ML should be.
  • Complex and chaotic – very bad. I have seen many IT-projects ending here to die. AI and ML should avoid this.

Measuring predictability and complexity

Predictability can be measured and controlled with functional- and operational-testing.

Complexity can be measured and controlled with developmental-testing. This is a key factor in the development of AI and ML.

To put it short:

  • The predictability measures “if” something is predictable or chaotic.
  • The complexity measures “how difficult something is to understand and therefore fix it”.