Automation is Coming – How Will You Survive?

Original source: https://labs.sogeti.com/automation-is-coming/

How AI will disrupt the developer and IT-architect; and what can they do about it?

You might be in your 20s, 30s, or 40s and surfing on the wave of brand new technology with no fear of “what’s to come”. We know that AI (Artificial Intelligence) with its Machine Learning and Cognitive Automation is surfacing below the deep unknown waters and that they will disrupt the industries within the transport, fast food, and farming sectors. We even know that the disruption will not only influence the blue-collar workers, but almost every job profile is also affected by accountants, lawyers, medical practitioner up to data scientists already in touch with AI. The questions we will treat here are, how will this AI revolution influence software development, and therefore the developer and IT-architect? What should you expect from the upcoming world of the 2020s and how should you prepare for it?

To understand what will happen in the 2020s we need to review what has happened in the last 61 years in the field of AI.

THE HISTORY OF ARTIFICIAL INTELLIGENCE

The first machine learning program and neural networks

The concept of “learning machines” is not new. The first electronic device that was able to learn and recognize patterns [Cor57], was built as early as 1957 by Frank Rosenblatt. The first machine learning prototype was built in 1961 by Leonard Uhr and Charles Vossler [Pat61]. Neural networks have existed for a long time, but their learning required a lot of labeled digital data, which was rare and expensive in the 1960s. In today’s digital world, especially social media deliver huge amounts of labeled date every second. Sensors were also analog and not very precise compared to today’s sensors in phones, smart homes, and cars. This is probably why chess was so interesting to automate because the sensory data input was simple (only 8×8 tiles and 12 types of bricks) but could result in at least 10^120 probable chess games [Che], which is larger than the number of atoms in the known observable universe [Uni].

The chess game itself was simple enough to code but winning a chess game was not. It was obvious that neural networks had a potential, but no neural network at the time was able to beat a human chess champion.

The 2000s

Something happened in the 2000s, that made AI move forward and solve problems AI couldn’t solve before. DARPA arranged in 2004 a self-driving car competition: “The DARPA Challenge”. No car managed to complete the course and the longest driven distance was 12 km.

DARPA tried again in 2005 with completely different results: 23 of 24 cars managed to beat the record of 12 km, where 5 of the 24 cars managed to complete the whole course of 212 km. What happened? The incredible improvements of big data, affordable HPC and deep architectures, e.g. digital online maps became available, image analysis tools became better, etc.

Deep learning

Software engineers and scientists required fewer data to build e.g. an image recognition algorithm, than a neural network required to learn to recognize images. In the late 2000s enough labeled digital data was available for machine learning software to remake the same image recognition algorithms, that humans already had developed. Deep learning was one of the machine learning methods, that split the learning into multiple layers. The first layer learned to recognize simple forms from pixels. The next layer learned to recognize faces from simple forms. The state of the art is that machines e.g. can diagnose diseases on the basis of images and do so better than corresponding human specialists

Not only did deep learning remake the previous image recognition algorithms, it even improved them. Machines didn’t only recognize items on images but also began to create its own images called “computer dreams” [Ifl]. Machines even began to change summer to winter on existing photos and even change day to night and the other way around [Pix]. The machine learning algorithms were not new, but the new huge datasets gave new possibilities.

WHAT TO EXPECT?

Software development by humans

Software is all about mapping the inputs with the correct outputs to solve specific problems.
A software engineer or a computer scientist could take a complex real-life phenomenon and refine the necessary patterns into an algorithm:

Software development by machines

Most machine learning is only about connecting inputs with outputs, but machine learning based on evolutionary algorithms are able to improve itself by putting pieces of codes together into completely new algorithms. This type of evolutionary development is a lot faster than traditional human software development.

In 1997 humans managed to develop Deep Blue, the first computer that was able to win a chess game against a human world champion. It took 20 years, before AlphaGo in 2017 was able to win the board game Go against the best player in the world.

AlphaGo Zero (a new version of AlphaGo) was developed based on reinforcement learning. AlphaGo Zero learned itself to play Go from scratch in only 4 hours, after which it was able to beat the original AlphaGo 100 times in a row [Dep].

A machine was able to create a better algorithm in only 4 hours compared to the 20 years the multiple developers and architects needed. Developers and architects will be disrupted, but there will still be a need for humans.

