Recently active topics

You will learn:Why AI-assisted testing creates new governance gaps, even when the tool works perfectly The six biggest risks: biased training data, autonomy drift, unclear accountability, compliance and audit gaps, black-box recommendations, and over-reliance on automated judgment How to build a simple inventory of the AI tools in your testing process How to define clear ownership and human review checkpoints What to audit and measure to keep AI tools accurate and trustworthyPricilla Bilavendran is a Quality Engineering leader at Billennium IT Services in Malaysia with over 15 years of software testing expertise. Named one of Agile Testing Days' "100 Women in Tech to Follow," she is a technical expert, global mentor, and dedicated diversity advocate.Let me start by sharing an incident.A few months ago, a friend of mine who is a Test Lead at a mid-sized fintech company was excitedly showing me how their team had integrated an AI-powered test generation tool into their pipeline. It was f

MCP Servers and Automation for Testers by Karthik K.K. TL;DR/ Key Takeaways:Learn Model Context Protocol (MCP) basics and how MCP connects AI systems to real tools and data sources through a client-server architecture. Understand AI agents for QA and how agents enable tool execution beyond what an LLM can do alone. Explore popular MCP clients like Claude Desktop and Visual Studio Code and how they connect to MCP servers. Learn how MCP servers are configured and how different clients store MCP settings. See how the Playwright MCP Server can support UI automation using plain-language instructions such as opening a browser, navigating, clicking, validating results, and summarizing outcomes. Explore MCP-powered UI testing workflows, including login, entity creation, logoff, and browser closure with AI-assisted steps and evidence capture. Discover how test code and project scaffolding can be generated automatically, including Playwright configuration, TypeScript configuration, test specific

Generative AI for TestersBy Rahul ParwalIn this on-demand Generative AI for Testers session, you'll learn how to confidently apply Generative AI in software testing and quality engineering.TL;DR/Key TakeawaysLearn the fundamentals of Generative AI for software testing, including what AI can and cannot do within QA workflows. Understand Large Language Models (LLMs) in practical terms, including tokens, training data, APIs, and how AI-generated outputs are created. Explore a proven GenAI framework for testing that covers: AI as an assistant Experimentation and transformation Coding and test automation Learning and summarization Apply GenAI to: Test case generation Test data creation Requirements reviews Risk identification Bug report authoring Test documentation Improve test automation productivity through AI-assisted code generation, refactoring, debugging, modularization, and rapid prototyping. Master prompt engineering for testers using practical prompting techniques that im

What you’ll learn:Adding hypothesis logging and a “signals” step to an AI agent’s instructions did not change how many defects it found. All three conditions had a median of 3 of 6. The agent reliably found defects exposed by a single input, such as the 60-ticket cap (15 of 15 runs), but almost never found timing defects. It found the last-ticket race once and double submit never. A tidy investigation log shows process, not coverage. Process, investigation, outcome and coverage need to be judged separately. A human should define which risks the agent must test or justify skipping, and when it may stop. Leaving that to the agent’s own judgement is not enough.Author: Ujjwal Kumar Singh, QA Engineer · 4+ years in enterprise QA  · beinghumantester.comIn Part 1, I argued that an agent that executes steps successfully is not doing exploratory testing. Exploration is an investigation, not a script. A test can pass every assertion on the happy path and still miss the duplicate order created by

Adapted from the first session of Tricentis’s Performance Engineering Fundamentals webinar series, presented by Bryan Cole, Director of Customer Engineering at Tricentis.TL;DR: Performance tests rarely pass or fail cleanly, so you need defined targets to judge them. SLAs set business-facing goals (process, user load, response time), SLOs set internal engineering targets, and SLIs are the raw metrics underneath. When the business can’t supply numbers, use production telemetry or your first test results as a starting point and refine from there.Most software testing gives a yes-or-no answer. A tester clicks “calculate tax” and checks the result. The tax is either correct or it isn’t. When a test like that fails, it is usually clear what went wrong and what needs fixing.Performance testing doesn’t work that way. A test simulates many users at once, each doing different things: some searching, some adding items to a cart, a few updating an address. The result is rarely all good or all bad.

