QA Radar

Servidor MCP que le indica a tu agente qué archivos probar primero: churn de git, brechas de cobertura y mapeo de pruebas como puntuaciones de riesgo por archivo.

GitHubPrueba este MCPPatrocinado

Documentación

QA Radar

Dale a tu agente de IA de codificación el cerebro de calidad que no tiene que desarrollar desde cero.

QA Radar analiza tu base de código y produce un informe estructurado de salud de calidad, combinando churn de git, cobertura de pruebas y mapeo de pruebas a código fuente en módulos con puntuación de riesgo. Funciona como un servidor MCP para agentes de IA de codificación (Claude Code, Cursor, Windsurf) y como una CLI independiente para humanos y pipelines de CI.

Creado para desarrolladores que quieren que su agente de IA escriba pruebas dirigidas, no genéricas.

Inicio Rápido

Claude Code — un solo paso:

/plugin marketplace add Muratkus/qaradar
/plugin install qaradar@qaradar-marketplace

Luego pregúntale a tu agente: "¿Qué debería probar primero?"

O ejecútalo directamente sin instalar:

uvx qaradar serve

Opciones de instalación completas ↓

Qué Hace

QA Radar responde la pregunta que todo nuevo miembro del equipo (y todo agente de IA) se hace: "¿Qué debería probar primero?"

Escanea tres señales y las combina en una puntuación de riesgo por archivo:

Señal	Qué Mide	Por Qué Importa
Churn de Git	Frecuencia de commits, líneas cambiadas, actualidad	Los archivos con alto churn son imanes de regresiones
Brechas de Cobertura	Cobertura de líneas y ramas de informes existentes	Baja cobertura = puntos ciegos
Mapeo de Pruebas	Qué archivos fuente tienen pruebas correspondientes	Sin pruebas = sin red de seguridad en absoluto

El resultado es una lista clasificada de módulos por nivel de riesgo (crítico → bajo), con razones legibles para humanos para cada calificación.

¿Por Qué No Simplemente Dejar Que el Agente Lo Haga?

Un agente capaz con acceso a bash podría ejecutar git log --numstat, analizar coverage.xml y buscar archivos de prueba con glob. Entonces, ¿por qué un servidor MCP?

Preocupación	Qué hace QA Radar en su lugar
Costo de tokens	`git log` durante 90 días en un repositorio mediano son cientos de KB. QA Radar devuelve ~5 KB de JSON estructurado.
Determinismo	Una puntuación de riesgo ponderada calculada ad-hoc en contexto no es confiable. El código es reproducible.
Velocidad	Una llamada de herramienta vs. 4–6 llamadas bash secuenciales + razonamiento entre cada una.
Normalización de formato	LCOV / Cobertura / JSON de coverage.py / perfiles de cobertura de Go se analizan de manera diferente. QA Radar normaliza entre formatos para que el agente no tenga que hacerlo.
Codificación de convenciones	`test_x.py` para Python, `x.test.ts` para JS/TS, `x_test.go` para Go, `FooTest.java` para Java — codificado una vez, no re-derivado en cada sesión.
Portabilidad	Las mismas herramientas MCP funcionan en Claude Code, Cursor y Windsurf sin necesidad de re-prompting.

Instalar como Plugin de Claude Code (Recomendado)

El camino más rápido — un comando configura el servidor MCP e instala 4 comandos de barra. Sin edición manual de configuración.

Paso 0 — instala uv (si no lo tienes):

curl -LsSf https://astral.sh/uv/install.sh | sh
# or: pip install uv

uv lanza qaradar bajo demanda desde PyPI — no necesitas pip install qaradar por separado.

Paso 1 — agrega el marketplace:

/plugin marketplace add Muratkus/qaradar

Paso 2 — instala:

/plugin install qaradar@qaradar-marketplace

Lo que obtienes: 6 herramientas MCP auto-configuradas + 5 comandos de barra:

Comando	Qué hace
`/qaradar:qa-check`	Informe completo de salud — riesgo, cobertura, archivos sin probar
`/qaradar:qa-risky`	Lista clasificada de archivos más riesgosos con razones
`/qaradar:qa-untested`	Archivos fuente sin pruebas detectadas + sugerencias de andamiaje
`/qaradar:qa-plan`	Plan de pruebas priorizado (encadena 3 herramientas)
`/qaradar:qa-pr-risk`	Qué archivos cambiados en este PR son los más riesgosos

Ejemplo: después de fusionar una rama de características grande, ejecuta /qaradar:qa-check para ver qué ha regresado. Antes de abrir un PR, ejecuta /qaradar:qa-pr-risk para ver qué necesitas probar primero.