It might not be fair to compare the human development time to only training/learning time of the machine since it also took some time to develop the training/learning algorithm. What we have to remember, that the training/learning algorithm can be reused for other projects, while the human development time will not.

The risk in not understanding

Software in the last 70 years has been built on simple algorithms that are understandable by humans (even though they are still difficult for humans to understand). Machine learning software can create a new type of algorithms that are much more complex and impossible for humans to understand. We are much more dependent on our software today than ever before, and not understanding the algorithms behind our software will be a huge risk to take.

The consequences are not dire, when weather-chatbot mistakes the word “tonight” with a city name, as asking the weather-bot “What is the weather tonight?” would only result in a bad answer: “I don’t know ‘tonight’. Try another city or neighborhood.”. Word mistakes such as that would have far worse consequences for a critical healthcare system, especially, if no human was able to fix the problem. Some would say, that these mistakes happen because AI is still in the early stages of development and it is only a question of time before these mistakes won’t happen – but will they?

Complex algorithms are not perfect

Kurt Gödel proved with his incompleteness theorem, that all systems are incomplete, even math. I have simplified Gödel’s proof into:

  1. For a sentence to be true in math, it must be proved.
  2. But what about: “This sentence is unprovable”?
    If this sentence is true, then it can’t be proved and therefore false according to math.

The bad news: Complex algorithms created by machines are also systems and therefore incomplete, imperfect, flawed, and containing unexpected bugs.

The good news: A chess algorithm does not have to win all possible games. It just needs to win more times, than the current world champion. If humans could design a healthcare system as a board game, then machines would find better and better ways to win this game. If humans could design a healthcare system as a board game, then machines would find better and better ways to win this game, just like AlphaGo Zero managed to win the board game Go better than any human could.

Test Driven Reinforcement Learning

In traditional development of machine learning, a dataset is split into training data (80 %) and testing data (20 %). The training data is used to train the machine, while the testing data is used to evaluate how precise a machine is to predict/categorize. Data that reduce the precision is removed from the dataset, while data that increase the precision is added. Building, navigating, and improving the datasets require a data scientist or someone with a lot of mathematical, statistical and technical know-how. This restricts a lot of people from working with machine learning.

Reinforcement Learning is about rewarding and punishing behavior to either reinforce wanted behavior or diminish unwanted behavior. I have built a prototype: A bot that has to follow a target. The bot has 4 cameras (one in each direction) and a leg (so it can move in a direction). The bot would start moving the leg randomly. To reinforce a leg movement a developer could set up a technical test, that measures the distance between the bot and its target. If the distance decreases, the probability of the leg movement would be reinforced, but if the distance increased, then the probability of the leg movement would diminish:

Caption: “Visual example of how my prototype learns and unlearns.”

My prototype is even able to handle changes in the environment, because of constant learning and unlearning. If two cameras switch place, then the bot would unlearn the old camera-movement relations and relearn the new ones.I named this approach TDRL (Test Driven Reinforcement Learning) and is completely different than traditional development of machine learning. Instead of preparing the dataset for a machine, the machine gets access to an unfiltered dataset or environment. The tests will govern the development of the machine and whenever a machine behavior needs to change or be fixed, then a new test case can be written. For example, Microsoft deployed an AI chatbot “Tay”, that became racist within 24 hours. If this was built on TDRL, then this could have been easily fixed by adding a test case that measures the racism level within a sentence. The chatbot would then fix the problem itself, by governing its own sentences and lower the probability of writing something racist.The book “Testing in the digital age” [Tes2018] describes, that we will not only need technical tests (like in the example above: “measuring the distance”), but also ethical and conceptual tests (like measuring mood, empathy, humor, and charm) to improve robots in the roles of a partner, coworker, or assistant. Technical tests will be less complex to design, while the ethical and conceptual test will be more difficult. Ethical and conceptual tests would require domain-specific knowledge. For example, the concept of “health” or “happiness” can be perceived differently: Something that is healthy for me is not necessarily healthy for my children, or the planet’s environment.SummaryHow will this AI revolution influence software development, and therefore the developer and IT-architect?There is no doubt about that the AI revolution will disrupt the IT-industry in the 2020s. Machines will be able to create better and more complex solutions, in less time, than a human developer and architect ever could. Machines will even disrupt the data scientist.What should you expect from the upcoming world of the 2020’s?We already see the need to govern machine learning bots and this need will only be growing. To govern the machines doing software development; developers and architects will have to design tests and guide the machines in creating software and solutions.How should you prepare for it?There is already a need to design ethical tests, like for Microsoft’s AI chatbot “Tay” that became a racist. But before ethical tests can be implemented, a new set of development tools need to be developed from current TDLR prototypes. As a developer or architect, you will have the opportunity in the next few years to become a part of the development, and get the experience needed to not only design the technical tests, but also the ethical and conceptual tests. The book “Testing in the digital age” [Tes2018] is a good start to find out how to deal with these new challenges. Ethical and conceptual tests will require us to answer difficult domain-specific questions such as “what is a good partner”, “what makes a good product”, “how to make the customer happy”, etc.. These questions are important, and as a developer/architect in the 2020’s we will be answering them!Bartek Rohard Warszawski defines “knowledge” as the ability to predict a future – if you can predict something, then you can prepare for it.He has almost 30 years of experience within software development and testing, which he uses, when he speaks at conferences, writes articles, and holds workshops in TDD and test automation.Email: Bartek.Warszawski@Capgemini.comLinked: https://www.linkedin.com/in/bartek-rohard-warszawski/References

