44 posts tagged with "Quality Assurance"

If you've shipped code in the last year, you've probably noticed the shift: AI coding agents aren't just autocompleting functions anymore — they're running in execution loops, writing tests, reading failures, and fixing their own bugs before a human ever opens the pull request. Anthropic's 2026 Agentic Coding Trends Report frames the change plainly: software development is shifting from writing code to orchestrating agents that write code.

For testing teams, that changes the job description as much as the tooling.

Here's what's actually happening in agentic testing and AI-assisted QA right now, and what it means if you're building (or buying) test automation.

Last month I had a conversation with a CTO that stuck with me.

Their team has 3,400 tests. 94% coverage. A CI pipeline that runs on every PR. Tests pass reliably — less than 2% flaky rate. By every industry metric, this is a well-tested codebase.

They also had 6 production bugs in the past 30 days. All reported by users. All missed by the test suite.

I asked him to send me the bugs. Here's what they were:

1. A modal didn't close when clicking outside it. Users had to refresh the page to dismiss a confirmation dialog.
2. A price displayed as $1,299 in the cart but charged $12.99. Decimal formatting inconsistency between the display component and the payment API.
3. The "Export to CSV" button worked on Chrome, broke on Safari. Downloaded an empty file.
4. A newly added field was editable for admins but displayed as read-only for regular users — the opposite of what it should have been. Permission logic was inverted.
5. A search that returned 0 results showed the previous results instead of an empty state. Stale state from a React component not resetting.
6. The onboarding flow skipped step 3 entirely when the user's timezone was UTC+0. A conditional that checked for a truthy timezone value — and 0 is falsy in JavaScript.

None of these are exotic edge cases. Every one of them is something a human using the app would hit within 5 minutes.

And none of them were caught by 3,400 tests at 94% coverage.

Why?

Every Salesforce team tests. The question is how — and what slips through the cracks depending on which approach you use.

In this post, I'm going to take a real Salesforce application — Dreamhouse, Salesforce's official sample app — and test the same functionality three different ways:

1. Apex unit tests (the traditional Salesforce-native approach)
2. Selenium WebDriver (the industry-standard UI automation approach)
3. DevAssure O2 Agent (autonomous browser-based testing)

For each approach, I'll show you the actual code, explain what it catches, what it misses, and the ongoing maintenance cost. By the end, you'll have a clear picture of where each approach fits — and where it falls short.

For years, I led teams focused on engineering productivity and release management across startups and enterprises. My primary job was not just shipping features — it was ensuring release trains moved predictably, developers remained productive, and quality gates did not become velocity killers.

One thing became very clear over time:

Engineering velocity was rarely limited by coding speed. It was limited by testing friction.

For a decade, the testing industry rallied behind a simple mantra: shift left.

Find bugs earlier. Test sooner. Put quality in the hands of developers.

The theory was sound. A bug caught in development costs roughly 10× less than one found in production. Move testing to the left of the timeline, and you save money, ship faster, and improve quality.

But here is what actually happened:

Software testing traditionally focuses on one core question:

Does the application work?

But there is a more important question that often gets ignored:

“Hunt those pesky bugs before they haunt your customers.”

One of the most important challenges that every IT company in the United States faces at some point is how to kick-start QA engineer hiring and establish the best QA team that can compete globally. Testing the respective web application and detecting bugs early is one of the most important things that every IT company should ensure. This is where the STLC (Software Testing Life Cycle) jumps in!

Software Testing has evolved rapidly over the last decade. From test automation frameworks to AI-powered testing tools, the industry has witnessed a rapid change in how software testing is performed.

Every engineering team hits this wall at some point. And honestly, it's not because someone did a poor job. It’s usually because the team hasn’t clearly separated what unit tests should catch and what functional tests are supposed to catch.

Both testing types sound deceptively similar when you're new. They both test “functionality” in some shape. But in practice, they operate in completely different layers, catch different categories of failures, and even follow different rules of engagement.

Once you really understand how they differ, debugging becomes easier, CI/CD gets faster, and everyone stops blaming the wrong thing.

Let’s break this down in a clear, practical way that developers, testers, and engineering managers can actually use.