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

April 02Playwright: Python vs TypeScript, What Actually Differs - Maciej Kusz
Why Python might be the smarter choice for your Playwright tests
In this episode, I talk with Maciej Kusz, program chair of the Testwarez conference in Poland, about why Playwright doesn't have to mean TypeScript. Maciej has been using Playwright with Python for years and shows that Python testers can leverage the framework just as effectively—if they know which PyTest plugins to use and where the documentation actually lives. We dig into the practical trade-offs: what TypeScript does better out of the box, where Python offers more flexibility for QA work beyond the browser, and why stable tests are surprisingly easier to achieve in Python's synchronous world.
"Python by default is a synchronous language. You don't have this await, async and so on stuff that you have on the JavaScript and TypeScript stuff." - Maciej Kusz
With 17 years of experience as a QA and 14 years of test automation (Python and recently TypeScript), Maciej Kusz has been testing UI, API, IoT and has been a test lead and architect, mentor and keynote speaker. He is also a co-creator of the SlonzaczQA meetup and was part of the program committee of ConSelenium/Tada and TestWarez. He is also part of Polish Quality Retreat and shares his knowledge in his blog. After hours he is creating an open-source project called MkDocs Publisher, doing some DIY, and playing with 3D printing.
Highlights:
Playwright's Python version uses PyTest as its test runner rather than a built-in runner, which means documentation for test execution lives separately in the PyTest docs, not in the Playwright docs.
Visual regression testing is built into the TypeScript version of Playwright but only possible in Python through external, often poorly maintained libraries; Electron desktop apps and web components can only be tested with TypeScript.
Python's synchronous-by-default behavior removes the async/await complexity present in TypeScript, making test debugging more straightforward without requiring a dedicated IDE plugin.
Playwright gained ground over Selenium primarily because of built-in auto-waits, integrated tooling like CodeGen and Trace Viewer, and automatic browser version management tied to the framework version.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
22 min
March 26Learning from Failure: Feel It First, Then Analyze - Natalia Romanska
Why your biggest professional mistakes might be your most valuable teachers
In this episode, I talk with Natalia Romanska about why our biggest professional disasters often teach us more than our polished success stories. She shares how a 70,000 złoty accounting mistake early in her career forced her to develop the self-awareness that now guides her QA work—and why that painful learning stuck harder than any training ever could. We dig into the uncomfortable truth that testers rarely talk about: the gap between knowing we should learn from failures and actually sitting down to extract those lessons. Natalia offers concrete practices for turning blame into growth, from the "magic five whys" to building feedback loops that don't just stroke our egos.
"I can make mistakes. I will be doing mistakes in the future. That's not something that we can just skip and forget." - Natalia Romanska
Once an accountant, Natalia Romanska is now a QA. She is a fan of a holistic approach to Quality Assurance - the one that begins with neatly designed processes and thoughtful planning. She truly enjoys having things balanced, both in private and professional life. After hours, you’ll find her rewatching Friends, exploring new destinations, and always on the hunt for the next great scent
Highlights:
Analyzing a failure without emotions involved is a precondition for extracting useful lessons: grief and reaction belong first, analysis comes after the feelings settle.
Every failure is a different case with different contributing factors, so no universal pattern applies and each incident requires its own root-cause analysis, not a recycled fix.
Comparing your current self to your past self tracks real growth more accurately than comparing yourself to others, whose visible success represents only a fraction of their actual experience.
Self-awareness requires active input from outside, including regular feedback from managers and peers, because personal bias blocks honest self-assessment even after years of experience.
Avoiding an activity entirely after a painful failure, as Natalia Romanska did with public speaking after nearly fainting on stage, is itself a signal that the failure has not yet been fully processed.
More Links with Insights:
Testwarez
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
28 min
March 19How Motherhood Made Her A Better QA Manager - Žaklina Polak Matanović
A QA manager on transferring soft skills from motherhood to testing
In this episode, I talk with Žaklina Polak Matanović, an experienced QA manager who discovered that raising three daughters taught her more about software testing than most training courses ever could. She shares concrete stories about how skills like clear ownership assignment, prioritization under pressure, and proactive thinking emerged naturally from parenting chaos – from navigating playgrounds with toddler twins to managing ambiguous requests at home. What makes this conversation powerful is Žaklina's honest reflection on returning to tech after maternity leave, initially doubting her career trajectory while others seemed to advance, only to realize the soft skills in software testing she'd been building at home became her greatest professional assets for achieving work life balance in tech.
"If something is obvious to you, it does not mean that it's obvious to someone else." - Žaklina Polak Matanović
Žaklina Polak Matanović is a seasoned QA professional with over 20 years of experience in software quality assurance, test and release management, and software development. She enjoys working in international environments and takes a structured, collaborative approach to delivering high-quality software.
Outside of work, she is a passionate salsa dancer, chorus singer, and a curious explorer at heart—whether she is sailing, skiing, biking, or capturing moments through photography. She loves traveling and being near the sea or snow, and these adventures inspire both her personal and professional life.
Highlights:
Ownership assigned by name gets things done; ambiguous responsibility leaves tickets in the backlog indefinitely, whether at home or in a project team.
Parenting toddlers on a playground is a live prioritization exercise: protect the child in greater danger first, then handle the next risk, which maps directly to triage under release pressure.
Asking a colleague to take on tasks when your own list is full is not a weakness; spreading responsibility makes the workload manageable for everyone, just as calling a neighbor for backup at the playground does.
Quiet team members never get to speak when only the proactive ones hold the floor; a lead's job is to create space for every voice, not just the loudest.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
21 min
March 12Structured Exploratory Testing Strategies That Work - Callum Akehurst-Ryan
Using Exploratory Testing to Uncover Risks and Unknowns in Software Projects
In this episode, I talk with Callum Akehurst-Ryan, a quality coach with nearly 20 years of experience, about why exploratory testing is far more than random button-pushing—and how teams waste it by using it in all the wrong places. Callum walks us through practical exploratory testing techniques that help uncover risks in non-functional requirements like performance and security, especially when no one has bothered to document what "good" should look like. We discuss how to structure exploration with timeboxes and risk-based scopes, when to turn findings into automated tests, and why retrofitting quality into existing systems demands a different software testing strategy than most teams realize.
"We do exploratory testing when things are unknown. But from the unknown, we get information. That makes things known." - Callum Akehurst-Ryan
Callum Akehurst-Ryan (he/him) is a testing specialist and quality coach with over 17 years of experience across a range of different industries and development methodologies. With a focus on holistic quality engineering and exploratory testing, Callum teaches others in core and agile testing concepts. He’s also a kick-ass dungeon master!
Highlights:
Exploratory testing covers unknown territory: it runs experiments to gather information where no requirement or expected result exists, not to confirm a known outcome.
Time-boxing exploration to a fixed session, then checking with the team before continuing, prevents both endless rabbit holes and work on defects nobody will fix.
Exhaustive testing is mathematically impossible: the character combinations for a single 100-character input field exceed the number of seconds the universe has existed.
Findings from exploratory sessions should feed scripted or automated tests once the behavior is understood, because exploratory testing is a poor mechanism for repeatable regression checks.
Golden master testing, capturing what a live system currently does and writing tests to confirm it stays that way, is a valid strategy for retrofitting regression coverage when original requirements are gone.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
31 min
March 05Testing Economics: Treat QA as Insurance Against Failures - Vitaly Sharovatov
How Testers Can Use Economics to Influence Quality Decisions in Software Development
In this episode, I talk with Vitaly Sharovatov about the economics of testing. We ask how testers can sell quality to managers who think in money, risk, and time. Vitaly frames testing like insurance. You pay now to lower the chance or impact of pain later. He shows where to find numbers that speak. Churn, support hours, rework in Jira, failed handoffs, and regulatory risk. Start small. Pair with developers, cut waste, count saved hours, and share clear wins. Then aim bigger. Shorter time to market, better UX, fewer angry users.
"We are paying with efforts and time for things which don't occur, which is very, very strange to do." - Vitaly Sharovatov
As a quality enthusiast, Vitaly Sharovatov believes that people should take pride in their work and companies should aim to produce high-quality products. He has spent the last 23 years in IT, focusing on engineering, QA, and mentorship.
He is also a huge animal lover and has saved and raised more than 50 cats and dogs.
Highlights:
Framing testing decisions in financial terms gives testers a concrete fallback: if a manager overrides a risk warning, the tester can request a written sign-off, which protects their job security.
Reducing visible, repetitive waste first (such as features returned from testing to development because they were untestable) builds the credibility needed before proposing larger investments in quality.
Testers have more direct exposure to real user behavior than product managers do, because regression and exploratory testing requires them to follow the full user journey from signup to cancellation.
Customer support time spent routing user complaints into existing bug reports is a direct, measurable cost that can anchor a business case for better QA without requiring complex financial modeling.
More Links with Insights:
QA collaborative community
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
34 min
February 26Public Speaking for Testers: Preparation Reduces Stress - Maryia Tuleika
Motivation and Tips for Presenting at Tech Conferences
In this episode, I talk with Maryia Tuleika about stepping on stage in tech and testing. We explore why people speak: joy of sharing, stage energy, and community. The hard part is fear and stress. If you fear the stage, you will hear simple moves that help. Maryia shows how to switch stress to excitement: prep well, record dry runs, collect feedback, use box breathing, slow down, and stand tall.
"So my recommendation is not to Care too much about the audience face expressions while you're talking from the stage because you never know what it means." - Maryia Tuleika
Maryia Tuleika is a Quality Engineering Leader who leads teams, creates testing strategies, drives education programs and actively contributes to the testing community. As a mentor, speaker and conference organiser she helps new test professionals build their skills and confidence. She is a podcast host and a co-founder of Beyond Quality community of practice. Maryia believes that great testing brings both technical excellence and knowing what to prioritize, think critically and enjoy the process.
Highlights:
Stress before going on stage does not disappear with experience; even speakers with decades on stage still feel the adrenaline kick, and reframing it as excitement rather than anxiety is a proven way to handle it.
Slides with minimal text force a speaker to build a real story with a problem, escalation, and resolution, rather than reading bullet points, which lets the audience listen without splitting attention between reading and hearing.
Thorough preparation is the single most reliable way to reduce on-stage stress, because confidence cannot be performed when the material is not ready, regardless of breathing techniques or posture.
Square breathing (four seconds in, hold four, out four, hold four) directly calms the nervous system and slows speech, making it a practical pre-stage tool with a physiological basis, not just a relaxation ritual.
More Links with Insights:
Maryia's Personal Page
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
35 min
February 19Design Patterns in Test Automation: Less Spaghetti Code - Kostiantyn Teltov
Page Objects, Builders, and Facades: Key Test Automation Design Patterns Explained
In this episode, I talk with Kostiantyn Teltov about design patterns in test automation. Kosta shows why test code needs the same care as product code. Page Object to cut duplication. Builder to shape data like choosing a burger. Facade as a reception that guides you to the right service. We touch creational patterns and even pools for drivers. DRY, KISS, and YAGNI keep us honest and stop overdesign.
"Design patterns support extensibility of our test automation solutions." - Kostiantyn Teltov
Kostiantyn Teltov was born in Dnipro, Ukraine, and lives in Kraków, Poland, for the past three years.
He has been working in software testing since 2008 and writing code for over 11 years.
His technical background includes C#, Java, JavaScript/TypeScript, and Python, and he can speak four languages — though not all my programming and speaking languages are equally good ;-)
He is a strong advocate of the Shift-Left testing mindset and the Testing Pyramid approach.
He is passionate about mentoring and educating others, especially in Test Automation.
In the past, he has lectured IT courses. Today he speaks at webinars, meetups and perform workshops, and regularly write articles on Medium.
Currently, he works as a QA Lead at Metso, managing five projects and focusing on building QA processes and automation frameworks with limited QA resources.
Highlights:
Design patterns give test automation teams a shared vocabulary, so a problem can be solved by naming a pattern (Builder, Singleton, Facade) rather than re-explaining the solution from scratch.
Spaghetti test code is the direct result of skipping encapsulation: without patterns like Page Object, selectors and methods scatter across tests and duplication multiplies.
The YAGNI principle applies to test automation frameworks: implement only what is needed now, and leave extensibility as a structural option, not a pile of unused helpers.
AI tools will generate overcomplicated test automation code without explicit constraints in the prompt, and a human engineer must still verify and redesign the output.
The Gang of Four design patterns, published in 1994, remain directly applicable to test automation, especially the creational patterns. The object pool pattern, which is not part of the Gang of Four catalogue, helps manage parallel web driver instances.
More Links with Insights:
Testwarez
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
20 min
February 12Facing Impostor Syndrome as a Software Tester - Linda Van De Vooren
Why simple can be right and doubt can mislead you
In this episode, I talk with Linda Van De Vooren about impostor syndrome, mental health, and growth in testing. Linda shares stories, from eating disorders to the inner critic she named Hannibal Lecter. We look at how doubt hits our work, like writing a test plan that feels too easy. Her tactics: Share openly. Check basic needs. Treat your comfort zone like a rainbow and pick a color you can handle today. Build an honest feedback circle.
"Nobody sees all your flaws but you yourself." - Linda Van De Vooren
In her daily life, Linda Van De Vooren is an amateur (baritone!) saxophonist and an experienced software tester. Living in the center of the Netherlands, she can be found exploring nature, attending concerts, or visiting the theater.
She enjoys working in complex environments and does not shy away from a challenge, whether it stems from technical difficulties or a politically complex environment. In any free time that is left, she is an avid gamer (Nintendo!) and enjoys reading.
Highlights:
Naming the inner critic, for example by giving it a character from a film, creates separation between self-generated thought and self-destructive doubt, making the voice easier to dismiss.
Impostor syndrome hits hardest around skills that come naturally, because fluency in a task removes the visible effort that would otherwise confirm competence to the person doing it.
Choosing feedback sources deliberately matters: people who love you protect you from change, while people who see you in your professional context can challenge you toward growth.
The comfort zone is not a fixed line to cross but a range, and recognizing on a given day how far you can stretch it is itself a skill that reduces the cost of self-doubt.
More Links with Insights:
I am not the impostor, it's all in my head!
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
26 min
February 05Critical Thinking in AI-Assisted Testing: Check the Source - Steve Watson
Use AI in testing without losing judgment or ownership
In this episode, I talk with Steve Watson about critical thinking in the age of AI in testing. Steve says treat AI like a smart teammate. Useful, but you still check its work. We talk bias, missing context, and why lazy shortcuts tempt us. He shares where AI helped, like clustering survey responses, and where it missed ambiguities in requirements. We look at our craft: Ask better questions. Focus on the user. Let tools draft, but you decide. Train the next generation in skepticism and analysis. Same mission. New habits.
"We're moving away from telling a computer what to do to actually collaborating with it." - Steve Watson
Steve Watson is an experienced Quality Engineering Manager who leads and coaches testing teams to help them to be the best testers they can be.
As a Senior Quality Engineering Manager at easyJet, he is responsible for the overall testing strategy and standards within the Airline Operations area, managing an offshore testing function and the testing budget. His mission is to ensure that Quality Engineering is embedded as early as possible to add value, working with key business and IT stakeholders to identify improvement areas and gain buy-in and support to implement change.
Steve has vast experience in a variety of domains - banking & finance, vehicle leasing, chemical pricing and aerospace, and other than a brief stint as a Product Manager and then Project Manager in 2018, he has spent most of his professional career in the testing & quality engineering space.
As a member of the British Computer Society, Steve cares about improving how we test as an industry, and he writes a blog to share his personal thoughts and ideas.
Steve has spoken at a number of conferences over the past 12 years, including the National Software Testing Conference, Test Expo, UKStar and HUSTEF, facilitated a Zoom roundtable event, ran a BDD interactive workshop at a UK Meetup, and has been a guest on the Testing Peers podcast.
When Steve is not testing, you’ll find him broadcasting a Saturday morning radio show on a local community station in East Sussex, UK, where he has volunteered for the past 12 years.
Highlights:
AI is a tool for collaboration, not delegation: accepting its output without verifying the source data means the tester has not done the job.
Testers who offload analytical work to AI risk losing the ability to judge whether an output is correct, and that loss is hard to recover once it compounds over years.
AI tools carry biases that are not always visible, and without independent verification those biases can produce outputs that systematically disadvantage users outside a narrow demographic bracket.
The core tester responsibility stays constant regardless of who or what wrote the code: determine whether the software delivers what was expected for the end user.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
28 min
January 29Quality Metrics: Why Every KPI Needs a Counter Metric - Jani Grönman
The KPI pairs that keep you honest.
In this episode, I talk with Jani Grönman about KPIs for quality. We ask what to measure, and why. Jani shares pairs that keep teams honest. Test pass rate with escaped defects or flaky tests. Mean time to recovery with reopen rate. Lead time to production with customer impact. One team, one number. Keep it to three or four KPIs, own them, and act. We talk about agency at work and product sense. Your tests are not a scoreboard. They are a feedback loop. Bring product and engineering together, do root cause analysis. I left inspired to pick fewer numbers, tell stories, and ship with care.
"If you cannot measure what you change, it's really hard to lead the change." - Jani Grönman
Jani works as a Managing Partner at Hidden Trail, his mission being turning quality from a cost into competitive advantage.
Hidden Trail is a Digital Product Quality consultancy with clients in Scandinavia, Central Europe and the Americas. In Hidden Trail Jani leads advisory and transformation projects that tackle complex quality related development needs within his client companies. This means working with teams, management, product people, developers and testers to recognize where their product quality comes from and how to make it a tangible asset. Jani has 20+ years experience in software industry, during which he has worked with many teams in managerial, development and quality related roles. Jani firmly believes that quality means business!
Highlights:
Every KPI needs a counter metric: measuring mean time to resolve bugs without also tracking reopen rate invites teams to close tickets without actually fixing the underlying problem.
Teams should own no more than three or four KPIs at once, because a focused set drives direction while a long list produces noise and diffuses accountability.
A metric nobody acts on is a useless metric: ownership and periodic review are what separate a meaningful KPI from a number that decorates a dashboard.
Involving the team in building their own metrics creates genuine ownership, which is the difference between engineers who game a number and engineers who care about what it measures.
High unit test coverage can coexist with production defects, making escaped defect rate the necessary counterweight to any pass-rate or coverage percentage metric.
📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free
27 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