[Cor57] “The Perceptron A perceiving and recognizing automaton (project para)”, Cornell Aeronautical Laboratory, inc., Report No. 85-560-1, Frank Rosenblatt, January 1957

[Pat61] “A Pattern Recognition Program That Generates, Evaluates and Adjusts its Own Operators”, Leonard Uhr and Charles Vossler, May 1961

[Che] http://mathematics.chessdom.com/shannon-number

[Uni] https://www.universetoday.com/36302/atoms-in-the-universe

[Ifl] http://www.iflscience.com/technology/artificial-intelligence-dreams/

[Pix] https://petapixel.com/2017/12/05/ai-can-change-weather-seasons-time-day-photos/

[Dep] https://deepmind.com/documents/119/agz_unformatted_nature.pdf

[Tes2018] Testing in the digital age, by Rik Marselis, Tom van de Ven, Humayun Shaukat, 2018, ISBN 9789075414875

This content was first published in magazine OBJEKTspektrum, Germany.

Learn Not-ism

Learn about Not-ism
Learn about Not-ism

Why Not-ism? It’s a fresh take on understanding the world, reminding us that maybe complete understanding is a bit out of reach. But with Not-ism, we embrace the mystery and endless exploration! 🌟

Topics

🚧 Bondaries

🚧 Equivalent classes

🚧 Creating something out of nothing

🚧 Multiple paths to create Math

🚧 Paradoxes show the limits of our language

About

About Bartek and the think tank

About Bartek

Bartek is holding a keynote
Bartek is holding a lecture at 7N Academy

Welcome to my corner of the digital universe – I’m Bartek, your friendly neighborhood Software Quality Coach and Test Engineer! ✹

For years, I’ve been on a quest to make IT projects more transparent, efficient, and downright awesome!

As a Software Quality Coach, I’ve made it my mission to support testers and developers alike, offering guidance and reminding them about the fun and creative work of coding and testing!

I’ve also been dabbling in the mystical world of AI since way back in 1996. Even developed a Machine Learning algorithm called TDRL (Test Driven Reinforcement Learning) đŸ€–âœš
See the algorithm in action: Youtube or try it yourself: Bitbucket
And currently I am using AI to teach coding, testing, and TDD!

My top achievements:

📉 Reduced maintenance cost by 98% for test automation suites
(yeah, I’m a context-driven-automation wizard!)
📈 Reduced the execution time on a test suite from 8 hours to 2 minutes.
(talk about lightning-fast with proper shift-left!)
đŸ—ș Built a reporting tool show clearly business flows and data through IT-systems.
(say goodbye to being lost, and hello to live-documentation!)

And honorable mentions:

đŸ„‡ Got world’s highest score in a certification exam.
📖 Contributed to the book “Testing in the digital age – AI makes the difference”.

Personal

