My trip to Leipzig began, ofc, with S-Bahn chaos: https://www.sueddeutsche.de/muenchen/muenchen-s-bahn-chaos-ursache-li.3548379?reduced=true. So I had to take an Uber to still catch my train.
Lucky for me, the German train gods were with me, and I arrived on time at Leipzig’s main station.
On Tuesday there was a meetup before the offical confereence but since I still had some time left I decided to first get a doner
Then I used the two hours before the meetup to visit and walk around Leipzig. I prepared a small guide with the help of Clanker. It had a website with images and the exact locations I should visit: https://alexanderop.github.io/leipzig-spazierplan/.
Nikolaikirche
After I visited all the places and got some coffee
Then I walked from my hotel to the “Quality is NOW” – Networking Around Quality Engineering Meetup. It only took 30 minutes.
I arrived, got my Tacon badge, and then waited for the first lightning talk to start.
The lightning talk was by Lilia Gargouri, where she gave a little spoiler about her conference talk the next day. She will talk about low-code testing frameworks and how AI is changing things. Lilia is a really good speaker. Some speakers just have a kind of aura where you like to listen to them. For me, no-code tools for testing are a new concept, so it was interesting to listen to. I felt some of her frustrations with AI. I guess it is obvious for all of us that there are many things AI can do now, but if you talk with other people, there are still so many things where it struggles and sucks.
After the Lightning Talk, I met some other interesting people and we talked a bit about QA and other topics. What is always interesting about meetups or conferences is that you meet so many new people in a short amount of time. Since all of us at least share a passion for one topic, this week testing, it is easy to get a conversation going.
In the end, you could win a Tacon ticket for next week. After the winner was announced, I headed back to my hotel.
First Day of Tacon
I tried to maximise the amount of sleep I could get before Tacon started at 09:00, so I could arrive on time. First ofc I tried to find the most important place at any conference: the coffee station. After I filled up my coffee, I went to Stage 1, where Yvonne Kiepert and Elin Großhans gave the introduction. I really liked that they had some energiser exercises. There are always two hard talks at any conference:
- The first talk of the day
- The talk after lunch
Most people were still a bit tired, so they did some exercises like, “Please stand up if you are the real Slim Shady.” I mean, please stand up if you come from North Germany or South Germany, and so on. I think if I ever have a talk again that is the first of the day or after lunch, I will try out some of their exercises haha.
After that, the keynote of the day started with Michael Kutz. He gave a nice talk about his experience working in the software industry. There was one project where he had the feeling that, for a specific time, everything worked perfectly. He then tried to replicate the same setup afterward, but he was never able to do it. His talk focused on trust and psychological safety. There is a Google study about what makes a high-performance team that goes in the same direction. He also gave an example of different team setups. You can find his full Slides at https://slides.com/mkutz/vertrauen-verantwortung.
At the conference, I had many talks with Michael. We probably disagreed on some topics, but it was still nice to meet him because you could feel his drive and passion for the whole software topic.
After that, I watched Low Code in der Testautomatisierung: Fluch oder Segen? by Lilia Gargouri.
Then I watched Alexander Weichselberger’s Testen mit lokaler KI – Testfälle, Testdaten und Datensouveränität mit der razzfazz.ai-Box. It was an interesting talk because it was the first time I saw how other people try to use AI to automate testing strategy. You can check out their product at https://rzfz.ai/.
One thing where I would disagree a bit is the idea that, if we have a workflow that generates automated tests, we should still review every generated piece of code with a human expert in the loop. I think we need to aim for workflows where we do not need that. It is obvious that most developers, for example, are getting lazier and lazier when reviewing AI-generated code, or tests are just not fun to review. I think we will need experts to set up the pipeline and control what an agent is doing, but I think we should aim to reduce how much test code needs human review. That is a workflow I want to work towards, not a result I have demonstrated here. Before removing that review, I would want evidence that the pipeline catches tests that pass while checking the wrong thing. Take a hypothetical generated test for saving a document. Checking that the text stays visible is not enough. Reloading the document and checking its contents would test persistence. Deliberately breaking the save operation should make that test fail. But even those checks could miss a bug where an older save overwrites a newer edit. Experts would still need to decide which behavior matters and review gaps in the checks. I have not shown an actual generated test examined this way here, so I cannot claim that this replaces human review or gives a measured speedup. The OpenAI article below is context for the software-factory approach, not evidence that my proposed checks are sufficient. You can read how OpenAI is doing that in their software factory: https://newsletter.pragmaticengineer.com/p/openai-software-factory.
I realized how many new startup products are out there now that try to automate testing in one way or another.
Lunch
After that, we had lunch. I forgot to post an image of the food. Maybe if I continue to write blog posts about the conferences I visit, I will do a lunch rating too. There was a buffet, and I just added as many things as possible until my plate was so full that it was hard to navigate.
My favorite drink at Tacon
The next talk I visited was by Daniel Horn about Pact and contract testing. For me, it was more like a refresher because we already use contract testing. I think he did a good job introducing the topic and highlighting the importance of contract tests and Pact. For anyone who is more interested in the topic, I can recommend the book Contract Testing in Action: With Pact, PactFlow, and GitHub Actions by Marie Cruz and Lewis Prescott.
My Talk
Then at 15:50, I finally gave my talk about Vitest Browser Mode. I think I should have prepared it more for an audience of QA engineers. It was my first time giving a talk to a different audience than developers, so I think many things I mentioned, like Vitest, needed more explanation. Unfortunately, some of the live demos did not work because I use Slidev. In presenter mode, when you share the screen, you do not see interactive components. The video I generated to show that a test was working was not there either. But I got some good feedback and interest from some people. So I think as a speaker, it is always tricky to please everyone in the crowd. I like code examples and more technical deep dives. I am bored by talks that mention too much theory without concrete things someone should do. So I would personally give myself a 6/10. If I speak to a different audience than my own role next time, I will put more effort into explaining things.
After that, my colleague from Otto gave the last talk of the day on Stage 1.
It was a good talk that gave an inside look at how Otto and its platform team started to prepare a library for Playwright tests. It should help product teams with reusable page objects and helpers. I like the idea. Even if you do not have many teams and only have one team with a few developers, it makes sense to have your own testing UI library and use the DSL pattern for helper functions. Without that setup, your tests will become big and unreadable soon. The Playwright base has, for example, a helper that you can call to log in:
page.doLogin()with that setup teams that are not responible for the login but not a logged in user to test something hae a easy way to do that.
The talk also got some good feedback. I think the best talks are always the ones where someone from a company shares real findings and what they did, instead of only theoretical concepts.
After that, I went back with Michal Kutz and Christian Bauman. Since we were all speakers, we talked more about the testing community and which conferences we like. For me, one of the most interesting things about attending a conference is talking with other speakers. I like asking them what motivates them and how they prepare. Preparing a talk can often feel lonely, so it is nice to share what we learned and hear that many speakers face the same struggles.
Then I had a little break before some of the Tacon attendees and speakers went together to the restaurant the organizers had arranged.
Burger Heart
We had to wait a little bit for our food, which ofc made sense since many people from Tacon were eating at the restaurant. Then I got my smash burger with potatoes and coleslaw. It was really delicious and the perfect thing to end the interesting first day of Tacon. I had some beer.
I had more interesting discussions with other attendees. But after a long day and giving a talk myself, I noticed that I was getting tired quickly.
Second day at Tacon
On my second day at Tacon, I only watched two talks because I recorded my first podcast about Vitest Browser Mode for https://www.richard-seidl.com/en/podcast-software-testing/. It will probably be online in a few months.
The second keynote:
The second keynote was by Martin Heininger and August Weiss about using AI to go from requirements to generated tests. What I liked about the talk was that their approach was not just, “Give the requirement to an LLM and let it generate some tests.” They first use AI to analyse the requirement and find unclear or missing parts. After that, they apply normal testing techniques like boundary-value analysis, equivalence classes, or pairwise testing to generate structured test cases, and only in the last step turn those into executable tests.
For me, the interesting part was that AI is not replacing good testing methodology here. It is basically used to automate parts of an already good process. If your requirements suck, generating 100 tests with AI will not magically fix the problem. I think this is also a good lesson for coding agents in general: instead of only trying to make the model smarter, we should build better constraints, workflows, and validation around it.
Podcast
After that I joined my first Podcast with https://www.richard-seidl.com/en/podcast-software-testing/ where I talked about Vitest Browser mode. His Podcast has mostlye Qa Tester as a Audience so I hope a differnt View of a Software Develoepr would also be interessting for the Audience.
Traveling Back to Munich
After my 3 days at Leipzig I than did go back to the main station baught something to eat waited for my Train and travel back to munich. Luckly there was no problem with Train or Sbahn so arrived at home on time
Summary
As I said before, this was my first time as a speaker and attendee at a testing conference. The audience is different from an audience of web developers. There were developers there, ofc, not only testers. But what makes the testing community special is its range of backgrounds. There are many manual testers without a technical background. There are also testers with a technical background who can write automated tests themselves.
In November, I will give another talk to the testing community at QS Day in Frankfurt. This time, I will try to make it less technical and optimize it for the audience there.
I have always believed that every developer and BA should learn the skills that good QA engineers have. Most projects do not have a separate QA team or person. Ofc, you could argue that a lot of software sucks and is buggy because we do not value QA engineers enough.
Moving forward with AI, I believe many roles will merge. The second keynote made me want to learn more about the testing techniques behind those workflows. It did not show that separate roles would disappear. For me, the next step is to learn from QA engineers and apply more of their methods in my own work. It therefore makes sense for everyone to improve at the QA part of their work and learn from QA engineers.