AI Testing
Deploying an LLM is not a one-time event. Prompts change. Models get updated. Retrieval indexes get refreshed. Each of these changes can silently degrade the quality of your AI application — and without a continuous evaluation pipeline, you won't know until users start complaining. This guide covers how to
Provar
Provar is a Salesforce-native test automation tool built specifically to address the most common pain points in Salesforce UI testing: dynamic element IDs, frequent layout changes from seasonal releases, and the complexity of Lightning Web Components. While general-purpose tools like Selenium can be made to work with Salesforce, they require
No-Code Testing
The no-code testing market has exploded over the past few years. What was once a category dominated by expensive enterprise tools has become a crowded space with options ranging from free open-source projects to six-figure enterprise contracts. For teams trying to evaluate their options, the sheer number of choices — and
No-Code Testing
Software quality used to be the exclusive domain of engineers. If you wanted automated tests, you needed someone who could write Python, JavaScript, or Java — and ideally someone who understood Selenium's quirks, could configure CI pipelines, and was comfortable debugging stack traces at 11pm. That world is changing
No-Code Testing
If you've been manually clicking through the same five workflows before every release, you already know the problem. Manual regression testing is slow, error-prone, and doesn't scale. But every time someone mentions automated testing, the conversation turns to code — Selenium, Cypress, Playwright — and suddenly it sounds
Playwright
Playwright has become the gold standard for browser automation. Released by Microsoft in 2020, it quickly surpassed Selenium and gave Cypress serious competition, offering faster test execution, better support for modern web patterns (shadow DOM, iframes, async operations), and a genuinely excellent developer experience. There's one problem: Playwright
No-Code Testing
Few debates in QA generate more heat than codeless versus scripted testing. On one side: developers who view codeless tools as toys, insufficient for "real" testing. On the other: product teams who see scripted testing as an unnecessary barrier that concentrates quality ownership in a bottleneck. Both sides
Testing
Bad alerting is worse than no alerting. A monitoring setup that pages you at 3am for a 2-second blip that self-resolved trains your team to ignore alerts. And teams that ignore alerts miss the real outages. Getting synthetic monitoring alerting right is mostly about restraint: being precise about what constitutes
Testing
Synthetic monitoring is one of those terms that sounds more complicated than it is. At its core, it means running scripted tests against your application on a schedule — simulating what a real user would do — and alerting you when something breaks. No real users required. If you've ever
Testing
Every mature test strategy uses multiple types of tests, each serving a different purpose. Smoke, regression, and acceptance testing are three of the most commonly used — and most commonly confused. They're not interchangeable. Running the wrong type of test at the wrong time wastes time at best and
Testing
Smoke testing and sanity testing get conflated constantly. Both are fast, both happen early in the testing cycle, and both catch obvious problems before you waste time on deeper testing. But they serve different purposes, run at different times, and cover different ground. Mixing them up leads to gaps in
Testing
Playwright is a strong choice for smoke testing. It's fast, handles modern web apps well, and has built-in support for parallel execution, auth state persistence, and multiple browsers. This post walks through building a complete smoke test suite with Playwright, from project setup to CI integration. Project Setup