💍 Married to a fantastic woman, with who I have four lovely children.
🎓 Mensa member.
💗 Love skipping rope, swimming, carnivore diet, gaming, RPG’s, teaching, and sailing:

Bartek Rohard Warszawski

So, there you have it – a little peek into my world. I can’t wait to embark on this epic journey with you, fellow adventurers! Let’s make some magic happen! đŸ’«âœš

Bartek der holder foredrag pÄ test expo 2019
Bartek holder foredrag i Odense

Adding web editors for coding

A raven is coding

Let’s talk about learning to code – it’s like unlocking a whole new world of possibilities, right? But wait, here’s the thing: sometimes, getting started can feel like hitting a roadblock, especially when it comes to installing all those fancy tools.

But guess what? I’ve got your back! I’ve whipped up some super cool editors for JavaScript and Python, and I’ve even thrown in some existing ones for Groovy and C#! 🎉

Direct link

Now, here’s the kicker – we might not be able to code anything just yet, but we’re gonna learn the basics together. It’s like laying down the foundation for a super cool coding adventure! đŸ’»âœš

Stay tuned, because I’m about to show you the ropes in these editors. And get this – we’re gonna dive into the world of Test Driven Development and AI too! It’s gonna be an epic journey of learning and discovery. 🌈📚

So, wish me luck on this exciting adventure, and get ready to join me on this coding quest! Let’s do this! đŸ’ȘđŸ€–đŸ€

Why the cute style?

From intellectual to kawaii
From intellectual to kawaii

Why does testing and programming always have to be so serious?

I have always been fascinated by visuals as with programming.
Maybe I should loosen up a bit and have some fun?

So, why not include fun and cuteness, like kawaii?
(kawaii in Japanese means lovely, adorable, cute)

Proof of concept:

What would users of my site think?
Will they love it, like I do?

An A/B test could give an result.
(An A/B test is a test, where I post both solutions, but the 50% users see the A version, while the other see the B version. Then we can compare which version, works best for the users).

There was also another option:
Who would I preferer to eat lunch with?
I might loose 98% people, if I use the kawaii style.
At the same time, the rest 2% will be fun to eat lunch with!

So, why not try it?

Why TDD

why TDD

Why TDD?

Given we want to build something beautiful and complex.
When we build it, one step at a time.
Then we can experience our product manifest,
while we use our experience as a compass, to correct it.

Just like with do, when we put a jigsaw puzzle: one brick at a time.

This is what Test Driven Development is all about.

We can use it to learn programming, testing and build what ever we want – be it software or something completely else! (I use TDD to improve my house!)

Testing & Not-ism

Learn about Not-ism
Learn about Not-ism

What is Not-ism?

Philosophers have always attempted to explain how the world truly is. Socrates had his ‘world of ideas’. Nietzsche mentioned ‘will to power’.

In 2022, I introduced Not-ism, coming from the idea that “perhaps it’s not possible to fully describe reality.”

It’s a bit like knowing where my house is in relation to my neighbors, my children’s school, and my workplace. But I have no clue about where exactly in the universe my house is located.

This means that I can only describe things (e.g., the location of my home) based on all the other things I know (neighbors, school, workplace, etc.). To describe something fully would require me to know everything in the entire universe, which I cannot.

Local and temporal (no-universality)

This means that absolute, universal, or objective knowledge is beyond our human reach.

The principles of Not-ism also apply to Not-ism: That Not-ism cannot be absolute, universal, or objective, but only personal.

This means that you don’t have to understand Not-ism as I do, and I don’t have to understand Not-ism as you do. But we can have each our own versions.

Not-ism and testing

Before we can observe to objects, there needs to be a difference or a border between them. If we can’t see any difference or border, then we will only experience a single object.

This is the foundation of many test techniques, such as equivalent classes, where we see what different properties an object has or how many objects there are.

Boundary value analysis is also in this category, because we look, where something starts and ends, by looking at, when a difference happens. We test:

  • below the minimum to test, that something hasn’t started yet,
  • the minimum to test something has started,
  • the maximum to test it hasn’t ended yet,
  • above the maximum to test it has ended.

We can even prove mathematics with Not-ism, but that will be in another article.
(I have written about it in my book Not-ism, it’s okay not to know).
The Spiritual Dimension of Empirical Science