Servidor MCP (para Agentes de IA de Codificación)

Configuración

Alternativa: configuración manual de MCP (si prefieres no usar el plugin):

Agrega a tu configuración MCP de Claude Code (~/.claude/mcp.json para nivel de usuario, o .mcp.json en la raíz del proyecto para nivel de proyecto):

{
  "mcpServers": {
    "qaradar": {
      "command": "uvx",
      "args": ["qaradar", "serve"]
    }
  }
}

O inícialo manualmente:

uvx qaradar serve

Ejemplos de Prompts

Una vez conectado, pregúntale a tu agente:

"¿Qué debería probar primero en este repositorio?" "¿Qué archivos son los más riesgosos ahora mismo?" "Muéstrame los archivos con mayor churn del último mes." "¿Qué archivos fuente no tienen pruebas en absoluto?" "¿Cuáles de mis archivos cambiados son riesgosos?" ← consciente de diffs

Herramientas MCP Disponibles

Herramienta	Cuándo la Usa el Agente
`qaradar_healthcheck`	Visión general completa de calidad de un repositorio
`qaradar_risky_modules`	Qué probar primero; qué archivos son los más riesgosos
`qaradar_churn`	Detección de puntos calientes; dónde tienden a ocurrir regresiones
`qaradar_coverage_gaps`	Archivos con baja cobertura; dónde están los puntos ciegos
`qaradar_untested_files`	Archivos fuente sin archivos de prueba correspondientes
`qaradar_pr_risk`	Qué archivos cambiados en este PR necesitan atención
`qaradar_should_run`	Después de terminar el trabajo: ¿debería QA Radar re-analizar, y sobre el diff o todo el repositorio?

Consciente de Diffs: ¿qué es riesgoso en este PR?

qaradar_pr_risk puntúa solo los archivos cambiados entre una ref base y HEAD — no todo el repositorio. Mantiene las puntuaciones de riesgo calibradas usando normalización de repositorio completo, para que un archivo con 2 commits en un PR no sea marcado falsamente como CRÍTICO solo porque es el único archivo cambiado que el agente conoce.

Pregúntale a tu agente:

"¿Cuáles de mis archivos cambiados son riesgosos?" "¿Alguno de los archivos que cambié carece de pruebas?" "¿Qué debería revisar antes de abrir este PR?"

O desde la CLI:

# Diff against main — shows only changed files
qaradar analyze . --base main

# Diff against a specific ref
qaradar analyze . --base origin/main --days 60

qaradar_pr_risk detecta automáticamente la rama base desde GITHUB_BASE_REF (configurado automáticamente en GitHub Actions) o recurre a main/master. Pasa base_ref explícitamente para anular.

CLI

# Full health check on current directory
qaradar analyze

# Analyze a specific repo with 180 days of history
qaradar analyze /path/to/repo --days 180

# Output as JSON (for piping to other tools)
qaradar analyze --json-output

# Show top 10 risky modules only
qaradar analyze --top 10

# Diff-aware: score only files changed since main
qaradar analyze . --base main

Instalación

pip install qaradar

O ejecuta sin instalar:

uvx qaradar serve

Desde el código fuente (para desarrollo):

git clone https://github.com/Muratkus/qaradar.git
cd qaradar
pip install -e .

Soporte de Lenguajes

Todo el soporte de lenguajes vive en un solo registro — qaradar/analyzers/languages.py — por lo que agregar un lenguaje es una sola entrada (extensiones, convención de nombres de pruebas, contador de funciones de prueba), consumida tanto por churn como por mapeo de pruebas.

Nivel 1 — De primera clase, probado

Lenguaje	Detección de pruebas	Cobertura
Python	`test_x.py`, `x_test.py`	JSON + XML de coverage.py
JavaScript / TypeScript	`x.test.`, `x.spec.`, `x-test.*` (React Native)	LCOV, JSON de Jest/Istanbul
Go	`x_test.go`	Perfil de cobertura de Go (`cover.out`)
Swift	`XTests.swift` (XCTest `func test…`)	Cobertura / LCOV
Kotlin	`XTest.kt` (`@Test`)	Cobertura / LCOV
Dart / Flutter	`x_test.dart` (`test(`, `testWidgets(`)	LCOV (`coverage/lcov.info`)
Objective-C	`XTests.m` / `.mm` (XCTest `- (void)test…`)	Cobertura / LCOV

Nivel 2 — Mejor esfuerzo, basado en nombres

Java, Ruby, Rust — detección de pruebas mediante convenciones de nombres. Cobertura mediante XML de Cobertura o LCOV si se emite.

El análisis de cobertura está impulsado por formato, por lo que abarca más ecosistemas que la detección de mapeo de pruebas, que es específica del lenguaje.

