Software Testing Unleashed - QA, DevEx & Quality Engineering

By Richard Seidl | Software Development & Testing ExpertBusiness Technology Education Management

Software Testing Unleashed - QA, DevEx & Quality Engineering episodes

October 29Mental Skills: Testers Can't Outsource Their Brain to AI - Ard Kramer
If you don't use it, you lose it: what AI does to a tester's brain
Mental skills keep testers thinking when AI offers to do it for them, and Ard Kramer puts it bluntly: you can't outsource your brain. With him I talk about why an idle brain loses its connections, how his cue HAH (human, AI, human) keeps the thinking on our side, and which four skills get a tester into the flow: goal setting, visualization, self-talk and stress control. Ard turns the test goal around, because one passing test confirms nothing, so his hypothesis aims at the moment the payment interface fails. He also explains the Zeigarnik effect, why an open task keeps your subconscious busy overnight, and why AI works best as a critical partner that asks you the questions.
"You can't outsource your brain." - Ard Kramer
Ard Kramer is a software tester based in the Netherlands who blends philosophy with practice as a “Qualisopher”, which stands for combining curiosity, teamwork, and a drive to create meaningful impact. As a former volleyball coach and currently one of the seven board members of the Dutch Volleyball Federation, he brings team spirit, focus, and resilience into his work, treating testing as a team sport where communication and trust drive success. He applies “quality thinking” not just to software but also to team dynamics, personal development, and real-world systems, and sees testing as the way to gather relevant information about value and risks, which means it is about improving people, systems, and environments.
Highlights:
Ard Kramer holds that testers can never say a system works, only that they tried everything and found nothing that did not work.
Goal setting, visualization, self-talk and stress control are the four mental skills a tester can train, while concentration, motivation, confidence and arousal are the capacities already inside.
The cue HAH, short for human, AI, human, puts a person at both ends of every AI loop, thinking first and testing the output afterwards.
When AI takes over the thinking, use it or lose it applies to the brain. Unused connections disappear and are hard to rebuild.
Walking around raises brain activity and improves thinking, which makes movement the simplest form of stress control before a hard testing task.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
19 min
October 22Testing AI Models as Magic Boxes: Why Checks Fail - Michael Bolton
Michael Bolton on how to test LLMs you can neither control nor fully understand
Testing AI models means testing a magic box: nobody has the source code, and the behavior is neither controlled nor understood. Michael Bolton calls that strongly magical, and with him I talk about what follows from it. His principles are simple: if something matters very much, don't depend on magic, and if you use it anyway, responsibility demands that you test it and maximize testability. Simple output checks don't stand a chance against a language model, so testing becomes experiencing, exploring and experimenting, like peeling an onion. And Penn and Teller's clear plastic cups show why we fall for these models in the first place: the insight we see in their text comes from us.
"If something matters very much, you probably shouldn't depend on magic to get it." - Michael Bolton
Michael Bolton is a consulting software tester and testing teacher who helps people to solve testing problems that they didn't realize they could solve. In 2006, he became co-author (with James Bach) of Rapid Software Testing (RST), a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure.
Michael has over 30 years of experience testing, developing, managing, and writing about software. For over 20 years, he has led DevelopSense, a Toronto-based testing and development consultancy. Prior to that, he was with Quarterdeck Corporation for eight years, during which he managed the company's flagship products and directed project and testing teams both in-house and around the world.
Highlights:
Machine learning models are not developed by a conscious, intentional human; Michael Bolton compares them to strains from petri dishes. Nobody knows how they work, nobody has their source code.
Testing AI models with output checks is hopeless: that approach works for deterministic software developers understand and can instrument, and a large language model is neither.
Nothing that matters very much should depend on magic; a bot writing a funny poem for a party carries no risk, a bot giving medical advice carries a big one.
Anyone asking how to test LLMs without source code can still monitor inputs and outputs and know the training data, guardrails, context window and outside calls, which shrinks the magic.
Large language models fool us like a mentalist on stage, because patterns of text suggest insight while the insight comes from the reader making sense of the output.
More Links with Insights:
DevelopSense
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
29 min
October 15Dark Side of Testing: The Failures We Cause Ourselves - Bart Knaack
A CD full of production data, snapped in half, and what that says about test data
Testing is supposed to prevent failures in production, yet sometimes the test itself is what breaks things. Bart Knaack calls this the dark side of testing, and we talk about test data leaking out of poorly protected environments, test systems that give attackers a look at your code, and why testing in production needs a risk assessment of its own. Bart would rather ask questions than hand out checklists, because a ticked box stops people thinking. He also tells the story of a team with 10,000 end-to-end test cases that ended up needing only 50.
"If you can't bear the consequence of your test, don't test it." - Bart Knaack
Bart Knaack is an IT-professional, working in the field for over 25 years. He has had many different roles, mostly in QA-Testing. He has been working for many big corporates and is a frequently seen speaker at (international) conferences. Next to that he is also a PhD candidate at the Open University on the subject of process based assessment in software education.
With a solid background in IT for many years he has in depth knowledge of the different challenges the industry is facing at the moment.
Highlights:
Testing itself can cause failures: the dark side of testing covers leaked test data, exposed test environments and failing tests that touch production.
Non-depersonalized production data on a test system or a CD is ungoverned data; Bart Knaack broke such a CD rather than process it.
A test environment with weaker protection than production lets attackers study the code and reuse its flaws against the live system.
Testing in production needs its own risk assessment, ideally with a network engineer in the room who knows which environments are connected.
Ten thousand end-to-end test cases shrank to 50 after the team moved checks such as address validation into unit testing.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
20 min
October 08Quality Hunting: Testing for Information Instead of Bugs - Rik Marselis
Stakeholders want to know if the system is good enough, and a bug list rarely says so
Quality hunting grew out of Rik Marselis's frustration with bug hunting, and I wanted to know how it works when the goal is information about quality. Rik walks me through a session: teams of about four people, three hours of exploratory testing and a goal agreed up front by asking stakeholders what would help them sleep well at night. He explains why the report structure comes first, why the prize should stay small and why the point just before several sprints go to production suits a hunt well.
"Testing is not about finding bugs. Testing is about getting information about the quality level of your system." - Rik Marselis
Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He is a highly regarded presenter, trainer, author, consultant and coach who has supported many organizations and people in improving their quality engineering and testing practice.
Highlights:
Rik Marselis developed quality hunting out of frustration with bug hunting, because for him testing means getting information about the quality level of a system.
At the first quality hunt in a EuroSTAR test lab, one team found about eight problems and could still judge how well the system works for disabled users.
A quality hunting team has about four people, half the size of an average agile team, and a session lasts three hours or at most half a day.
Teams should sketch the structure of their report at the start, so the session fills that structure with the information their stakeholders need.
Shortly before a release that bundles several sprints is a good moment for a quality hunt; teams that ship every user story right away cannot fit it in.
More Links with Insights:
TMAP
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
19 min
October 01On-Site Testing Conferences: Why Networking Needs Presence - Okan Çakmak
How a risky one-time event in Istanbul grew into a conference that connects Europe and Asia
What does it take to turn a risky one-time event into a conference that testers travel across borders for? With Okan Çakmak I talk about how the Istanbul Software Testing Conference grew out of something missing: after the pandemic, the big Turkish testing events stayed online, and people lost the chance to meet, network and hug each other in person. He tells me how the team wondered whether 50 or 100 people would come, then welcomed 200, and how the "light in their eyes" of those first participants convinced them to keep going.
"Our main motivation is to see people with the light in their eyes when they leave here." - Okan Çakmak
Okan Çakmak is the founder and principal consultant of Padran Information Technologies and a co-founder of the Istanbul Software Testing Conference (ISTC). Based in Istanbul, he has more than 23 years of experience in software testing and quality engineering. He has helped organizations across Europe and the Middle East improve their test processes, test automation, performance testing, and service virtualization, particularly in telecommunications and financial services. As an ISTQB instructor, he enjoys sharing practical knowledge with testing professionals. Through ISTC, he helps connect the international testing community with practitioners in Türkiye. Outside work, he plays the clarinet.
Highlights:
The Istanbul Software Testing Conference started because Turkey's main testing events stayed online after the pandemic, leaving testers without a physical place to network and exchange ideas.
International participants made up 20 percent of the 2026 audience, and that share has grown with each edition since the first year drew 200 attendees.
Six program committee members reviewed every one of the more than 120 submissions for the third edition, a workload Okan Çakmak expects to outgrow as international submissions rise.
The conference will return from three parallel tracks to two, because participants reported that choosing between three sessions at once was too difficult.
Simultaneous translation runs in every track all day, so speakers can present in Turkish or English and no participant feels excluded by language.
More Links with Insights:
Padran Information Technologies
Istanbul Software Testing Conference (ISTC)
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
18 min
September 24You Need a Test Automation Strategy Before AI - Michaël Pilaeten
When AI removes your asserts and the pipeline stays green
What happens when AI ships poor quality faster, and nobody notices because the pipeline stays green? With Michaël Pilaeten I talk about why test automation without a clear strategy is a problem that AI only accelerates, not solves. We get into the question of what separates a tester from a test automation engineer, why those two roles need each other but are not interchangeable, and how chasing 100% coverage on millions of lines of legacy code can be a waste everyone agrees to quietly.
"An automated test rarely finds defects." - Michaël Pilaeten
Michaël Pilaeten is Head of Quality Engineering at SOFICO. He is an accredited trainer for various ISTQB and IREB courses, as well as an author, international keynote speaker and workshop facilitator.
Breaking the system, helping to rebuild it and giving advice on how to avoid problems in the first place: that sums up his work. With more than 20 years of experience in software consultancy across a wide range of environments, he has seen the best (and the worst) of software development. Today he guides consultants, partners and customers on their personal and professional path towards excellence.
Highlights:
Testers and test automation engineers are two distinct roles: testers explore and break products critically, while automation engineers translate requirements into automated cases, and conflating them weakens both.
AI-generated tests default to quantity over correctness, producing plausible-looking test cases with invented scenarios just to hit coverage targets, not because the scenarios are valid.
Automated tests rarely find defects; when a pipeline fails, teams blame the test rather than the code, which means real bugs hide behind green dashboards.
Replacing junior testers and developers with AI removes the learning path that produces senior engineers, creating a skills gap with no pipeline to fill it.
Convincing management to invest in test quality requires framing the argument around production incidents and customer risk, not coverage metrics they do not understand.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
23 min
September 17Agentic Systems in Testing: Why Humans Stay in the Loop - Nishan Portoyan
Nishan Portoyan on why 8 to 12 agents replace your entire test workflow
What separates a handful of agents from a real agentic system? With Nishan Portoyan I talk about exactly that line, and why most teams are still on the wrong side of it. We walk through a full testing pipeline where eight to twelve agents handle everything from requirement review to performance test conversion, and I keep coming back to the question of where the human has to step in and why the AI simply cannot replace that judgment. Nishan is direct about what these systems cannot do: they do not think, they gather information and hand it back, and anyone expecting otherwise will run into trouble fast.
"There is no intelligence in there. It's just gathering information and handing it over to you." - Nishan Portoyan
Nishan Portoyan is a tester with a passion for his work. Whether it’s planning, coordination, automation, or execution, there’s no area of testing he doesn’t enjoy. Thanks to his solid training as a computer scientist and his degree in business administration, Nishan knows how to act professionally as a bridge between computer science and business.
True to his motto, “If you love what you do, do it all the way or not at all,” he is deeply committed to the testing community in addition to his projects.
Highlights:
An agentic system is not a collection of individual agents given tasks by humans, but a goal-based ecosystem where agents orchestrate other agents autonomously.
Between 8 and 12 specialized agents can cover the full testing process, from requirement review through test case creation, automation, and performance testing.
AI cannot apply business rules or judge coverage the way humans do, so human oversight is not optional but structurally required at defined checkpoints throughout the agentic system.
Performance test cases cannot be reused from functional automation because the scope differs fundamentally: functional tests control a GUI like a human, while performance tests examine back-and-forth system communication at scale.
In data-protection-strict environments such as Switzerland, cloud-based AI tools like ChatGPT, Claude, and Gemini are not viable, and teams must run models such as Mistral or DeepSeek locally, for example via Ollama, on GPU-capable servers.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
29 min
September 10AI in Software Testing Raises the Value of Expert Testers - Olivier Denoo
Why expert testers will be needed more as AI writes more code
What happens to quality when anyone can generate code with a prompt but nobody checks whether it actually works? With Olivier Denoo I talk about why that question puts expert testers in a stronger position than many managers currently assume. We get into the real risk of AI that always sounds right, the edge cases a lost suitcase in Brussels reveals, and why the hardest unsolved problem in testing is still the same one Olivier ran into three decades ago: describing precisely what you want. The skills I keep coming back to in this conversation are business understanding, communication, and the ability to spot what the AI confidently got wrong.
"AI can do most of the parts of the testing process." - Olivier Denoo
Olivier Denoo has been, From May 2019 to April 2023, the president of the ISTQB and is now currently the Vice President of the ISTQB.
Olivier is also the President of the CFTL - the French ISTQB Board and official IREB, IQBBA and TMMi representative in France.
The CFTL is organizing the largest software testing conference in Europe (JFTL) with more than 1200 attendees.
He is also the Vice President of ps_testware SAS, the French subsidiary of the ps_testware group. His role is to develop business, recruit the local expert team, build sustainable partnerships, promote software testing and quality.
He is also involved in auditing test projects and organizations and provides high-level consultancy and support.
For nearly 30 years he is an international speaker who spoke at A4Q World Conference, Geekle QA, iSQE, Test-IT Africa; SQA-days; BA-days; JFIE; TestWarez; SEETEST; STF; Iqnite; JFTL; JMTL; JTTL; Analyst-days; Quality Week; Eurostar; Dasia…
He's also actively participating in the development of new certification schemes, like IQBBA (Business Analysis) or IREB (requirements engineering) and is co author of various books and articles on software testing
Highlights:
AI-generated output is correct often enough to look trustworthy, but the remaining faulty fraction, hallucinated references, invented requirements, fabricated test cases, causes real business damage if no human checks the result.
A tester who only runs pre-written scripts without understanding the underlying business is directly replaceable by AI; domain knowledge is what makes a tester hard to automate away.
Prompt engineering and requirements engineering are now core tester skills, because the fundamental problem of describing software behavior precisely and unambiguously has not changed in 30 years of the profession.
Communication skills are a critical gap in tester education: presenting data honestly, managing stakeholder expectations, and writing clear prompts all depend on abilities that engineering curricula do not teach.
More Links with Insights:
Oliviers Website
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
22 min
September 03Lean Management: Why Problem Analysis Beats Quick Fixes - Nirmala Saneechur
How spending more time on a problem means solving it fewer times
Why do we rush to fix problems before we actually understand them? With Nirmala Saneechur I talk about Lean management, what it means to deliver quality at the right time rather than just on time, and why spending a full day understanding a problem is not wasted time. We get into what waste really means in a software project, including the story of 15 features a client never used, and how working in silos creates the kind of back-and-forth that slows everything down.
"Waste is anything that does not bring value to the customer." - Nirmala Saneechur
Nirmala Saneechur is an experienced Test Manager based in Mauritius, with a strong background in software quality assurance and delivery. She specializes in defining testing strategies, leading high-performing teams, and ensuring quality across complex IT projects. Nirmala is the Secretary of the Mauritian Software Testing Qualifications Board (MSTQB), where she actively contributes to advancing the testing profession. She is also an engaged community member, playing a key role in organizing TestCon. A recognized local and international speaker, Nirmala has presented at DevCon, TestCon, and the A4Q Testing Summit, delivering sessions in both English and French. She holds a Green Belt in Lean Management, reflecting her commitment to efficiency and continuous improvement. Known for her collaborative leadership style and passion for quality, Nirmala is dedicated to strengthening testing practices and supporting the growth of the software testing community.
Highlights:
Rushing to a solution before understanding a problem means the same problem returns: time spent on root cause analysis eliminates recurrence, which spending time on a quick fix never does.
Waste in software projects is anything that delivers no value to the customer, including features built on time but never used by the people they were built for.
Lean is not a methodology layered onto agile, it is a mentality that runs underneath any working method, applicable to processes, tools, and daily habits alike.
Management buy-in is a prerequisite for sustained lean adoption: without it, the time required to understand problems gets cut before the mindset has a chance to take hold.
More Links with Insights:
Facebook
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
22 min
August 27Performance Monitoring: Set a 70% CPU Alert Before Failure - Rao Dhaligadoo
Slow systems bleed money before they ever crash
Slow systems don't just annoy users, they cost companies real money, and most teams only find out when the phone starts ringing. With Rao Dhaligadoo I talk about what it actually takes to catch performance problems before customers do. We get into how a 70 percent CPU threshold can trigger an automated chain of monitoring, ticket creation, and root cause analysis, and why that matters more than it sounds. Rao also shares what it feels like to spend 45 hours in a war room at a bank, watching a CIO walk in at 1 a.m. while the whole team sits in silence, and how that experience shaped the way he thinks about proactive testing.
"In a perfect world, they never see the loading spinner or the 404." - Rao Dhaligadoo
Vasudev Rao Dhaligadoo is a Quality Engineering Lead with over 10 years of experience driving test management, automation strategy, and QA capability across enterprise systems in banking, payroll, and large-scale platforms. He has led end-to-end testing initiatives, built scalable automation frameworks, and integrated quality practices into CI/CD pipelines to improve release confidence and delivery speed.
He is also a QA and Test Automation trainer, regularly mentoring engineers and delivering hands-on training on modern testing tools and practices. Passionate about advancing quality engineering, he focuses on combining test management, observability, automation, and AI-assisted insights to diagnose complex system issues and strengthen software reliability.
Highlights:
A 70% CPU or resource threshold triggers automated alerts before systems degrade to failure, keeping end users away from slowdowns and 404 errors entirely.
Slow systems cost real money even without full outages: a combined YouTube and Azure slowdown incident cost more than 70 million US dollars.
AI-powered monitoring tools like Datadog's Bits AI pinpoint the exact database query or API endpoint causing a performance issue, cutting analysis time from hours to minutes.
Database query optimization and load balancer configuration under high traffic are the most common root causes of production performance problems, based on Rao Dhaligadoo's field experience.
Reactive incident response without proactive monitoring forces teams into war-room situations, with one real case stretching to 45 hours before production was restored.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
18 min

About Software Testing Unleashed - QA, DevEx & Quality Engineering

From the publisher's feed

Software testing is no longer just a phase—it’s the foundation of modern engineering and your ultimate competitive advantage.

Share Software Testing Unleashed - QA, DevEx & Quality Engineering

Sign up to save your podcasts

Software Testing Unleashed - QA, DevEx & Quality Engineering

Software Testing Unleashed - QA, DevEx & Quality Engineering episodes

About Software Testing Unleashed - QA, DevEx & Quality Engineering