Practical AI Adoption in Test Automation

After years leading engineering and quality organizations, I wanted to explore practical AI adoption by building something hands-on.

Most conversations around AI in testing focus on:

AI-generated tests
Autonomous testing
self-healing magic

But in real engineering systems, reliability, transparency, scalability, and cost still matter.

The Classic Problem: Traditional automation frameworks come with several pain points. Complexity causing maintenance overhead, Lot of coding, Creating skill dependency. Duplicated logic, Test sprawl. Yes, there are commercial solutions to these, well they are expensive, causes vendor lock-in and less flexible and not scalable.

AI testing problems: Smart IDEs, Agentic QA, Tool calling all are evolving in making life easier, however the challenges of Inconsistent usage across team, cloud LLM dependency, expensive test building and execution, over reliance on AI are some of the persistent problems.

That led me to build OpenSecant — an AI-native resilient automation framework built on Playwright.

The goal was not to replace deterministic automation with AI, but to augment automation intelligently where it adds value.

What OpenSecant currently supports:

✅ Natural language-driven test execution
✅ Local-first locator intelligence
✅ LLM fallback when local resolution fails
✅ Self-healing selectors
✅ Step memory / reusable automation intelligence
✅ QA agent mode for exploratory workflows
✅ Parallel execution support
✅ Cloud + local LLM providers (OpenAI, Azure OpenAI, Bedrock, Ollama)
✅ Test Report with screenshots

... and More on the way.

Architecture:

Key Concepts:

Simplicity:
No more feature files, no more step definition, just test files and step to code mapping. catering to all roles QA, Dev, BA etc.

Deterministic-first approach:
Use of local locator engine to resolve locator identification reducing dependency on LLM calling

Self-healing philosophy:
On error fall back to Locater engine, pass the Hybrid element structure combining DOM structure and Accessibility snapshot. If the suggested locator fails, then 2nd level fall back to AI calling with local LLM or cloud, with retries in each layer

Local LLM support:
Cloud LLMs are Expensive - I have been using cloud LLMs from multiple providers. I have realized when you have 1000s of tests to build run, heal, relying on cloud models is expensive.

Data Privacy, Security by Design - Local LLMs are way to go when your tests are to deal with sensitive data

Tool Calling Flexibility - Easy to test integration in Internal Environments, Databases etc.

Enterprise Adoption - Easier to Scale

I used Ollama with models like phi4-mini, gemma4-e2b etc. They would need a machine with 8 GB GPUs to respond in seconds. This is getting to norm lately on local machines or pipeline set ups. Which makes scaling easier.

Integration with OpenAI, Bedrock and Azure exist, use with caution of cost.

Agentic QA:
Agentic QA if the future of Quality Engineering and I have taken a strong step towards it. Use cases like autonomously exploring sites or apps, building and saving tests for future execution

The working code: