Skip to main content
M
From Test to Trust
Live Talks ↗
Maneesh Maddala
Maneesh Maddala AI / QE Leader

From testing software to engineering trust

AI-First Quality Engineering Leader · Principal QA Automation Engineer at Morningstar

Current Focus

Multi-Agent SDLC Orchestration →
Model Routing & Cost Control via LiteLLM →
Crash-Testing LLM Guardrails & Evals →

About & Evolution of Practice Personal Philosophy

A direct look at how I think about quality, how my approach evolved across 15+ years, and how I build trustworthy AI systems today.

Quality for me is not a checkbox or a gate at the end of a sprint.

As Jerry Weinberg once said, quality is value to someone who matters. For me, that means finding hidden risks, questioning assumptions, and protecting the person using our product.

Over 15+ years, my work has moved through three clear chapters: hands-on manual testing, simple scalable automation, and building trustworthy AI systems.

The 3 Chapters of My Quality Journey

15+ Year Evolution
01

How I Approach Manual and Exploratory Testing

Learning how software actually breaks in the real world.

Exploratory & Manual Testing

When I started in QA, I quickly realized that following a written script only catches the bugs you already expected. The worst bugs always hide in the gaps nobody thought to write down. Influenced by thinkers like James Bach and Michael Bolton, I treat testing as an active technical investigation.

How I put this into practice:
▸
I look at the product with fresh eyes: Developers naturally test what they hope will work. My job is to explore what actually happens when real people touch it.
▸
I put the user first: What happens when someone clicks too fast, loses connection halfway through a form, or enters messy data?
▸
I ask the uncomfortable questions early: Finding a flaw during design discussions saves the team weeks of painful rework later.
02

How I Approach Test Automation

Keep it simple. Zero clever code or unwanted abstractions.

Test Automation & Architecture

When I moved into automation, I saw teams make the same mistake everywhere: they built massive, over-engineered frameworks with too many custom layers. When the author left the company, nobody could maintain the code, and the whole framework fell apart. My motto on every team I lead is simple: keep it simple, stupid (KISS) and do not build things you do not need (YAGNI). If a new engineer joins my team on Monday, I want them to understand our test code and push their first working test on Tuesday with almost no hand-holding.

How I put this into practice:
▸
I use standard tools directly: I write clean, readable TypeScript using tools like Playwright or Cypress directly, without wrapping them in five layers of custom code.
▸
I test at the right level: I cover Web UI, API endpoints, visual regression, components, and accessibility (WCAG 2.2 AA) where each test runs fastest and gives the clearest signal.
▸
I build for easy maintenance: Flaky tests kill developer trust. I make sure our tests run fast in CI/CD pipelines and give an obvious failure trace when something breaks.
03

How I Build AI Systems

Guardrails, evals, and trust baked into the architecture.

AI-First Systems & Governance

Traditional code is predictable: input A always gives output B. AI is completely different. A model can give a different answer every time, hallucinate facts, or get tricked by prompt injections. You cannot test an AI system with standard assertions. For me, building AI-first systems means engineering trust into the pipeline itself.

How I put this into practice:
▸
I run evals at every step: I build automated evaluation harnesses that score the model's accuracy, safety, and output format before the agent takes any real action.
▸
I put hard guardrails in place: I do not rely on prompt phrasing alone. I set strict input filters, enforce JSON schema validation on every tool call, and catch injection attempts before they execute.
▸
I use open standards like MCP: I build custom plugins and Model Context Protocol (MCP) servers so models only have access to the exact tools and data they need to do their job.
▸
I build for resilience: If an AI provider goes down or slows down, my gateways (like LiteLLM) automatically fail over to backup models without the user ever noticing.

🛡️ Three Rules I Follow Every Day

1. Show proof, not opinions

In AI and quality, saying something 'works' means nothing without eval scores, test results, and clear logs to back it up.

2. Build guardrails inside the system

Security, trust, and accuracy must be built directly into the architecture, not patched on after an incident.

3. Simplicity always wins

A clean, readable system that the whole team can maintain is always better than a complex framework only one person understands.