
Sign up to save your podcasts
Or


Ein Lasttest ohne Frage dahinter ist verschwendete Lebenszeit, sagt Stephan Schwarz, und genau darüber spreche ich mit ihm: Lasttests in Kubernetes-Umgebungen, die eine Risikofrage beantworten und eine Entscheidung vorbereiten. Stephan erklärt, warum Dev, Ops und QA dafür an einen Tisch müssen: Kein Team allein weiß, wie sich die Software unter Last verhält. Wir reden über Laborsetups, in denen Autoscaling und Load Balancing erst mal zurückgefahren werden, über Lastgeneratoren wie k6 oder Locust und über seinen ersten Test 2018, bei dem der limitierende Faktor sein eigenes Notebook war. Und darüber, dass jedes System ein Bottleneck hat, auch wenn es noch keiner gefunden hat.
„Wenn ich nicht teste mein Produkt, dann macht es mein Kunde.“ - Stephan Schwarz
Stephan Schwarz ist Senior DevOps Consultant bei der iits-consulting GmbH und beschäftigt sich schwerpunktmäßig mit der Entwicklung und dem Betrieb Kubernetes-basierter Plattformen.
Dabei interessiert ihn nicht nur die technische Umsetzung, sondern vor allem die Frage, wie Plattformen, Anwendungen und Prozesse gestaltet sein müssen, damit sie zu den Menschen passen, die sie entwickeln, nutzen und betreiben. Themen wie Performance- und Lasttests betrachtet er deshalb nicht als isolierte Aufgabe eines Test- oder Betriebsteams, sondern als Teil gemeinsamer Verantwortung für zuverlässige Software.
Sein Ziel ist es, Nachhaltigkeit und Pragmatismus miteinander zu verbinden und Lösungen zu bauen, die langfristig funktionieren – ohne dass ihre Nutzer, Entwickler oder Betreiber anschließend therapeutische Unterstützung brauchen.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Ob ein Kernel auf jeder CPU-Generation läuft, zeigt erst die echte Hardware. Genau dafür hat Markus Napierkowski mit seinem Team ein Hardware-in-the-Loop-Framework gebaut, das seit zwei Monaten Open Source auf GitHub liegt, und darüber spreche ich mit ihm auf der TACON in Leipzig. Entwickler und CI reservieren sich dieselben Testmaschinen über eine REST API, sauber initialisiert, als stünden sie neben dem Schreibtisch. An jeder Maschine hängt ein Raspberry Pi für USB, HDMI und serielle Konsole, eine neue Hardware ist auf der Softwareseite fünf Zeilen Code im Nix-Repository. Mich hat vor allem gefreut, dass hier jemand ein über Jahre gewachsenes Werkzeug zurück an die Community gibt.
„Ich kann mir als Entwickler jetzt eine Hardware reservieren und sie benutzen, als würde sie neben meinem Tisch stehen.“ - Markus Napierkowski
Markus Napierkowski hat Informatik in Dresden studiert und ist seit neun Jahren bei Cyberus Technology tätig. Angefangen hat er als Software Engineer mit der Entwicklung von Produkten auf Basis von Microkernels. Seitdem hat er an unterschiedlichsten Themen gearbeitet, von Virtualisierungstechnologie in Rust und Performance-Benchmarks über den Aufbau der internen Testautomatisierungs-Infrastruktur bis hin zur Beratung rund um Nix, NixOS und moderne Entwicklungsprozesse.
Heute ist Markus Head of Test Automation and CI bei Cyberus. Sein Fokus liegt auf Entwicklungsmethodik und Testautomatisierung sowie darauf, Partner bei der Verbesserung und Automatisierung ihres Software Development Lifecycles zu unterstützen.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Was taugen Tests, die 100 Prozent Coverage liefern, aber keine einzige Assertion enthalten? Mit Julius Mischok spreche ich über Mutation Testing: Ein Tool baut absichtlich Fehler in den Produktionscode ein, dreht Bedingungen um oder setzt Rückgabewerte auf Standardwerte und prüft dann, ob die Tests anschlagen. Bleiben sie grün, hat die Mutation überlebt und der Test ist wenig wert. Julius erklärt, warum diese alte Idee gerade jetzt zurückkommt, wo Agenten massenhaft Tests schreiben, die kaum jemand wirklich in der Tiefe liest.
„Wenn der Test danach noch grün ist, ist es verkehrt, weil dann ist der Test schlecht." - Julius Mischok
Julius Mischok ist Gründer und Geschäftsführer der Mischok GmbH. Mit seinem Team setzt er Softwareprojekte um, die für die mittelständischen Kunden geschäftskritisch sind. Seine Erfahrung aus mehr als 20 Jahren Softwareentwicklung gibt er als Speaker, Autor von Fachartikeln und als Dozent in der Mischok ACADEMY weiter.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Wer schreibt noch selbst Code, wenn Agenten das in Minuten erledigen? Mit Benedikt Stemmildt spreche ich darüber, wie Qualität entsteht, wenn nicht mehr Menschen, sondern Agenten die Hauptarbeit am Code übernehmen. Wir reden darüber, warum der entscheidende Unterschied nicht im Modell liegt, sondern darin, ob man am System arbeitet oder im System: Hooks, Regeln, Skills und automatische Architektur-Reviews als Feedbackschleifen, die den Agenten genau so anlernen, wie man einen neuen Kollegen einarbeitet. Benedikt zeigt, wie er Testpyramide, Contract-Tests, Performance-Budgets und Accessibility-Prüfungen direkt in diesen Prozess einbaut, und warum er Codex den Code von Claude reviewen lässt.
„Ich arbeite viel mehr am System als im System." - Benedikt Stemmildt
Benedikt Stemmildt ist seit seiner Kindheit Technologe. Seit zwanzig Jahren geht es ihm um eine Sache: dass Entwickler Spaß an ihrer Arbeit haben. Er war Entwickler, Architekt und CIO, bevor er hackers&wizards mitgegründet hat. Dort unterstützt er Engineering-Teams dabei, ihre Software Factory zu bauen. Er ist Program Chair der code.talks in Hamburg und kuratiert die CASE in Berlin, die erste Konferenz für Agentic Software Engineering in Deutschland. Seit 2014 bringt er bei der Hacker School Kindern das Programmieren bei. Im November erscheint sein Buch "Building the Software Factory" bei Packt, zusammen mit Alex Merced.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Mehr Code, mehr Fehler: Mit Benjamin Hummel spreche ich darüber, was passiert, wenn KI-Agenten Code produzieren schneller als Teams ihn prüfen können. Wir reden über die Illusion, dass Qualitätssicherung ein Bottleneck ist, den man einfach wegoptimiert, und was das für Systeme bedeutet, die in der echten Welt laufen.
„Wenn ich doppelt so viel Code schreibe, habe ich statistisch doppelt so viele Fehler." - Benjamin Hummel
Dr. Benjamin Hummel hat im Bereich Software Engineering promoviert und zu den Themen Softwarequalität und -wartbarkeit geforscht und publiziert. Seit über 20 Jahren entwickelt er aktiv Methoden und Werkzeuge für die Qualitätsverbesserung von großen Softwaresystemen. Als Mitgründer und CTO der CQSE GmbH verantwortet er seit über 10 Jahren die Entwicklung und den Betrieb der Software-Intelligence-Plattform Teamscale.
Highlights:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Wer steckt eigentlich hinter den Testing Boards, wenn die Tester gerade nicht hinschauen? Mit Andrea Kränzlein spreche ich darüber, was es bedeutet, als Backoffice die drei deutschsprachigen ISTQB-Vertretungen am Laufen zu halten, und zwar seit mittlerweile 20 Jahren beim German Testing Board, plus jeweils über einem Jahrzehnt für das Austrian und das Swiss Testing Board. Andrea ist keine Testerin, und gerade das macht ihren Blick auf unsere Community sointeressant. Sie erzählt, wie sie ihr erstes Meeting mit lauter schweigenden Laptopnutzern erlebt hat, was eine Kuhdose mit Timeboxing zu tun hat und wie sich Deutsche, Österreicher und Schweizer in ihrer Boardarbeit liebevoll karikiert unterscheiden. Vielleicht hast Du dann ja Lust, selbst in den Boards mitzuarbeiten :-)
„Wir haben alle irgendwann mal angefangen. Und wir haben nicht mit 100% angefangen." - Andrea Kränzlein
Andrea Kränzlein gründete vor 30 Jahren OFFICE-MANAGEMENT mit einer klaren Vision: Unternehmen im Office-Bereich professionell zu entlasten und ihnen den Rücken für ihr Kerngeschäft freizuhalten. Das Zauberwort damals wie heute: Outsourcing.
Was als klare Idee begann, ist über drei Jahrzehnte zu einem branchenunabhängigen und vielseitigen Leistungsspektrum gewachsen. Dabei verbindet sie langjährige Erfahrung mit einem ausgeprägten Gespür für individuelle Anforderungen, zuverlässige Strukturen und effiziente Lösungen.
Ein besonderer Schwerpunkt hat sich im IT-Umfeld entwickelt. Seit mehr als 10 bis hin zu 20 Jahren vertrauen die ISTQB Boards aus Deutschland (GTB), Österreich (ATB) und der Schweiz (STB) auf ihre Unterstützung. Langjährige Geschäftsbeziehungen wie diese stehen für das, was OFFICE-MANAGEMENT auszeichnet: Verlässlichkeit, Kompetenz und nachhaltige Zusammenarbeit.
30 Jahre Erfahrung bedeuten eben mehr als nur Zeit: sie bedeuten Vertrauen, gewachsene Partnerschaften und die Fähigkeit, immer genau dort zu unterstützen, wo professionelle Entlastung gebraucht wird.
Highlights:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Hartnäckige Qualitätsprobleme, an denen Unternehmen seit Jahren kauen, löst man nicht mit einem 15-seitigen Assessment-Dokument. Mit Pia Wiedermayer und Roman Kirchmeier spreche ich über das Format "Quality Sprint": ein kompakter Workshop-Tag, bei dem alle Betroffenen an einem Tisch sitzen, in strukturierten Interviews zuhören, was die anderen wirklich beschäftigt, und am Ende konkrete Schritte definieren, die tatsächlich im eigenen Wirkungsbereich liegen. Was mich dabei besonders beschäftigt: die Interviews finden bewusst in der großen Runde statt, denn oft genug merken alle erst dabei, dass sie eigentlich über dasselbe Problem reden. Wie der Transfer danach klappt und warum das Follow-up mindestens so wichtig ist wie der Workshop-Tag selbst, erzählen Pia und Roman aus ihrer gemeinsamen Erfahrung mit den Quality Elevators.
Wir werden nicht die Welt bewegen in einem Tag, aber wir haben dann konkrete drei, vier Steps, die wir mitnehmen." - Pia Wiedermayer, Roman Kirchmeier
Pia Wiedermayer arbeitet als Organisationsentwicklerin und IT-Strategin an der Schnittstelle von Produkt und Technik, wobei sie als zertifizierte Business- und Team-Coachin auf tiefgehende systemische Wertearbeit setzt. Roman Kirchmeier bringt über 15 Jahre Erfahrung im Leadership von Qualitätsteams sowie tiefe Expertise in Performance Engineering und Observability ein.
Gemeinsam mit drei weiteren Qualitäts-Expert:innen bilden sie das Kollektiv der Quality Elevators und unterstützen Unternehmen dabei, den lähmenden Wartungsmodus zu verlassen und kontinuierliche Lieferfähigkeit zu etablieren. In ihrem kollaborativen Quality Sprint Workshop brechen sie operative Silos zwischen IT, Business und Produkt auf, um in nur einem Tag glasklare Muster offenzulegen und messbare Action Items abzuleiten. Technologie ist für sie kein reiner Selbstzweck, sondern das Fundament für menschlichen und unternehmerischen Erfolg. So vereinen Roman und Pia “Hard Facts” und “Soft Systems” zu einem unschlagbaren Fundament für echte, nachhaltige Software- und Prozessqualität.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Kann man mit 100% Branch Coverage wirklich sicherstellen, dass Code fehlerfrei ist? Mit Roger Butenuth spreche ich darüber, was passiert, wenn man dieses Ziel konsequent verfolgt, und zwar nicht als theoretische Übung, sondern an einem echten, selbst geschriebenen Interpreter für eine Lisp-ähnliche Sprache. Roger erzählt, welche peinlichen Fehler er dabei entdeckt hat, darunter eine handfeste Sicherheitslücke an einer Stelle, die er für zu trivial hielt, um dort einen Bug zu vermuten. Und trotzdem blieb am Ende noch ein Bug übrig, der erst beim Advent of Code auftauchte.
„Man macht Fehler an Stellen, wo man denkt, nein, das ist zu trivial, da ist kein Fehler." - Roger Butenuth
Dr. Roger Butenuth arbeitet seit 2012 bei der codecentric AG mit den Schwerpunkten Integration und Architektur. Weiterhin interessieren ihn Themen rund um Performance und Parallelität.
Highlights:
Weitere Links zur Episode:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Wer automatisiert testet, baut auf Determinismus, auf Konsistenz, auf klare Erwartungen. Mit Anupam Krishnamurthy spreche ich darüber, warum genau das bei LLMs nicht funktioniert und was wir stattdessen brauchen. Wir gehen der Frage nach, wie man einen Chatbot testet, der nie zweimal die gleiche Antwort gibt, warum ein LLM ein anderes LLM beurteilen kann und wo das an seine Grenzen stößt. Anupam erklärt, wie RAG-Systeme sich in Retrieval und Generation zerlegen lassen, und warum die meisten Fehler im Retrieval stecken.
„Die meisten Probleme liegen im Retrieval." - Anupam Krishnamurthy
Anupam Krishnamurthy ist Head of AI Testing bei der TestSolutions GmbH, wo er die Bemühungen des Unternehmens leitet, beim Testen im Zeitalter von KI-gestützter Softwareentwicklung an der Spitze zu bleiben. Er ist Mitgründer der BeyondQuality-Community und Co-Host des dazugehörigen Podcasts.
Anupam ist ein Manager, der zum Softwareentwickler wurde — ein bunter Karriereweg, der ihn zu den Grundlagen zurückführte. Er begann als Maschinenbauingenieur, der in Indiens Raumfahrtprogramm Satelliten zusammenbaute, machte einen MBA, arbeitete als Strategieberater und stellte dann fest, dass ihm Programmieren mehr Spaß macht als PowerPoint. Zuvor war er als Test-Automation-Engineer und als freiberuflicher Berater tätig und half seinen Kunden, qualitativ hochwertige Software schneller auszuliefern.
Ursprünglich aus Bangalore, Indien, und mittlerweile in Berlin zu Hause, findet man ihn in seiner Freizeit vertieft in eine Partie Online-Schach, beim Langstreckenlauf mit einem History-Podcast im Ohr oder beim Blues-Spielen auf seiner Akustikgitarre.
Highlights:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:
Was können wir von Bakterien und Motten lernen, um besser mit Unsicherheit umzugehen? Mit Anna Melbinger spreche ich darüber, wie Strategien aus der Natur auf Softwareprojekte und Projektmanagement übertragbar sind. Anna bringt einen ungewöhnlichen Hintergrund mit: Jahre in der Wissenschaft, Physik studiert, biologische Fragestellungen mit Mathematik bearbeitet, und heute im IT-Projektgeschäft. Wir reden darüber, warum Stillstand keine Robustheit erzeugt, warum Bug-Trends oft aussagekräftiger sind als einzelne Bugs, und wann es sich lohnt, bewusst einen Schritt zu tun, der nicht direkt zum Ziel führt, nur um Wissen zu gewinnen. Am Ende landet das Gespräch bei Karl Popper und der Frage, ob das aktive Suchen nach Widerlegung eigentlich die ehrlichste Methode ist, mit komplexen Entscheidungen umzugehen.
„Manchmal lohnt es sich bewusst innezuhalten. Schritte zu tun, nur um Wissen zu generieren." - Anna Melbinger
Bevor Anna Melbinger in die IT wechselte, forschte sie viele Jahre als biologische Physikerin an komplexen Systemen – unter anderem an der LMU München, am Institut Pasteur in Paris und an der UC San Diego. Dort beschäftigte sie sich mit der Frage, wie biologische Systeme unter Unsicherheit funktionieren, Entscheidungen treffen und robust bleiben.
Heute arbeitet sie seit über zehn Jahren im IT-Projektmanagement und begleitet anspruchsvolle Digitalisierungs- und Transformationsprojekte. Immer wieder erkennt sie dabei überraschende Parallelen zwischen Projektarbeit und biologischen Mechanismen.
In ihren Vorträgen verbindet sie wissenschaftliche Tiefe mit praktischer Erfahrung – und zeigt, warum Orientierung, Anpassung und Robustheit oft wichtiger sind als perfekte Planung.
Highlights:
📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen
Danke an die Community-Partner des Podcasts:Alliance for Qualification | ASQF | Austrian Testing Board | dpunkt.verlag | German Testing Board | German Testing Day | GI Fachgruppe TAV | Heise | HANSER Verlag | ISTQB | iSQI GmbH | oop | QS-TAG | SIGS-DATACOM | skillsclub | Swiss Testing Board | TACON Credits: Sound | Grafik
From the publisher's feed