Thanks to Karlo Šmid for the photo. Used with permission.

The Idea

I wanted to give a five minute lightning talk in April at Testival Meetup #80. AI is a topic everybody talks about these days. I play a few instruments. I’ll ask an AI for advice on how to write a song. Then, iterate with the AI over the song, live, in front of the audience. When I practiced it, it took hours, not minutes. I did not give up on the idea, but I had to significantly simplify it.

The Plan

At home:

• Ask an AI for advice on writing a song.
• Ask it to generate sample tablatures for a song.
• Prerecord the bassline and the guitar chords.

At the event:

• Play the prerecorded part from a computer.
• Play the guitar solo live.

All music has to be composed and performed by me. I can only ask AI for advice. I can never follow its advice blindly.

Vibe Composing Git Repository

There are several popular AI tools. I have decided to use Claude Code. (Just Claude from now on.) I don’t know which model I used at the time, but it was probably Opus 4.6.

I thought it would be funny to ask a tool optimized to create code, to create tablatures instead. Both are just text, after all. What could possibly go wrong?!

After some conversations with Claude, we decided to compose a simple rock song in C major. The chords are C, Am, Dm, F and G.

I have created a git repository, vibe-composing. I decided to experiment with all the stringed instruments I have. Bass, guitar and ukulele. For each instrument, I asked Claude to generate a fretboard, a scale and both a simple and an advanced solo.

In addition to those, I asked it to generate the music I would play in the song. For example, a bassline for the bass, and the chords for the guitar.

What Didn’t Go So Well

At the time, I didn’t think I would write a blog post about it, so I didn’t save the conversations I had with Claude. That would be a fun read. A lot of the time I was complaining about mistakes it made.

Even when asking for very simple tablatures, it was getting things wrong. For example, it would mess up whitespace. Tablatures are read by humans, so whitespace is not significant. Except, nicely formatted text is much easier to read.

At one point I realized the bassline was so wrong, on so many levels. I decided to start over. This time, I would record the mistakes. For a very simple bassline, it got two notes wrong. Then I noticed one more wrong note. Also, the text was not formatted correctly. All of that for just a very simple bassline.

(While writing the article, I took another look at the tablatures. Some of them are still wrong, in various ways. I didn’t have the time to fix them. Please report an issue on GitHub if you find something wrong in the tablatures.)

What Worked Well

Out of all tablatures it created, fretboards were the most useful. (It shows where each note is on each string.) I used the guitar fretboard to practice the solo. There are plenty of fretboards available online. With a tool like Claude Code, you can create a custom one. Just for your instrument: type of the instrument, number of strings, number of frets, tuning…

Performance

I didn’t have the time to check how my computer and guitar would sound in the room. It was a big, noisy room. Both my computer and small portable guitar amplifier that I had were not even close to being loud enough. I’m not sure if anybody heard anything. Lesson learned for the eventual next time. Bigger speakers. Check the sound in the room before the event.

That said, I did have a lot of fun playing live in front of a small friendly audience. I would do it again. If you would like to hear a funny talk about using an AI to help you create music, let me know.

Conclusion

I was not impressed with Claude’s ability to create tablatures. Even for very simple tablatures, it was getting things wrong. It was doing almost ok for chords and scales, but I was not at all impressed with the solos it created. For none of the instruments.

I do understand I was using a tool optimized for generating code to generate tablatures. That was the point of the experiment.

It was a fun experiment. As with every experiment, I need to work on it more. I had very limited time for it, just a few hours. So, the experiment is in a half-finished stage. I’ll experiment more in the future, if some magical free time falls from the sky.

Handcrafted

No AI was used in writing this article. I wrote it the old fashioned way. Start with a blank page. Every single letter, word, sentence and paragraph was created by me and typed by me. I do use grammar and spell checking, but that’s all.

Introduction

In April 2026 I have attended Testival meetup #80 (testival.eu, meetup.com).