Your instructor Laveena RamchandaniSenior Test Manager at a major low-budget airline, specialising in quality leadership within data science and complex technologies. With 13+ years of experience in QA, Laveena is an international conference speaker, keynote presenter, podcast guest, and author of professional courses on quality engineering.Description This free upskill session shows you how to scale quality governance across multiple squads, tools, and applications so you can release with confidence and prove every decision.The course is split into two parts.Part 1 covers the foundations: why governance changes at scale, traceability, and risk-based coverage.Part 2 builds on these with agentic workflows, a release confidence model, and leading governance across your organization.Each chapter includes real-world case studies showing governance in practice, plus a practical checklist to apply what you’ve learned straight away.What you’ll learn:When team-level governance is enough and wh

The Coverage IllusionA global oil and gas company was preparing a major SAP upgrade. The release contained 27,000 changes, and the team had 9,000 tests ready to go. By any traditional measure, that looked like solid coverage.Then they ran an AI-powered impact analysis. It showed that only 8% of the changed SAP objects were actually being verified by those tests. The other 92% of the change risk would have gone live untested.The team caught it in time, focused on the highest-risk areas, closed the gaps, and released successfully. The lesson was learned, though. Thousands of tests can still miss almost everything that changed, because traditional testing isn’t connected to what each transport touches.This isn’t an unusual case. Tricentis research shows that 51% of SAP teams say updating their systems puts business processes at risk, and 75% rely on hypercare after go-live to limit disruption. Hypercare means war rooms, extended monitoring, and extra people on standby. It is a symptom rat

Dinesh Gujarathi: Senior QA Engineer · Hands-on practitioner with ToscaTL;DR: Most "Tosca can't find it" problems have nothing to do with properties. Before you rescan for the fifth time, work out where the control actually lives and which engine is looking at it. This article walks through the four places a scan usually breaks, how to build an identifier that still works tomorrow, and the one-minute check I now run before any rescan.Rescanning didn't fix it.Rescanning again won't either.Over the years, colleagues and learners have brought me the same question in many different clothes. "The extension is added but the scan still fails." "I can't scan this pop-up." "It used to be a dropdown, now it comes in as an input." "How do I automate something like Calculator?"They sound like four different problems. In my work, they almost always turn out to be the same one.Tosca doesn't see your screen the way you doWhen you look at your monitor, you see everything at once. The browser, the page

Model Context Protocol (MCP) is an open standard that lets AI assistants (and agentic tools) talk to enterprise systems through a consistent, secure interface—think of it like USB‑C for AI tools. In practice, MCP gives an AI chat/agent access to resources, prompts, and tools exposed by a server, over a JSON‑RPC connection, in a way that’s LLM‑agnostic and designed with explicit user consent and controls.Why it matters for quality engineering: Tricentis now ships a qTest MCP server that bridges AI clients (e.g., Cursor, Claude) with the qTest API so you can converse your way through common test‑management work: list requirements, inspect linked tests, spot gaps, create missing test cases, analyze executions, and even file defects—all without writing glue scripts or clicking through deep UI menus. How the qTest–MCP stack fits togetherMCP client (e.g., Cursor): The IDE/assistant that speaks MCP and can attach servers via local mcp.json or remote transport. Cursor documents first‑class sup

Author: Ujjwal Kumar Singh, QA Engineer · 4+ years in enterprise QA  · beinghumantester.comKey takeaways:Why a test run can pass every check and still hide a real defect between connected systems How experienced testers turn an unexpected observation into a hypothesis and a deliberate experiment Why searching for explanations differs from searching for actions, and why more automated actions don't replace investigation How the six-step investigative loop lets testing change direction as evidence builds upImagine an order flow that spans two systems: a web storefront that takes the order, and an ERP that owns the stock. Two customers buy the last available unit at almost the same moment. Both orders are confirmed. The storefront's checks pass, and so do the ERP's. No exception is raised. From the perspective of an execution-oriented automation system, the test has succeeded and there may be nothing left to investigate.An experienced tester may see something different. There are now two