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

June 11AI in Regulated Industries: Strategy First in a Medical Lab - Alexis Savkin
How to make AI work in a regulated medical lab, step by step
How do you bring AI into a medical lab when the regulatory landscape is still taking shape? With Alexis Savkin I talk about exactly that tension, and the answer turns out to be less about technology than about focus and strategy. We get into why starting with a very specific, measurable problem makes the regulatory side manageable, and how a single-page risk diagram convinced compliance stakeholders faster than any technical pitch. I keep coming back to his point that regulators are not enemies but partners trying to make things safer, and that the real mistake is trying to solve "AI" as one giant problem instead of one concrete thing at a time.
"Regulators are not our enemies. They are our friends and they're trying to make our life safer." - Alexis Savkin
Alexis Savkin is a Senior Strategy Consultant and the CEO of BSC Designer, a Balanced Scorecard platform. He has more than 20 years of experience in the field, with a background in applied mathematics and information technology. Alexis is the author of the “Strategy Implementation System”. He has published over 100 articles on strategy and performance measurement, regularly speaks at industry events.
Highlights:
Focusing AI integration on one specific, bounded problem makes regulatory compliance tractable, because regulators can analyze a narrow scope where a broad implementation gives them no choice but to refuse.
A non-deterministic AI layer can produce deterministic outcomes when wrapped in the right controls, just as internet protocols deliver reliable communication over inherently unreliable packet transmission.
Bow tie risk analysis condenses the entire compliance picture onto a single page, making threats and controls visible to technical staff, compliance stakeholders, and regulators simultaneously.
Stakeholder needs must be quantified, not just named: specifying required precision, acceptable timeframes, and tolerable risk levels is what makes a strategy actionable rather than aspirational.
Architecture decisions made early either enable or block the transition to agentic AI later, so long-term structural thinking at the outset prevents expensive migration work down the road.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
22 min
June 04COBOL Unit Testing: Java Tests Run as Debugger Scripts - Bartosz Filipek, Szymon Wałachowski
When no IBM tool fits, two engineers built their own testing layer
What happens when 40 years of custom decisions stack so high that even the standard testing tools from your own vendor stop working? With Bartosz Filipek and Szymon Wałachowski I talk about exactly that situation: a mainframe environment so deep in its own customization that the only way forward was to build one final bridge to the outside world. We dig into how they created a Java-based unit testing tool for COBOL developers, and what surprised me most is that COBOL programmers find it easier to write assertions in Java than in their own first language. We also get into code coverage, integration with tools like SonarQube and X-ray, and the long road of getting something as basic as a service account approved.
"The ultimate goal is to make people's life easier." - Bartosz Filipek
Szymon Wałachowski(https://www.linkedin.com/in/walachowski/) is a Senior Software Engineer, Professional Nerd, and part-time QA team member (the plot twist nobody saw coming).
He has broken things in JavaScript, Blockchain, ML, JVM, and Mainframes — which taught him to love QA so much that he now builds testing tools to help with modernization.
He enjoys modernizing legacy systems than build from scratch — because making ancient code dance with modern APIs while everyone says „that’s impossible” is his idea of fun.
Bartosz Filipek is an IT Architect with over 10 years of experience in software development, specializing in Java, Scala, and TypeScript. Passionate about automation and fostering strong collaboration between development teams and customers, he places a strong emphasis on quality assurance and testing.
In recent years, his focus has shifted toward architectural design and guiding teams toward future-ready solutions, while leveraging his extensive background in backend, frontend, and DevOps.
Highlights:
Building one final, well-designed customization layer that bridges a legacy environment to standard tooling is more sustainable than letting ad-hoc customizations accumulate indefinitely.
COBOL developers found it easier to write unit test assertions in Java than in COBOL itself, because the Java API was designed so that no prior Java knowledge is required.
When a unit testing capability is missing in a legacy stack, the absence cascades: reporting, release validation, and integration with tools like SonarQube and X-Ray all become blocked as a consequence.
Code coverage for COBOL programs is technically achievable through the IBM debugger's built-in line-tracking option, without requiring a custom implementation.
More Links with Insights:
Testwarez Conference
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
24 min
May 28Chatbot Testing: Why Bugs Hide in Prompts and Retrieval - Dušanka Lečić
From prompt failures to hallucinations: what breaks in AI testing
This time I talk with Dušanka Lečić about why testing chatbots breaks everything we know about traditional QA. She explains how chatbot bugs are invisible – they hide in prompts, retrieval logic, and chunks, not in code – and why the same input can produce dozens of valid outputs. Dušanka shares her framework for testing context retention, hallucination control, and accuracy, and reveals why stress testing a chatbot means checking for typos and user frustration, not system load.
"For the same input we have a lot of different outputs, some of them can be similar, but yeah still non-determinism is completely there." - Dušanka Lečić
Dušanka Lečić is a dynamic leader and technical expert with nearly a decade of experience steering software testing initiatives across international teams. As a Test Lead and Department Manager at Levi9, she specializes in performance testing, agile methodologies, and engineering excellence. Holding a Ph.D. in Technical Sciences, Dušanka blends academic insight with real-world execution, and is a frequent contributor to industry conferences, mentoring programs, and expert communities. Her sessions offer a rich perspective on quality assurance, innovation, and leadership in fast-paced development environments.
Highlights:
Chatbot bugs are invisible in the traditional sense because they live not only in code, but in prompts, retrieval logic, and response generation, requiring a different debugging approach entirely.
Non-determinism in chatbot responses means multiple valid outputs exist for the same input, which breaks the classical pass/fail model and demands a wider definition of what counts as a correct test result.
Traceability in chatbot testing must cover chunks, retrieval results, and queries, not just the final response, because without that full log, root-cause analysis of a wrong answer is nearly impossible.
The CHAT framework structures chatbot testing around four concerns: context retention, hallucination control, accuracy and relevance, and a testing workflow that includes tracing, fixing, and retesting with similar queries.
Stress testing for chatbots means checking responses to misspellings, ambiguous terms, and bad wording that frustrated users produce, not measuring system performance under load.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
25 min
May 21AI-Assisted Testing: Testers Keep Control of the Process - Mitko Mitev
From test planning to defect clustering: where AI already saves you 30% effort
This time I talk to Mitko Mitev, about how AI is reshaping our work as testers, without replacing us. Mitko shows exactly where AI tools save real time across test planning, test case generation, and exploratory testing, and why human expertise remains non-negotiable for context, business logic, and validation. We go into the shift from writing scripts to instructing agents in plain language, how ISTQB's new AI syllabi prepare testers for what's coming, and why waiting another year to explore AI might already be too late.
"People should stop asking on interviews what's the difference between class and object. You should probably ask: What is MCP?" - Mitko Mitev
With over 30 years in software quality assurance and more than 20 years as a Project and Test Manager, Mitko Mitev is recognized as one of South East Europe’s leading software testing experts.
A dedicated advocate for the QA and testing professions, he has been instrumental in establishing and promoting international standards through his work with the ISTQB and as President of the South East European Testing Board (SEETB). Mitko also serves as Chief Editor of Quality Matters magazine and Chair of the SEETEST conference, both focused on advancing global best practices in software quality.
Today, Mitko continues to develop and refine educational materials, books, and articles that help professionals deepen their expertise in software testing. He is also the founder and owner of Quality House – a leading outsourcing and consultancy company with offices in Bulgaria, Serbia and Romania, proudly celebrating 21 years on the market and delivering world-class independent testing services.
Highlights:
AI challenges the tester's role by shifting mechanical and automation tasks to machines, but context, business logic, and user behavior prediction still require human control.
Generating test cases and test data are the highest-value AI use cases in testing today: a task that takes a human a month can be completed in roughly a week with AI support.
Business stakeholders can contribute directly to test automation when plain-language instructions replace scripting, widening the group of people who can drive test activities.
Scripting knowledge in languages like TypeScript or Python remains necessary because someone has to verify that AI-generated scripts actually do what they are supposed to do.
ISTQB offers two dedicated syllabi covering AI in testing: one on how to test AI products, and a newer one on how to use generative AI in day-to-day testing work, updated every three to six months.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
25 min
May 14How to Build QA Culture in Your Company - Filip Leszek Barszcz
Why your stakeholders, devs and PMs all mean something different by "quality"
In this episode, I talk with Filip Barszcz about what most companies get wrong when they claim to have a quality culture. Filip reveals why stakeholders, developers, and product owners all speak different languages when they say "quality" and how he translates between them to build actual buy-in for testing strategy. He walks through his playbook for introducing change without burning out the team: small wins first, honesty about short-term productivity drops, and color-coded tables that make executives eager to invest in QA. If you've ever struggled to get testing taken seriously beyond "just click through it before release," this conversation gives you the roadmap.
"The truth is that we are feedback givers for all the development teams." - Filip Barszcz
Filip Barszcz is a full-time QA Chapter Leader with over 10 years of experience in the IT industry.
Throughout his career, he has collaborated with renowned organisations such as SCIB (Santander Corporate & Investment Banking), T-Mobile, Capital.Com, and IQVIA.
He specialises in building and refining quality assurance processes, mentoring QA professionals, and fostering close collaboration between QA and development teams.
As a strategic QA leader, he has driven major organisational transformations — from building QA departments from the ground up to restructuring teams for greater efficiency and alignment with business goals.
He has successfully defined test strategy, designed automation architecture, and implemented multi-level testing — from unit to end-to-end coverage.
Highlights:
QA professionals are feedback givers for all development teams, not just testers, and that broader role is what makes quality improvement possible across an entire organization.
Introducing too many changes at once creates team fatigue and resistance; one significant change per quarter, fully measured before the next begins, keeps adoption stable.
Framing quality failures as financial cost, by calculating what a late-stage defect costs to fix, is the argument that moves business stakeholders from skepticism to willingness to invest.
Consulting everyone affected by a change before rolling it out, and letting them shape parts of it, turns potential resisters into partial owners who advocate for the new approach.
Visibility of QA work, through regular reports and status updates that use tables and clear metrics, closes the gap between what testers do and what management and stakeholders actually see.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
30 min
May 07Business Value of Testing: Translate Risk into Money - Marta Firlej
How to prove your testing work in money - before the next budget cut hits
In this episode, I talk with Marta Firlej about a topic most testers avoid: money. Marta explains why understanding how your company actually makes money is crucial for QA professionals, and walks through the real costs behind salaries, automation projects, and test activities that stakeholders care about. She shares a practical calculation method to assess whether test automation is worth the investment, and challenges us to translate testing value into business numbers.
"That's the goal of every company. Every company, government and country make money." - Marta Firlej
Marta Firlej is inventor and organizer of the testing conference test:fest in Wrocław Poland. Proud member of the Polish and European testing community by being an organizer of various events, sharing knowledge and experience as a speaker, and participating as an attendee.
Currently working as a Head of FS Testing Practice at Capgemini in Poland. Throughout her career, she worked on different positions always having quality in heart for different industries such as finance, healthcare, edutech, etc. Her favorite part is working with people.
Highlights:
Testers who cannot explain what a failed release costs in money will lose budget arguments, because managers treat testing as an abstract cost, not a risk mitigation tool.
Automation return on investment depends on maintenance costs and longevity: automating a product that may be cut or heavily revised in the near term produces negative value.
The real cost of an employee to a company is roughly double the gross salary, once employer taxes, benefits, bench time, and overhead are included.
Testers own the responsibility to produce quality reports and communicate risk proactively, because clients will not ask for information they do not know they need.
Understanding how a company earns money, who the key stakeholders are, and what decisions they make is a precondition for translating test results into business value.
More Links with Insights:
Testwarez Conference
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
19 min
April 30Trust in AI Agents Lives in the System Around the Model - Henri Terho
How to build trust into AI systems when they constantly change underneath you
In this episode, I talk with Henri Terho, senior consultant and AI enthusiast, about why building trust in AI systems requires the same rigor we've always applied to software—just now at a whole new level. Henri explains how AI agents multiply both our successes and our mistakes, why prompting is harder than it looks, and why testers are uniquely positioned to thrive in this shift. We dig into the oracle problem, the communication trap, and why your test suite might soon matter more than your codebase.
"AI doesn't think, it doesn't analyze, it predicts." - Henri Terho
Henri Terho is a Senior AI Consultant at Eficode with broad experience spanning regulated industries—automotive, banking, aerospace, and beyond—alongside a deep commitment to open-source collaboration. He has played a key role in fostering community-driven innovation, having served as chairman of Tampere Entreprenourship society and co-founding Tampere Tribe to support local startup culture.
Henri’s passion for AI, quality assurance, and rapid software development is evident in both his industry work and ongoing PhD research on agile product innovation. He frequently shares his expertise on stage and in publications, championing lean practices and the latest AI advances to empower organizations worldwide.
Highlights:
AI systems amplify both mistakes and successes at scale, so the checks, guardrails, and validation processes built around the model matter more than the model itself.
Testing AI requires a shift from deterministic pass/fail checks to monitoring trends and mean time between failures, because non-deterministic outputs cannot be verified with a single green test.
The communication problem with AI agents is structurally identical to the bug-report problem with humans: vague input produces generic, context-free output that misses the actual need.
As AI-generated code becomes a black box, test specifications and acceptance criteria become the primary source of truth, making the tester's skill set central rather than peripheral.
AI democratizes software creation by removing the need for programming knowledge, which surfaces long-ignored organizational problems such as document version control and missing single sources of truth.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
21 min
April 23Flaky Tests: Why They Destroy Trust in CI Pipelines - Simon Stewart
Managing Flaky Tests Strategies for Trustworthy CI Pipelines
In this episode, I talk with Simon Stewart, professional software developer and former lead of the Selenium project for over 10 years, about one of the most frustrating problems in software testing: flaky tests. Simon reveals why a flaky test isn't always a bad test – sometimes it's actually exposing real production risks that your team needs to address. We dive into practical strategies for handling flakiness in CI pipelines, from gatekeeping techniques used at Meta to knowing when it's actually okay to delete tests. You'll learn why assigning ownership to individuals (not teams) is crucial, and how to use test flakiness as valuable signal rather than just noise.
"A flaky test can actually sometimes be a good test because it's highlighting things." - Simon Stewart
Simon Stewart has been a professional software developer since before the millennium began. He was the lead of the Selenium project for over a decade and is the co-editor of the W3C WebDriver and WebDriver Bidi specs.
As well as browser automation, Simon is also interested in monorepos, blazing fast byte-for-byte reproducible builds, and scaling software development efficiently. He draws on his experience working in Open Source, ThoughtWorks, Google, and Facebook. He was the tech lead of Facebook’s build tool team, and is currently working on projects using Bazel, for which he’s the maintainer of several rulesets.
Simon lives in London with his family and dog.
Highlights:
A flaky test breaks the foundational property of repeatability, and once developers stop trusting CI results, the entire value of continuous integration collapses.
Flaky tests sometimes expose real production risks: transient network errors, unavailable dependencies, and race conditions in tests are the same failures users will encounter in the live system.
Removing a flaky test from CI rotation is necessary but not sufficient; ownership must be assigned to a named individual, not a team, or the fix will never happen.
Meta's practice of running every new test a hundred times concurrently overnight before admitting it to CI is a concrete, automated gatekeeping strategy that prevents flaky tests from entering the build at all.
Deleting a flaky test is a legitimate resolution, especially when lower-level tests already cover the same risk, because shipping changes quickly and safely matters more than preserving test code.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
24 min
April 16Mobile Security: From Unencrypted Calls to Overlay Attacks - Bartosz Czernic-Goławski
Why your smartphone knows more about you than you think it does
In this episode, I talk with Bartosz Czernic-Goławski, a penetration testing and cybersecurity expert, about how mobile security has evolved from Nokia's indestructible brick phones to today's pocket-sized computers. We trace the journey from analog networks that anyone could eavesdrop on to modern smartphones that demand excessive permissions and collect sensor data every second. Bartosz reveals how attackers use overlay attacks to steal banking credentials, why iOS users aren't as secure as they think, and what phone freaks in the 1980s can teach us about today's vulnerabilities.
"Attackers know what apps we are working with, we are using, and they take advantage of it." - Bartosz Czernic-Goławski
Bartosz Czernic-Goławski is a non-functional tester with six years of professional experience, currently working at Pentacomp as a security auditor and penetration tester. He holds an Engineering degree in Telecommunications and a Master’s degree in Applied Computer Science with a specialization in Cybersecurity—both earned at the Warsaw University of Technology.
In his work, he focuses on the security testing of systems developed by Pentacomp, as well as conducting penetration tests and audits for external organizations. Commercially, he has tested mobile, web, and desktop applications, as well as IT and OT environments. He has had the opportunity to assess systems used daily by millions of people in Poland, as well as components of critical infrastructure.
He is also involved in delivering cybersecurity training, particularly related to secure working practices and compliance with requirements such as NIS2.
Highlights:
Analog mobile networks transmitted calls without encryption, making eavesdropping possible with nothing more than a nearby receiver, a vulnerability that drove the shift toward cryptographic standards in later generations.
Overlay attacks on Android exploit legitimate app permissions to place invisible input fields over login screens, capturing banking and social media credentials without the user suspecting anything is wrong.
Users accepting all app permissions without reading them, because convenience outweighs caution, is the primary mechanism attackers rely on to extract sensitive data from smartphones.
Governments have requested push notification metadata from platform operators, proving that data types widely assumed to be non-sensitive can still expose user behavior and associations.
Forcing older Android versions and legacy network technologies to remain supported, to serve users who cannot or do not upgrade, keeps known security weaknesses in active circulation across entire populations.
More Links with Insights:
Tracking NSO Group's Pegasus Spyware
The EU's DMA Directive and "European iOS"
The Dark Side of Accessibility and Overlays on Android
Guardsquare Resource Library
Detecting Location Spoofing
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
33 min
April 09Empowering Women in Software Testing - Line Thomsen
Why women testers still need to advocate louder than they should
In this episode, I talk with Line Ebdrup Thomsen, quality engineering manager, about why software testing attracts more women than other tech roles – and why that's still not enough. Line shares how she coaches testers to be assertive but kind, especially when they're the only woman or the only tester in a team of developers. We discuss what prevents women from speaking up, how curiosity and communication skills matter more than your degree, and why the next generation of leaders might still need a wake-up call.
"It doesn't matter what degree you have." - Line Ebdrup Thomsen
Line Ebdrup Thomsen is a driving force in modern quality engineering in Denmark, known for transforming how teams think about testing, leadership, and value delivery. As a Quality Engineering Manager at Accenture, she leads clients and teams through complex digital transformations, ensuring that quality becomes a strategic advantage, never an afterthought.
She plays an active role in shaping the future of the profession through her role as a board member in the Danish Software Testing Board (DSTB), where she helps elevate standards, disseminate knowledge and strengthen the testing community.
Line is also a co‑author of the ISTQB® Agile Test Leadership at Scale syllabus, bringing clarity and guidance to organizations navigating the challenges of scaling agile practices.
With a passion for people, quality culture, and practical excellence, she empowers teams to build better products and stronger collaboration - one iteration at a time.
Highlights:
Communicating quality status assertively but with kindness is a core tester skill, because critiquing someone's work without triggering conflict requires deliberate framing of the product as a shared effort.
Testers who talk openly about what they are doing and where they want to go give managers the information needed to advance their careers, a habit that works even when it is not consciously strategic.
A testing background is not tied to any specific degree: geology, music, and cultural studies graduates have all proven to be strong testers, because curiosity and the drive to take things apart matter more than formal credentials.
Women entering tech still encounter the assumption that being a tester and being female signals weaker technical knowledge, and countering that assumption requires actively demonstrating understanding rather than waiting for it to be presumed.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
25 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