The Evil Tester Show - Software Testing and Development with Attitude

Based on my experience with AI, am I optimistic or pessimistic. I gain huge value from AI during development, but have I managed the same in Testing? And how will the Tester role change, what do we need to do to adapt? I look forward to learning more and describe my next steps. 00:00 - Introduction: Am I an AI Optimist or Pessimist? 02:16 - AI, Jobs, and Management Excuses 06:33 - How AI Changes Our Roles 10:49 - Human Connection vs. AI: Where I Refuse to Use It 16:27 - Building and Using AI Tools for Programming 22:46 - Automation, Testing, and the Human Factor 28:21 - The Future: Agentic AI, Fundamentals, and Looking Forward

The answers given during a Browserstack Community AMA session held on Discord on the 11th of December 2025, following a live LinkedIn video stream. The session focused on "Mastering Automatability for Test Automation". The main theme is the concept of Automatability, which I view as the ability to automate, this personal skill is more critical than reliance on specific tools. The discussion covers various topics, including how to separate automation problems from application design issues, dealing with slow UIs and non-automation friendly third-party widgets, evaluating automation readiness, and addressing common architectural failings related to large-scale UI automation. 00:00:00 Introduction 00:01:27 key early lesson about automatability?   00:01:56 separating automation issues vs. design issues?   00:03:49 is slow UI a testability or automatability problem?   00:06:50 handling non-automatable third-party widgets?   00:09:20 assessing automation readiness - any framework?   00:11:23 common architectural patterns that break at scale?   00:13:37 prioritizing testability vs. automation in sprints?   00:16:51 do modern tools reduce the need for good design?   00:19:32 explaining automatability as an investment?   00:21:44 how do AI agents handle dynamic/third-party elements?   00:23:17 early signs a feature will be flaky when automated?   00:26:10 which microservice layers to automate first?   00:29:16 high-ROI automatability fixes for small budgets?   00:30:55 early dev–test collaboration to prevent rework?   00:34:08 thinking about automatability in continuous delivery? Join the BrowserStack Discord community and discover more AMA sessions https://www.browserstack.com/community

Should you use AI to help you migrate test automation code? And what should you actually migrate, the tests coverage hasn't changed. In this episode we discus show abstractions and AI can be used to migrate... and discuss when you shouldn't. Welcome to The Evil Tester Show! In this episode, host Alan Richardson dives into the complex world of test automation migrations. Have you ever wondered what it really takes to move your automated test execution code from one tool or language to another—like switching from WebDriver to Playwright, or migrating from Java to TypeScript? Alan breaks down the pitfalls, challenges, and best practices you need to consider before taking the leap. He explains why migrating isn’t just about copying test cases, how abstraction layers can save you time and headaches, and why using AI and solid design principles can streamline your transition. Whether you’re facing unsupported tools, evolving frameworks, or strategic changes in your testing approach, this episode offers practical advice to plan and execute a seamless migration—without burying new problems beneath old ones. 00:00 Migration Challenges 02:43 Tool Evaluation 04:05 Migrating to Playwright: Considerations 06:00 Migration Process 06:25 Migrate: Easy First, Hardest Next 09:37 Effective Migration Strategies for Tests 10:23 Focusing Abstractions 14:39 Optimize Test Code Migration 15:44 Focus on Abstraction, Not Auto-Healing **1. Why Migrate—And When You Really Shouldn’t** Before any big move, Alan urges teams to get their “why” straight. Is your current tool unsupported? Is your framework truly incompatible, or are you missing some hidden potential? Migrate for the right reasons and make sure your decision isn’t just papering over problems that could follow you to the next tool. **2. Don’t Confuse Migration with a Rewrite** Too many teams treat migration like a rewrite—often with disastrous results. Alan emphasizes the importance of planning ahead, solving existing flakiness and coverage issues _before_ you move, and carefully evaluating all options (not just the shiny new tool you think you want). **3. The Secret Weapon: Abstraction Layers** The podcast’s biggest takeaway: Don’t migrate “test cases”—migrate _abstractions_. If your tests are full of direct calls like `webdriver.openPage()`, you’ve got work to do. Build out robust abstraction layers (think page objects or logical user flows) and keep your tests clean. When it comes time to migrate, you’ll only need to move those underlying layers, not thousands of individual test case scripts. **4. Taming Flakiness and the Risks of Retries** Migration is not the time to rely on self-healing tests or retries. Any test flakiness _must_ be rooted out and fixed before porting code. Bringing instability into a new stack only multiplies headaches later. **5. Harnessing AI—But Stay in Control** AI-assisted migration really shines at mapping old code to new, but Alan warns against “agentic” (hands-off) approaches. Use AI as a powerful tool, not as the driver—you need understanding and control to ensure things work reliably in CI/CD pipelines. **6. Learn Fast: Tackle the Hardest Stuff Early** Pro tip: Once you’re ready, start your migration with the simplest test, just to get going—then dive into the hardest, flakiest, most complex workflows. You’ll uncover potential blockers early and kick-start team learning. “We’re not migrating test cases when we change a tool. We’re migrating the physical interaction layer with our application... ”

Should you have an online portfolio showcasing your Software Development and Testing skills to help get a job? It really depends on the recruitment process. But... if I'm recruiting, and you have a profile then I will have looked at it. So it better be good. Most Software Developers and Testers don't have public portfolios so that means you can really stand out. We'll cover the difference between different types of projects: A breakdown of project types: Learning Projects, Personal Projects, Portfolio Projects. Lots of tips on how to adjust your Github profile and promote your projects. 00:00 Value of Portfolio 02:59 Stand Out Skills 09:19 Project Types 12:27 Showcase Projects 19:39 Promoting Yourself 21:44 Final Advice

Software Testing deserves respect. Doesn't it? But so does every role in Software Development: managers, testers, QA, programmers, Product, Everyone. This is for you. Ever feel like you’re not getting the respect that you deserve in your job? This episode dives deep into the topic of Respect in tech, especially focusing on software testing versus programming. We look at why some roles seem to earn more respect, what that means for workplace culture, and how you can change things for yourself and your team. Respect isn’t just about manners or titles - it’s about how the system works and how we show up in our roles. If you’ve worked in agile projects, you might have heard, "Everyone is a developer." But some roles seem to get more recognition than others. Is this because of how we define our jobs, or is it just baked into the way our workplaces run? This episode is a call to action, urging everyone to look at respect both at a personal, process and craft level. We’re breaking down the difference between self-respect, respect for others, and respect built into your team’s process. You'll see why just doing your job isn’t enough. You have to own your craft, communicate what you do, and make your contributions visible to earn genuine respect. By the end of this episode, you'll have practical steps to make respect part of your daily work, whether you’re writing code, testing, building products, or managing. 00:00 Respect Dilemma 02:41 Human Level Respect 06:31 Self-Respect First 10:17 Respect Cycle 15:37 Knowledge Sharing 18:53 Respectful Organizations 21:26 Final Thoughts