It was a pretty big meetup, more than sixty people. Since there were so many people, the usual introduction at the beginning took about twenty minutes. A lot of people have very poor microphone skills. It was a big room with a lot of people. If you didn’t speak directly into the microphone, nobody could hear you.

There were three longer talks, a break and one lightning talk.

Talks

There were three talks. All by the people from the host company, Super. I’m not sure I have the correct titles of the talks. I should get slides from the talks soon, so I will update the post.

The host made a mistake of having three talks. One talk is usually enough. Two might work, if they are not too long. But with three talks, there was almost no time to socialize. That is an important part of in person meetups. When the talks were finished, the vast majority of the people left.

AI in QA

There was a lot of prompt engineering. I prefer more engineering, less prompts. To my surprise, there was a lively discussion after the talk. Several people asked questions. I might be one of the rare people not excited by prompt engineering.

AI augmented quality engineering

I’m not sure I even understood what the speaker was talking about. Except, there was plenty of prompt engineering. Again, there was a lively discussion after the talk. I might just be too old and too grumpy.

Load testing

Finally a talk with just engineering and very little prompts. It was about using k6 and Kubernetes. There was another lively discussion after the talk. Some people had questions for every speaker. That’s impressive.

Lightning talks

As the only lightning talk, when most of the people already left, I talked about vibe-composing. It’s an experiment in composing music with Claude Code. The part of the talk was me playing live on my guitar. I didn’t have the time to check how my guitar will sound in the room, so I’m not sure if anybody heard anything. Anyway, I’m glad I got a chance to play in front of a small and friendly audience. If I give a similar talk in the future, I’ll make sure to check the sound first. It’s an important part of the talk.

Last month we didn’t have a regular Testival meetup, so we had the second Testival book club. The attendance was lower than the last time. This time only three of us came. It is my fault. I organized the meetup on very short notice. March was really busy.

We were talking about Taking Testing Seriously: The Rapid Software Testing Approach by James Bach. I was the only one that finished the book. Other attendees (Karlo and Bojan) started reading, but didn’t finish yet.

It was still a good meetup. Karlo wrote a blog post An unexpected display of art about it.

During the last meetup, I didn’t yet write Taking Testing Seriously by James Bach and Michael Bolton. I also depended on my Kindle for highlights from the book. Looking for relevant highlights on the Kindle proved not to be fast, so this time I have printed both the blog post and all of my Kindle highlights. It made it much faster to find things.

At work, I have to set up MediaWiki on my machine frequently. Setting up MediaWiki Core is not a big problem. The problem is when you want to install an extension or a skin. Some extensions and some skins are easy to install and set up. Some are very complicated. Guess which ones I have to install most of the time.

Over the years, I have tried several MediaWiki local development environments. (I’ll use just the environment from now on.) The list below is roughly by the time I started using each tool.

• MediaWiki-Vagrant
• MediaWiki-Docker
• cli
• MediaWiki-Quickstart

In 2023 I created a task to explore various available options (T344682).

A few environments I didn’t even manage to try yet.

• docker-dev
• Local development quickstart

I’m sure I’m missing a few environments. I remember trying some environments that no longer exist.

What’s the point? Obviously, there’s a need for environments. No existing environment has all, or at least most, of the features developers are looking for.

Quibble

I was working on a project that required me to take a good look at Quibble. Quibble is an important part of our continuous integration. It’s the part that installs and configures MediaWiki Core with various combinations of extensions and skins.

As a first step of taking a good look at it, I updated a very old wiki page, Run tests targeting Quibble. I have created the page in 2019, and the last update to the page was in 2021.

I was playing with Quibble and updating the page. I was pretty happy with Quibble features. I was not at all happy with the commands I had to write.

For example, this command installs MediaWiki Core.

