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

August 28, 2025Cross-Functional Teams Need a Clear Owner for Quality - Gitte Ottosen
Are Cross-Functional Teams Really Working? Deep Skills vs. Shallow Roles in Agile
In this episode, I talk with Gitte Ottosen about cross functional teams, quality engineering, and how deep skills fit in agile work. We question the Everyone owns quality mantra. If all own it, who does the hard parts. Gitte calls out mechanical agile and the comb shape myth that makes people wide and shallow. We talk about what Scrum expects from a team and why testers still bring sharp value. AI may take easy tasks, yet we need critical thinking and solid test design to judge its output.
"When we expect that everybody is supposed to do everything, then nobody does anything really good." - Gitte Ottosen
Gitte Ottosen is a test manager and quality coach with a strong focus on a value driven approach to software development. She has 30 years of experience in IT, primarily within test, test management and process improvement, in both traditional and agile contexts. She is focusing on supporting a quality mindset across teams and organizations in Denmark. As a self-confessed test and agile evangelist who preaches the need for a strong quality and value driven focus, Gitte is a strong advocate for a context-driven approach, a role requiring profound professional insight, passion, and persistence—qualities that she holds in abundance. Gitte is a dedicated trainer within the areas of agile and test and is a regular speaker at international conferences.
Highlights:
Saying everyone is responsible for quality without a named owner means no one takes ownership, and most agile teams lack the testing competence to carry that responsibility collectively.
Broad skill profiles, the so-called comb shape, produce shallow expertise across the board; two or three deep competences per person is the realistic ceiling for genuine excellence.
Reviewing AI-generated test output without understanding test design techniques adds no value, because you cannot spot what is wrong or missing if you do not know what the correct output should look like.
Testing context determines the tester's contribution: someone without a technical background delivers most value upstream, shaping acceptance criteria and process models, not downstream in the pipeline.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
32 min
August 21, 2025Nonviolent Communication in Testing: Observe, Don't Judge - Maroš Kutschy
From Blame to Clarity: Enhancing Team Conversations
In this episode, I talk to Maroš Kutschy, a QA technical lead passionate about automation testing and self-improvement. We go into the topic of nonviolent communication and its impact on tech teams. Maroš explains its four core components: observations, feelings, needs, and requests. We discuss how simple changes in language can greatly improve team dynamics and communication. For example, he illustrates how expressing yourself without blame opens up clearer dialogue.
"So yes, there is a lot of communication for testers." - Maroš Kutschy
Maroš is QA Technical Lead at Ness Košice, Slovakia. His hobby is automation testing. He likes leading and mentoring colleagues, learning new automation testing framework and helping people to enter the world of testing. In 2022 he was speaking at ‚Testing United‘ in Prague, ‚Nordic Testing Days‘ in Tallinn, ‚Tacon‘ in Leipzig, ‚HUSTEF‘ in Budapest, and ‚Test Dive‘ in Cracow. In 2023 he was speaking at ‚Software Quality Days‘ in Munich, 'HalfStack' in Vienna, 'SEETEST' in Bucharest and 'SANAE BEER.EX' in Bratislava. He likes self-improvement and leadership books, stoic philosophy, and exercising in the gym.
Highlights:
Mixing evaluation with observation is a form of communicative violence: saying "John procrastinates" is an evaluation, while "John delivered fixes on the last day of the sprint for two sprints" is an observable fact a manager can act on.
Saying "you disappointed me" shifts emotional responsibility onto another person; nonviolent communication reframes this as "I was disappointed because I needed to discuss open questions," keeping ownership with the speaker.
Feelings and non-feelings are distinct: "I feel ignored" describes how you interpret someone else's behavior, while "I feel frustrated" names an actual internal state and communicates it honestly.
Vague requests block action; a request like "send me automation reports more often" leaves the recipient guessing, while "send me reports on Monday, Wednesday, and Friday" gives a clear, executable instruction.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
23 min
August 14, 2025Teaching Test Automation: Hands-On Labs Before Theory - Dmitrij Nikolajev
Engaging Students in Software Testing: From Test Automation to Motivation
In this episode, I talk with Dmitrij Nikolajev about teaching software testing to the next generation. Dmitrij, who balances roles at InSoft and Vilnius University, shares his approach to making software testing engaging for students. He focuses on practical, hands-on experience, using tools like Postman and Selenium to teach automation and performance testing. Dmitrij redesigned his course to appeal to both new learners and those already in the industry. He leverages real-world examples to highlight the importance of testing, encouraging students to understand the consequences of failures. We also talk about the role of AI tools like ChatGPT in the learning process and their impact on student progress.
"Ideally, I would love to see one day a full bachelor program on software testing." - Dmitrij Nikolajev
Dmitrij Nikolajev has built his career in test automation, requirements engineering, and IT project management, with a proven track record in designing and managing mission-critical IT systems. Dmitrij serves as Head of Business Unit at Insoft, where he focuses on developing the professional skills of testing teams, ensuring the success of testing activities, and driving the delivery of high-quality IT services and solutions. In parallel, Dmitrij is a Testing Lecturer at Vilnius University (Lithuania), where he bridges academic knowledge with practical experience by researching and teaching software testing to computer science students and preparing them for careers in the IT industry.
Highlights:
Introducing test automation and performance testing before test plans keeps students engaged because they experience what testing does before learning what it is called.
Students using AI tools like ChatGPT to write automation code is not a problem to block but a skill to develop: the course responds by raising exercise complexity to match the faster pace.
Codeless test tools are not truly codeless, because complex scenarios still require custom code, which means knowing how to write and evaluate code remains a core skill for testers.
Graduated difficulty in lab exercises, where early tasks are easy enough to score points immediately, builds motivation that carries students through harder stages later in the course.
Assigning students to research real software failures and present them to classmates, rather than to the lecturer, creates healthy peer competition and makes the cost of poor quality concrete.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
28 min
August 07, 2025Resistance to Change: Turn Skeptics into a Resource - Mary Lynn Manns
Let's explore why great ideas often face resistance.
In this episode, I chat with Mary Lynn Manns about the ever-tricky topic of change in tech. Mary Lynn is a consultant, pushing ideas forward despite resistance. We explore why good ideas alone often aren't enough and why change can falter when we rely solely on logic and ignore emotions. We discuss how to effectively engage skeptics and build emotional connections that go beyond simple presentations. Mary Lynn shares practical techniques for leading change from any role, aiming to minimize resistance and maximize impact.
"If you don't manage the people, if they don't feel seen and heard, your change is constantly going to be ambushed." - Mary-Lynn Manns
Mary Lynn Manns is an independent consultant based in Asheville, NC. Her background includes university teaching and she is now a Professor Emerita at the University of North Carolina Asheville. She has done numerous presentations and workshops on the topic of change at conferences and in organizations that include Microsoft, amazon.com, Procter & Gamble, Apple, and Avon.
Highlights:
Skeptics in a change process hold information that change advocates cannot see, because enthusiasm blinds advocates to gaps and risks the skeptic spots.
Presenting problems without solutions labels a person as a problem-bringer, which causes listeners to disengage before any real dialogue can start.
Emotional connection moves people more reliably than information alone, because people resist data that contradicts their beliefs but respond to questions that let them feel the angst and the possibilities themselves.
Every change involves both a gain and a loss, and failing to acknowledge what people lose, even when that loss is unavoidable, prevents the emotional recognition that makes acceptance possible.
Bottom-up change sticks better than top-down mandates, and any person in an organization, regardless of formal authority, has equal capacity to lead that kind of change.
More Links with Insights:
Fearless Change
Fearless Change App
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
24 min
July 31, 2025Built-In Quality: Small Practices Beat Big Frameworks - Derk-Jan de Grood
How skills triumph over frameworks in effective Agile scaling
In this episode, I chat with Derk-Jan de Grood. We explore what it means to live agility beyond just following frameworks. Derk-Jan shares insights on scaling skills over frameworks and connecting strategy to team actions. We discuss common pitfalls where quality often falls through the cracks, particularly at the management level. There's a focus on breaking down testing and improvement into small, actionable practices. It's all about making Agile effective and meaningful.
"If you don't know when you're going to accept, how can I know what I need to test?" - Derk-Jan de Grood
Derk-Jan de Grood works as a Principal Consultant and Inspirator at InnSpire.
He helps organizations take the next step in their agile transformation and improve the flow of value delivery. As an Agile Transformation Consultant, RTE Coach, and Value Delivery Expert, Derk-Jan is passionate about optimizing the development process. He actively collaborates with leaders, RTEs, Scrum Masters, and Product Owners to co-create effective solutions. While he is not afraid to lead by example, his main goal is to empower people within the organization, help them grow, and encourage them to embrace agile values.
With his enthusiastic and engaging approach, Derk-Jan inspires the people he works with. He is a sought-after speaker at international conferences, a frequent columnist, and a regular contributor to various industry magazines. He shares his insights and experiences through his blog and his monthly podcast series. Derk-Jan is also the author of several bestselling books.
Highlights:
Breaking Built in Quality practices into the smallest possible skill containers makes improvement tangible enough for teams to act on, instead of staying paralyzed by the size of the whole.
A single tester working against five developers will always fall behind on execution, so moving that tester to test strategy and delegating execution to developers is a structural fix, not a compromise.
Agile frameworks like Scrum are vehicles for delivering value, not the destination. When the framework becomes the goal, the PI event matters more than its purpose.
Management is a root cause of quality gaps when acceptance criteria stay undefined, because a tester cannot scope work without knowing when the organization will sign off.
👉🏻 Click here for the prize draw
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
30 min
July 24, 2025When Property-Based Testing Pays Off, and When It Doesn't - Nikhil Barthwal
Unlocking the Secrets of Property-Based Testing
In this episode, I chat with Nikhil Barthwal about property-based testing. We go into how property-based testing can uncover the hidden bugs that often slip past human testers. With its capacity to automatically generate a multitude of test cases, this method helps us see beyond typical limitations. Nikhil also shares when property-based testing may not be ideal, like when it incurs high resource costs. He emphasizes that this approach serves as an assistant to testers rather than a replacement, enhancing productivity and reliability.
"When the system gets too complicated it is not possible for humans to write every test cases." - Nikhil Barthwal
Nikhil Barthwal is passionate about developing decentralized systems. He has several years of professional experience in large corporations as well as in smaller start-ups and acts as a mentor for various start-ups. He is also a guest speaker at various international conferences and gives talks on topics related to decentralized systems and software quality.
Highlights:
Property-based testing generates thousands of test combinations automatically from a formal description of system behavior, reaching failure modes no human-authored test suite can anticipate.
In distributed systems with many services, the number of possible failure combinations grows rapidly, making manual test case authorship impractical at scale.
The shrinker component is what makes property-based testing usable: it reduces a long generated failure sequence to the precise step where the fault occurred, so engineers can act on it.
Property-based testing becomes costly where each test execution consumes billable resources, such as cloud storage writes or live network calls, because automated test volume can spiral expenses out of control.
Introducing property-based testing in a large organization is primarily a cultural challenge: winning one willing team first, letting them advocate to peers, is more effective than a top-down rollout.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
27 min
July 17, 2025Security by Design: Why Custom Encryption Adds Risk - Eoin Woods
Making Security a First-Class Citizen
In this episode I talk with Eoin Woods about integrating security from the start of software development. Eoin, an expert in software architecture, explains why security often gets overlooked until the last minute. We explore why engineers find security daunting and discuss making it a standard part of development. Eoin shares design principles like defense in depth and cautions against custom security solutions.
"If you start thinking about security in the last 10% of your project, you're going to get 10% security." - Eoin Woods
Eoin Woods is an independent consultant in the fields of software architecture, green software and software engineering. He is formerly the CTO of Endava, where he was responsible for software engineering and capability development for over 10,000 delivery staff across the world. Prior to Endava he has developed databases, created security software and designed way too many systems to move money around. Outside his day job he is interested in software architecture, software security and sustainable (or "green") software. He is a regular conference speaker, has co-authored three books on software architecture and was the recipient of the 2018 Linda Northrup Award for Software Architecture, from the Software Engineering Institute at CMU
Highlights:
Security addressed in the last ten percent of a project produces ten percent security, making early involvement the only reliable path to a secure system.
Threat modeling is not a specialist-only exercise: any team can sit down, identify what is valuable in their system, and work out systematically who would want it and how they would attack.
Building custom security mechanisms, including encryption or authentication flows, introduces vulnerabilities that even expert-produced security technology routinely contains and that most teams lack the resources to find.
Failing to a secure state is a design obligation: when a component such as an audit trail or authentication service fails, the system must refuse to continue processing rather than default to an open position.
Testers are a natural forcing function for security awareness because questioning what can go wrong is their core skill, and involving them early surfaces bypassed security controls before they reach production.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
23 min
July 10, 2025Collaborative Software Design: Surface Assumptions Early - Kenny Baas-Schwegler, Gien Verschatse
Use collaborative software design to break down silos
In this episode I talk to Gien Verschatse and Kenny Baas-Schwegler about the challenges of collaborative software design, especially the disconnect between development teams and business stakeholders. Both Gien and Kenny shared stories of communication gaps, assumptions in requirements and the constant struggle to build shared understanding. They gave practical tips for breaking down silos and making modeling sessions actually work - not just as visual exercises, but as real opportunities for teams to learn together.
"We try to make it visual because then you focus the conversation on what's actually there, what's in front of you." - Gien Verschatse
Gien Verschatse is an experienced consultant and software engineer that specialises in domain modelling and software architecture. She has experience in many domains such as the biotech industry, where she specialised in DNA building lab services. She's fluent in both object-oriented and functional programming, mostly in .NET. As a Domain-Driven Design practitioner, she always looks to bridge the gaps between experts, users, and engineers.
As a side interest, she's researching the science of decision-making strategies, to help teams improve how they make technical and organisational decisions. She shares her knowledge by speaking at international conferences.
And when she is not doing all that, you'll find her on the sofa, reading a book and sipping coffee.
Kenny Baas believes in collaborative software design where ‘every voice shapes the software’. Leveraging a domain-driven design approach with Team Topologies, he facilitates clearer communication between stakeholders and software creators by collaborative modelling and deep democracy, decoding complexities, resolving conflicts and ensuring software remains agile to business demands.
As an independent software consultant and trainer, he is specialised in technical leadership, software architecture, and sociotechnical system design. He works with organisations and teams to design and build sustainable and resilient software architecture.
Highlights:
Assumptions made by developers who never talk to stakeholders reach production as working software, not just as misunderstandings on paper.
Collaborative modeling sessions work because every relevant role, including testers, architects, and business experts, builds shared understanding directly, cutting out the document-handoff chain.
Simple visual tools like event storming or example mapping outperform formal notations because participants contribute freely without learning a specialized notation first.
A 20-minute example mapping session on a single backlog item is enough to reveal whether acceptance criteria are clear or whether more discovery is needed before writing any code.
Teams that collaborate continuously with stakeholders and move directly to implementation reduce the knowledge loss that accumulates through tickets, refinements, and intermediary documents.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
40 min
July 03, 2025Team Autonomy: How Teams Solve Problems Together - Ben Linders
How to increase team autonomy?
In this episode, I talk to Ben Linders about what really drives team autonomy and effective software development. We get into team culture, the importance of psychological safety, and why diversity matters - not just as a feel-good topic, but as a genuine catalyst for change. Ben shares practical tips from his workshops, discussing how teams can move from being stuck to taking meaningful action. We discuss, how to avoid that sticky notes from retrospectives gather dust and how to make results visible, keeping actions manageable, and introducing a little bit of fun through gamification.
"If you have a good understanding, solving the problem is actually easy. The hard part is understanding it." - Ben Linders
Ben Linders runs a one-person business in Agile, Lean, Quality, and Continuous Improvement. Ben is a well-known speaker and author; he is much respected for sharing his experiences and helping others share theirs. His books and games have been translated into more than 12 languages and are used by professionals in teams and organizations all around the world.
As a trainer, facilitator, coach, and advisor, he helps organizations with effectively deploying software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers.
Highlights:
Psychological safety is destroyed faster than it is built: a single blame remark can undo weeks of trust, so facilitators must interrupt blaming the moment it appears.
If a team cannot generate at least three distinct solutions to a problem, the problem is not yet understood well enough, and exploration must continue.
Diversity in a team is a prerequisite for collaborative problem solving, because each person holds only part of the picture, and different views produce a richer, more accurate shared understanding.
Making retrospective actions visible on the daily task board, assigned to a person and framed as a testable experiment, is what separates actions that get done from sticky notes that stay untouched.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
27 min
June 26, 2025Holistic Testing: Quality Work at Every Stage of the Loop - Lisa Crispin
Creating a Quality Mindset and Build Better Software
In this episode, I talk to Lisa Crispin about holistic testing and what it really means for teams striving for better software quality. Lisa brings her experience to the conversation, sharing how testing is much more than a stage or a checklist - it’s a mindset that weaves through every part of the development process. We dig into the practical side: how teams can focus on both internal and external quality, the value of strong relationships, and the power of good questions. It’s clear: true quality comes from collaboration and curiosity, not just tools or process. There’s a lot for teams to rethink here.
"Nobody wants to read the documentation, although it is important." - Lisa Crispin
Lisa Crispin is a consultant, author and speaker based in Vermont, USA. She and Janet Gregory have co-authored four books, most recently Holistic Testing: Weave Quality Into Your Product. They have also developed two courses taught by training providers around the world.
Highlights:
Lack of shared understanding is the primary driver of rework: teams build and test a feature, only for the product owner to reject it because the requirement was never fully explored.
Holistic testing covers every stage of the development cycle, from evaluating business ideas in discovery through observing customer behavior in production, not only a dedicated test phase.
Risk assessment during planning prevents defects before a single line of code is written, yet many teams skip it even when they practice test-driven development and continuous integration.
Testers who build relationships with operations engineers, site reliability engineers, and designers gain visibility into production risks that never surface inside the delivery team alone.
A visual, collaboratively built test strategy on a mind map outperforms a written document because teammates engage with it, update it, and generate ideas they would not reach through reading alone.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
30 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