Empirical science for me is spiritual.

Something spiritual can be seen something beyond our consciousness or language. An experience we can’t fully describe, but still can sense it.

We can explore the phenomena with experimentation. When we can reproduce it, then we can become conscious about it. When we can make other people reproduce it, then it can become part of our language. Something we then can discuss and share. 

This is why I’ve made the Test Driven Oracle Cards open-ended, with the option to create custom cards. 

By doing so, we all have the opportunity to explore our selves, and things we are not conscious about. A process to refine our understanding. A process to grow our body of knowledge.

Keynote: A way to do Test Automation

Dark but fun side of test automation

What is test automation and how do we do it?

What is testing and why do we need it?
Important questions to answer, before we start automate it.

Testing is the empirical foundation of knowledge and therefore a very useful tool to navigate after. We dive into Test Driven Development: a method to describe quite complicated systems, without ever having the entire model in our head before hand. It’s about exploring one step at a time to experience what is needed.

We look also into configuration management of test data, because we need to encapsulate the complexity and be able to focus on what is actually important.  

Next generation of test reporting is not only about to see what has passed and what didn’t, but to use as live documentation, which illustrates how data flows through the systems and is always up to date!


During this session you will learn about

  • Have another perspective on what testing is and why it is important.
  • How to apply test driven development, instead of development driven test (and do proper shift-left)
  • How to encapsulate the complexity, so the focus can be spot on what is important.
  • How test reporting can be used as live-documentation.

Join Mohammad and Bartek for an interesting session, where we share our experience of our successful and not so successful experiences.


Bartek Rohard Warszawski
Quality Coach & Test Engineer

Mohammad El-Wali
Test Architect & Engineer

Mohammad and Bartek are recognized expert in the testing industry and have been on multiple major IT-projects together. Mohammad is a certified ISTQB advanced trainer, while Bartek have been teaching in Test Driven Development since 2018 and has his own AI-learning (e-learning 3.0) platform.


Format: Keynote presentation
Location: Copenhagen, Aarhus or online
Language: Danish / English
Duration: 30 min. – 2 hours
Max. Attendees: no limit
Price: contact me


Provided in collaboration with 7N Academy

Watch my music video about being a Test Automation Rockstar!

Onsite workshop in Test Driven Development

Workshop in Test Driven Development
Workshop in Test Driven Development

Let you developers and test engineers learn Test Driven Development

Test Driven Development also known as TDD is a method to describe quite complicated systems, without ever having the entire model in our head before hand. It’s about exploring one step at a time to experience what is needed.

We start from the basics of “what is TDD” and why it is important, especially in the age of AI with tools such as Git Copilot and Devin.

Then we will progress to concepts such as “Red, Green, Refactor”, Testing framworks, unit-testing, mocking, CI/CD pipelines, Behavior Driven Development, etc.

There is also plenty of hands-on exercises an we will also use AI tools to help us learn.


During this session you will learn about

  • What TDD is and why it is important, especially in the age of AI.
  • How to describe and implement complicated systems, without having the whole model in our heads.
  • Learn about Testing frameworks, unit-testing, mocking, and how to integrate it with CI/CD and Behaviour Driven Development. We will also use AI to help us.

The course caters to developers and Test Automation Engineers. A requirement is to know a programming language, such as Python, Groovy, C#, JavaScript, etc.


Bartek Rohard Warszawski
Quality Coach & Test Engineer

Bartek is a recognized expert in the testing industry and have been on multiple major IT-projects.
He learned to code at the age of 9 and soon learned the importance of testing.

Bartek have been teaching in Test Driven Development since 2018 and has his own AI-learning (e-learning 3.0) platform.

Agenda

  • What is TDD and why do we want to use it.
  • Going from manual testing to unit-testing.
  • TDD with CI/CD and AI.
  • Walk through unit-testing and integration-testing.
  • Lunch đŸœïž
  • Introduction to Test techniques.
  • Intro to fakes, stubs, spies, dummies, and mocks.
  • Test reporting and live-documentation.

Format: Workshop
Location: Onsite
Language: Danish / English
Duration: 1 day
Max. Attendees: 4-10 people
Price: contact me


Provided in collaboration with 7N Academy

Watch my music video about being a Test Automation Rockstar!