Self-Hosted AI Testing with Local LLM

What Does Self-Hosted AI Testing Mean in QAMind?

Self-hosted AI testing in QAMind means the AI model runs on the user's own workstation, not on third-party cloud servers. QAMind uses Qwen 3 Coder 30B running on Ollama, installed on the user's GPU workstation. Browser recordings, requirement documents, and test data never reach OpenAI, Anthropic, Google, or any cloud AI service.

Every competitor in the test management market routes AI features through cloud-hosted models. This includes TestRail, Qase, Zephyr, and TestQuality. QAMind's architecture is the only one in this market where the model processes data locally.

What is the Qwen 3 Coder 30B model?

Qwen 3 Coder 30B is an open-source code-optimized language model developed by Alibaba Cloud. QAMind uses this model because it produces structured, step-by-step test case output from browser event sequences and requirement text. The model runs locally on Ollama, a runtime that manages local LLM execution on the user's GPU hardware.

How Does QAMind's Self-Hosted Architecture Work?

The QAMind web app sends generation requests to a Python/Uvicorn worker running on the user's workstation. The worker receives the browser recording or requirement document, forwards it to the local Ollama instance, and returns the structured test cases to the web app. The worker connects via the user's private network.

The web app (authentication, suite storage, bug tracking, sprint planning) runs on QAMind's infrastructure. Only the AI inference step runs locally. Metadata is stored in Supabase after generation. Metadata includes test case titles, steps, and expected results. Raw recordings and requirement documents are processed locally and never forwarded to QAMind's servers.

Who Needs Self-Hosted AI for QA Testing?

Self-hosted AI testing addresses 4 scenarios where cloud AI is not acceptable. Teams working on unreleased product features need to keep PRDs and requirement documents out of cloud AI training datasets. Teams in regulated industries (healthcare, finance, government) face data residency requirements that prohibit sending test data to third-party AI services.

Teams with security or legal restrictions on external data transmission choose local AI to avoid policy violations. Teams testing proprietary algorithms, trade secrets, or competitive features cannot risk those details appearing in cloud AI training corpora.

QAMind's local architecture serves these teams with the same AI generation capabilities as cloud competitors, without the data exposure risk.

What Hardware Does the Local AI Worker Require?

The local AI worker requires a GPU workstation with sufficient VRAM to run Qwen 3 Coder 30B on Ollama. The worker runs as a Python/Uvicorn process. Setup scripts for Windows and macOS install Ollama, download the model, and start the worker process.

The AI worker processes one generation job at a time on the GPU slot. Concurrent requests queue with automatic retry and exponential backoff. The web app shows a "worker busy" status during active generation and notifies when the slot becomes available.

Teams share one AI worker across the workspace. The worker does not need to run continuously. It runs only during active test case generation sessions.

How Does the Local AI Connect to Other QAMind Features?

The local AI worker powers 3 QAMind features: AI test case generation from browser recordings, test case generation from requirements, and the private AI chat. All 3 features route inference requests to the same local Ollama instance.

The Playwright test generator uses a separate MCP server on port 3100. Script generation does not require the AI worker. The MCP server converts existing test cases into code.

The local AI architecture page describes the full data flow in detail.

Frequently Asked Questions