docker run -it --rm \
  --entrypoint=quibble-with-supervisord \
  -v "$(pwd)"/cache:/cache \
  -v "$(pwd)"/log:/workspace/log \
  -v "$(pwd)"/ref:/srv/git:ro \
  -v "$(pwd)"/src:/workspace/src \
  docker-registry.wikimedia.org/releng/quibble-bullseye-php83:latest

This one runs Selenium tests.

docker run -it --rm \
  --entrypoint=quibble-with-supervisord \
  -v "$(pwd)"/cache:/cache \
  -v "$(pwd)"/log:/workspace/log \
  -v "$(pwd)"/ref:/srv/git:ro \
  -v "$(pwd)"/src:/workspace/src \
  docker-registry.wikimedia.org/releng/quibble-bullseye-php83:latest \
  --skip-zuul \
  --skip-deps \
  --run selenium

Pretty quickly I had enough of copy/pasting long multi-line commands.

In MediaWiki-Quickstart, the same can be done with these commands.

./fresh_install
./run_selenium_tests

That’s way more to my taste.

Quibble Local

In the spirit of xkcd standards comic, the obvious solution was to create yet another environment. Of course. Introducing… Quibble Local. (URL might change in the near future.)

My initial plan was to create simple scripts that would execute very long Quibble commands. I didn’t need to think about how to name the scripts. I could just reuse names from MediaWiki-Quickstart.

So, in Quibble Local, if you want to install MediaWiki Core and run Selenium tests, you would use the same commands as MediaWiki-Quickstart.

./fresh_install
./run_selenium_tests

These were one of the first commands. Quibble Local has much more features these days.

Project readme file documents everything. You can also use the help command to get help for all commands, or about just one command.

./help
./help install

I keep adding features and refactoring the code. Let me know if you find it useful, if you find any problems, or if you have any comments. See the footer for contact information.

Claude Code

I took this project as an opportunity to try Claude Code. I wanted the project to have minimal dependencies (Bash, Git, Docker). There was no chance I was going to write a project in Bash. For various reasons.

It is an interesting experience. I’m impressed that a tool can write code that does what I say. Most of the time. I’m not impressed with the quality of the code, or the architecture. Since this is just an experiment, I’m fine with the code as is. If this becomes anything more, I would rewrite it in a language I know better.

Draft

This post is a draft. Please come back in a week or two and it will be updated.

I try to write at least one blog post every month. For months where I fail to meet even that very low bar, I publish whatever I have at the end of the month. I do my best to finish the post as soon as possible. Usually in the next few days, or weeks.

Introduction

I have been reading James Bach’s blog for years, if not decades. The same is true for Michael Bolton’s blog. (I met Michael Bolton, not once, but twice! The first time in 2018, the second time in 2025.) In late 2025 James Back published a blog post 55 Months, 1 Day, announcing his new book. The book is a collaboration with Michael Bolton. (I could not find a blog post announcing the book on Michael Bolton’s blog. The only thing I found is Taking Testing Seriously: The Rapid Software Testing Approach.)

I was very excited to read the book. I think I bought it on the very day it was published. I have been reading it almost every day for about thirty minutes. I might be one of the first people that have read the book.

The book

The book has four parts, twenty two chapters and four appendices.

The first eight chapters are written mostly by James Bach. From chapter nine until the end of the book, each chapter is written by a different author or authors.

Chapters seventeen and eighteen are transcripts of interviews Michael Bolton had with a couple of people.

Appendices are unattributed, so I assume they are written by the main authors, Bach and Bolton.

It’s a very strange book format. I don’t think I’ve read a book that combines so many different styles and authors. Maybe Bach and Bolton submitted the first eight chapters (and appendices) to the publisher and they told them the book is too short. So, they added more chapters written by other people. Maybe they wanted this format.

Book Clubs