Monorepos: los informes de Istanbul/Jest se descubren automáticamente bajo packages/*/coverage y apps/*/coverage, y las rutas de cobertura absolutas/relativas al paquete se normalizan a relativas al repositorio para que se unan correctamente contra las señales de churn y mapeo de pruebas.

Formatos de Cobertura Soportados

Formato	Herramientas
JSON de coverage.py	Python `coverage run` + `coverage json`
JSON de Istanbul / Jest	`coverage-final.json`, `coverage-summary.json` (Jest/Vitest/nyc)
XML de Cobertura	Python, Java/Gradle, .NET (Coverlet)
LCOV	JS/TS, Flutter/Dart, C/C++, Rust (grcov)
Perfil de cobertura de Go	`go test -coverprofile=cover.out`

Ejemplo de Salida

╭──────────────── QA Radar Health Report ─────────────────╮
│ Repository: /home/user/my-service                       │
│ Source files: 47  Test files: 23  Ratio: 0.49           │
│ Avg coverage: 62.3%  Tested: 31  Untested: 16          │
╰─────────────────────────────────────────────────────────╯

  CRITICAL risk modules: 3
  HIGH risk modules: 7

┌─────────────────────────────────────────────────────────┐
│ Risky Modules                                           │
├──────────────────────┬──────────┬───────┬───────────────┤
│ File                 │ Risk     │ Score │ Reasons       │
├──────────────────────┼──────────┼───────┼───────────────┤
│ src/payments/core.py │ CRITICAL │  0.87 │ High churn:   │
│                      │          │       │ 34 commits;   │
│                      │          │       │ No tests      │
│ src/auth/tokens.py   │ CRITICAL │  0.82 │ Low coverage: │
│                      │          │       │ 12.3%; Active │
│                      │          │       │ recently      │
└──────────────────────┴──────────┴───────┴───────────────┘

Seguimiento de Ejecuciones a lo Largo del Tiempo

Por defecto, QA Radar no tiene estado. Opta por la persistencia para rastrear un repositorio a través de ejecuciones y impulsar el re-análisis incremental (diario/semanal, o después de N diffs, o después de que un agente termine el trabajo).

qaradar analyze . --save      # record a snapshot to .qaradar/state.json (gitignore it)
qaradar should-run .          # exit 0 if a re-run is warranted, 1 if not — prints JSON
qaradar status .              # last run, commits/days since, current decision + risk delta

should-run es una puerta, no un programador — conéctalo a lo que ya uses:

# cron / CI / git hook: only do expensive work when criteria are met
qaradar should-run . && qaradar analyze . --save

Informa scope: "full" (intervalo transcurrido) o scope: "diff" (suficientes archivos cambiados), para que un agente que llame a la herramienta MCP qaradar_should_run sepa si debe continuar con qaradar_healthcheck o qaradar_pr_risk. El estado es un .qaradar/state.json por repositorio, por lo que una "colección de repositorios" es solo un bucle sobre repositorios en tu propia infraestructura.

Ajusta los criterios en qaradar.toml:

[schedule]
interval_days = 7        # re-run the full healthcheck at least weekly
min_changed_files = 25   # ...or sooner, once this many files have changed

--save también informa un delta vs. la ejecución anterior — qué archivos se volvieron riesgosos recientemente, cuáles empeoraron, cuáles mejoraron o se resolvieron.

Hoja de Ruta

v0.1.2 — Plugin de Claude Code + comandos de barra
v0.2.0 — Archivo de configuración (qaradar.toml), validación de lenguajes de Nivel 2, endurecimiento
v0.3.0 — Modo consciente de diffs: qaradar_pr_risk + bandera CLI --base
v0.4.0 — Cobertura de lenguajes móviles/monorepo (Swift, Kotlin, Obj-C, Dart, React Native, Jest); persistencia de ejecuciones + criterios de re-ejecución (should-run, --save, qaradar_should_run)
v0.5.0 — Detección de pruebas flaky desde el historial de CI (análisis de XML de JUnit)

Filosofía

QA Radar se basa en tres creencias:

El cuello de botella se ha movido. La IA hace que escribir pruebas sea fácil. Saber cuáles pruebas importan es la parte difícil.
La calidad es un paisaje, no un número. Un solo porcentaje de cobertura lo oculta todo. El riesgo es por módulo, por señal, por período de tiempo.
Los agentes necesitan contexto. Un asistente de IA de codificación que no conoce las áreas frágiles de tu repositorio escribirá pruebas genéricas. Dale el paisaje de calidad y escribirá pruebas dirigidas.

Licencia

MIT