I have started not one, but two book clubs about the book. One for Testival (see Testival Meetup #78), one at work. Each club has met once so far. Both clubs plan to meet at least one more time.

I love book club meetings. I had great discussions in both clubs.

Quotes

When I exported my Kindle highlights to a pdf file, it was twenty file pages. That’s above the average for me. The average is five to fifteen pages. I’ll comment on a few interesting quotes.

The first full book on a human-centered approach to testing was Cem Kaner’s Testing Computer Software. (Page 13.)

I have read it in 2022.

But we suggest that pessimism is a good heuristic for testers. Let everyone else on the team be optimistic. (Page 70.)

Pessimism is my superpower.

p. 233339362199739. (Page 73.)

I’m one of those people that (sometimes) carefully reads footnotes. This surely looks like an impossible page number.

Bug reporting is central to testing. (Page 118.) … the quality of your reports is probably the single most important factor in determining your credibility as a tester. (Page 118.)

There’s craft in writing a good bug report. As short as possible, while still containing all relevant data.

No one can deny that automation tool sales demos are impressive. (Page 217.)

That’s the main complaint I have when I see a demo of yet another test automation tool. Sure, it’s impressive for a simple example. But what happens in a few months, or years, when there’s a lot of code?

…the costs of automation are not just in the initial creation of it. (Page 232.)

In my experience, the vast majority of the cost is maintenance.

There are also large tooling opportunities; automation frameworks and such. But keep in mind, there is a certain danger with those projects: they tend to pull the toolsmiths into their own world. Pretty soon, the testers are wondering what those guys do for a living. (Page 237.)

I do test automation for a living. For the last couple of decades. At least once, a tester asked me what in the world I actually do.

Considerations for GUI-level Automation. Let’s say you are thinking about embarking on automation that will drive the product on a GUI level. Okay. Generally speaking, you ought to be scared of this. (Page 243.) Having said that, it’s not always a bad idea. (Page 243.)

If you’re not scared of GUI test automation, you should be.

So-called self-healing automation is very limited in its scope. Don’t believe the hype. (Page 245.)

I am yet to see this work. As usual, I’ll be glad to be proven wrong.

There’s always a problem, and the problem is always people. (Page 428)

If you think projects fail for technical reasons, you might be wrong.

Of all the things I’ve learned over the years, I see now that learning how to learn has been the most valuable lesson. (Page 433.)

I wish learning how to learn is something you do in school. I had to learn it myself.

Popular Highlights

The book has more than five hundred pages. All of the popular highlights are in the first fifty pages. Either most of the people that highlight have only read the first ten percent of the book, or the first ten percent of the book are the best part.

I’ll have to double check, but it looks like popular highlights are not the same (for the same book) on my Kindle device and in my Kindle macOS app. Shrug.

Why Testing?

Testing is the opposite of faith in the product. Testing begins with faith in the existence of trouble. (Page 8, 20+ highlighters)

The Meaning of Testing

Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting with it. (Page 17, 30+ highlighters)

Even if you do run a bunch of very good automation, when it fails, you must investigate it. That’s a learning process. And when it doesn’t fail, you ought to be wondering what bugs you could be missing. You should be proactively looking for holes in that testing. That’s a learning process. Real testing is always learning. (Page 18, 10~ highlighters)

A test is an encounter with a product that constitutes an episode of testing. (Page 20, 20~ highlighters)

Good deep testing means testing that maximizes the chance of finding every elusive bug, of some particular kind, that matters. Good shallow testing means testing that has some chance of finding every easy bug of some particular kind. (Page 21, 20+ highlighters)

Foundational Ideas

For testing purposes, we are concerned with dynamic systems— wherein changing the meaningful relationships causes change to the entire system. (Page 34, 20+ highlighters)

A model allows you to explore a system; exploring a system allows you to model it better. (Page 34, 20+ highlighters)

Testers do not control, assure, or ensure quality. Releasing the product is a business decision, not a testing decision. (Page 38, 20+ highlighters)

Methodology is what you think should happen; process is what actually happens. (Page 43, 20+ highlighters)

Without tacit knowledge, you can’t solve hard problems; without explicit knowledge, you can’t talk about them. (Page 48, 10+ highlighters)

This week we had the first ever Testival book club. About ten people came to discuss Taking Testing Seriously: The Rapid Software Testing Approach by James Bach.

We did our usual introductions, had some pizza and discussed the book. Less than half of the attendees started reading the book. Most of the people just started reading recently, so they have read only the first few chapters. I was the only one that has read more than half of the book. (I read for about thirty minutes every working day.)

The discussion was diverse. From different chapters of the book, to ISTQB and finally to AI (of course).

We were a bit distracted by a big screen in the restaurant showing the Croatia-Hungary handball game.

I really enjoyed the discussion. Two hours were not enough. I hope we’ll have more book club meetups in the future.

Introduction

Cal Newport is one of my favorite authors. I have read almost all of his books. Some of them several times. I also really like his podcast Deep Questions.

I have read this book at least two times. I have listened to it in late 2022 as an audio book and I have read it in early 2025 as an ebook.

I wish I had read this book when I was much younger. Probably in high school. I hope my kids read it in high school.

2025 was really busy. I wanted to write a review of the book earlier. I usually have the time to write one blog post every month. So, this book never made it to the short list. Until now.

The Book

The book has four sections. Each section has several chapters. Each section discusses one rule.

• Rule #1: Don’t Follow Your Passion
• Rule #2: Be So Good They Can’t Ignore You (Or, the Importance of Skill)
• Rule #3: Turn Down a Promotion (Or, the Importance of Control)
• Rule #4: Think Small, Act Big (Or, the Importance of Mission)

Quotes

After exporting my Kindle highlights, I got an eleven page pdf document. I have highlighted a lot. I’ll select just a few quotes.

Chapter One: The “Passion” of Steve Jobs

The Passion Hypothesis

The key to occupational happiness is to first figure out what you’re passionate about and then find a job that matches this passion.

(Page 4.)

Before reading the book, I thought this was the only way. I know better now.

Chapter Five: The Power of Career Capital

The Career Capital Theory Of Great Work

• The traits that define great work are rare and valuable.
• Supply and demand says that if you want these traits you need rare and valuable skills to offer in return. Think of these rare and valuable skills you can offer as your career capital.
• The craftsman mindset, with its relentless focus on becoming “so good they can’t ignore you,” is a strategy well suited for acquiring career capital. This is why it trumps the passion mindset if your goal is to create work you love.

(Page 48.)

The combination of rare and valuable is the key. If something you can do is just rare, or just valuable, it’s not enough.

Three Disqualifiers For Applying The Craftsman Mindset

• The job presents few opportunities to distinguish yourself by developing relevant skills that are rare and valuable.
• The job focuses on something you think is useless or perhaps even actively bad for the world.
• The job forces you to work with people you really dislike.

(Page 56.)

When selecting a job, you don’t have to be really picky. There are just a few things that would make a job bad.

Chapter Seven: Becoming a Craftsman

There are two types of these markets: winner-take-all and auction.

(Page 91.)

I was not aware of these two markets. The world makes more sense now.

Chapter Eleven: Avoiding the Control Traps

The Law of Financial Viability When deciding whether to follow an appealing pursuit that will introduce more control into your work life, seek evidence of whether people are willing to pay for it. If you find this evidence, continue. If not, move on.

(Page 139.)

It’s pretty easy to get positive feedback from people. It’s very hard to get money from people. If people are willing to pay for something, you have struck gold.

Popular Highlights

This Kindle feature fascinates me. What have other people highlighted? It’s probably important. I could not find any official documentation about it. What I did find is that a lot of people hate it.

Introduction

In other words, you need to be good at something before you can expect a good job.

(4k+ highlighters.)

A word of warning for people entering the job market.

Chapter Two: Passion is Rare

Compelling careers often have complex origins that reject the simple idea that all you have to do is follow your passion.

(Page 13. 4k+ highlighters)

My career is a perfect illustration of this.

Autonomy: the feeling that you have control over your day, and that your actions are important

Competence: the feeling that you are good at what you do

Relatedness: the feeling of connection to other people

(Page 18. 5k+ highlighters.)

The more I think about this, the more it sounds correct.

Chapter Three: Passion is Dangerous

The more we focused on loving what we do, the less we ended up loving it.

(Page 23. 3k+ highlighters.)

It’s similar to relationships. It’s not enough to focus only on picking the right person. It’s very important to work on the relationship once you have found the right person.

Chapter Five: The Power of Career Capital

You need to get good in order to get good things in your working life, and the craftsman mindset is focused on achieving exactly this goal.

(Page 49. 4k+ highlighters.)

The world doesn’t owe you anything. You have to deserve it.

Chapter Seven: Becoming a Craftsman

It is a lifetime accumulation of deliberate practice that again and again ends up explaining excellence.

(Page 84. 4k+ highlighters.)

This is probably not something you want to hear at the beginning of your career. It’s something you’ll agree with later in life.

Doing things we know how to do well is enjoyable, and that’s exactly the opposite of what deliberate practice demands.… Deliberate practice is above all an effort of focus and concentration. That is what makes it “deliberate,” as distinct from the mindless playing of scales or hitting of tennis balls that most people engage in.

(Page 96. 3k+ highlighters.)

It’s sobering when you realize you have hit a plateau in something. Be it running, chess, guitar, coding… The time of being comfortable is over. It’s time to train hard again.

Chapter Eight: The Dream-Job Elixir

Giving people more control over what they do and how they do it increases their happiness, engagement, and sense of fulfillment.

(Page 113. 4k+ highlighters.)

To summarize, if your goal is to love what you do, your first step is to acquire career capital. Your next step is to invest this capital in the traits that define great work. Control is one of the most important targets you can choose for this investment.

(Page 114, 3k+ highlighters.)

I have not realized, until recently, how motivated I am when I have a hard goal to reach, and enough control to try different approaches to reach it.

Chapter Twelve: The Meaningful Life of Pardis Sabeti

Hardness scares off the daydreamers and the timid, leaving more opportunity for those like us who are willing to take the time to carefully work out the best path forward and then confidently take action.

(Page 154. 3k+ highlighters.)

I am amongst “the daydreamers and the timid” in several things that are important to me. I am amongst a few that are “confidently taking action” in a few things that are important to me.

Meetup

For me the meetup started with a beautiful bike ride to the venue. As usual, Karlo Šmid joined me on the bike ride after the meetup. We had some time for a longer chat.

About thirty to forty people were at the meetup. An average for our meetups. There were even several people online. (We usually don’t have an online option.)

There were a couple of talks and several lightning talks.

• Sanjin Grahovar Sadiković - Maestro: A Modern Take on Mobile Test Automation
• Greg Paskal - AI Insights for the Quality Minded

It was a good meetup. It was organized by Tomislav Prša. He’s taking more and more of the organization. I’m glad the next generation is taking over.

Maestro: A Modern Take on Mobile Test Automation

Maestro looks interesting. It’s a mobile test automation tool. It was fun to see in the documentation how to automate Wikipedia Android application page.

I already have an idea for a project where I would like to try it out.

I’m not impressed by using YAML for writing tests. (There seems to be a JavaScript option too.) (I once strongly discouraged a team at work that was writing an automation framework from using YAML. They eventually picked JavaScript.) YAML is great for demos. Even for some simple use cases. It would probably not be a good choice for any even moderately big test suite. I prefer to write tests in real programming languages. All the way back in 2001, Bret Pettichord wrote Hey Vendors, Give Us Real Scripting Languages.

AI Insights for the Quality Minded

I’m not sure why the host company wanted to have a remote speaker. We usually only have in person meetups, with in person speakers. That said, Greg Paskal did a good job.

These days, no event can happen without somebody talking about AI. He talked about using various AI tools for various tasks, and for which of those tasks tools did a good job and for which tasks they failed.

Lightning talks

One of the best parts of every meetup are lightning talks. (Up to five minutes long.) We had three this time.

• Marko Bjelac - Većina koda je bljak. (Most of the code is yuck.)
  • Mostly a commercial for the meetup he’s organizing, Zagreb Software Crafters. Lightning talks are perfect for such announcements.
• Karlo Šmid - Build a Large Language Model (From Scratch) by Sebastian Raschka.
  • Book report.
• Željko Filipin - Taking Testing Seriously by James Bach and Michael Bolton.
  • I have proposed we read the book together, like a book club. We’ll see how that goes.

I’m taking a photo of Karlo, who’s taking a photo of Michael. To make it even more fun, you can see Michael, Karlo and me on the big screen.

Introduction

At the beginning of the month, a member of the Testival community posted in our Slack that Michael Bolton is giving a talk in nearby Ljubljana, Slovenia.

This was not the first time I would see Michael speak. He was already in Zagreb (Croatia, where I live) at Testival #41.

Ljubljana is about a two hour drive from Zagreb, so a few of us decided to go. I was driving one car. There was at least one more car from Zagreb with a few more people. A fun part of such events is that there’s several hours of driving to get there and back, so there’s plenty of time to just talk. Frequently, it’s hard to find some time to just talk with people.

We arrived an hour or two earlier. We had time to walk around a bit, grab a drink and some food. There was even time for a short chess game.

Meetup

QA meetup in Ljubljana happens only once a year. (Our Testival meetup is monthly.) About fifty (or even sixty) people came. Pretty good outcome for a meetup.

It started with a very short introduction by the organizers. So short, that I don’t think the organizer introduced himself or the company, just the speaker.

They had trouble connecting the speaker’s machine to the big screen. I think the solution included connecting a phone with a cable to the computer, then connecting to the screen via the phone, then somehow to the computer. Or, something even more complicated. Welcome to 2025.

The official talk name was “What Are We Thinking in the Age of AI?”. The unofficial summary could be “I don’t hate AI.”

Michael recommended a lot of books and articles. I was trying to write them all down, or take photos of slides. I’m not sure if I did a good job. I think the best way is to send him an email message asking for slides. I’m sure I missed a lot of recommendations, or got them wrong.

The talk lasted for more than an hour. It was longer than expected. I’m not complaining. It was a good talk.

I have plenty of notes from the talk, but I’m having trouble picking a few to highlight here. A pretty interesting part of the talk was a report Michael (or James Bach, or both of them, I’m not sure) created after testing several AI tools. (I’m not sure if Serious Data From Testing LLMs is the correct report.)

After the talk there was some time for questions. The vast majority of questions came from people that came with me to Ljubljana. I had a few questions too, but I wanted to give others a chance to ask their questions.

After the talk, there was more time to socialize. Since I came all that way to see Michael speak, I decided to stick around him. People were asking all sorts of questions. That was a pretty good part of the event.

Conclusion

I’m glad I heard about the event and that I was able to attend. If it wasn’t posted to Testival Slack, I would surely miss it.

I’m glad several people from the Testival community are interested in testing so much that it’s not a problem for them to drive for a few hours just to attend an event.

It was great to have some time with fellow Testival organizers, Karlo and Tomislav.

The event itself was well organized. The talk was interesting. The discussion after the talk was great.

I hope there will be more events like that in the near future, close enough to where I live.

Read More

If you want to read more about the event, Karlo also wrote a blog post.

Meetup

During summer there are no official Testival meetups, but a few of us meet every month for drinks. In July and August 2025 we had Testival meetups #74 and #75.

It’s always great to meet with the Testival organizers and community. In this photo by Niko Mađar (used with permission) you can see all Testival organizers and one community member.