Automatiza lo que un script verifica igual en cada ejecución: recorridos críticos de punta a punta, peticiones fallidas, errores de consola, reglas de accesibilidad y cada tamaño de pantalla. Deja manual lo que pide criterio: las pruebas exploratorias, si un flujo tiene sentido, el uso con lector de pantalla. Nuestro paquete Fundamentos de automatización de QA hace la primera parte con tus 5 flujos críticos, corriendo en CI y con controles de accesibilidad, por USD 5,000 en dos semanas.
Hacemos QA manual y automatizado en productos propios y de clientes, y las reglas de abajo salen de ahí. Te muestro cómo es un test que escribiríamos de verdad y dónde dejaría de automatizar.
¿Qué diferencia hay entre QA y testing?
QA (aseguramiento de calidad) es toda la práctica de asegurar que el software haga lo que debe: cómo se escriben los requisitos, cómo se revisan los cambios, qué frena una versión. El testing es una actividad dentro de eso: ejecutar el software y verificar el resultado. Un equipo puede tener muchísimas pruebas y un QA débil, si las pruebas verifican lo que no importa o nadie reacciona cuando fallan.
Pesa al tercerizar. Si compras “testing”, recibes casos de prueba. Si compras QA, deberías recibir menos defectos en producción. Si quieres comprarlo así, Fundamentos de automatización de QA es el paquete de precio fijo con el que empezamos.
¿Qué es la automatización de pruebas?
Es escribir código que usa tu aplicación como lo haría una persona (abre páginas, hace clic, completa formularios) y verifica el resultado sin intervención humana. Corre en segundos, en cada cambio, siempre igual. Su límite es que solo verifica lo que alguien pensó en verificar.
¿La IA va a reemplazar al QA?
No en la parte que exige criterio. La IA ya ayuda a escribir código de pruebas y a generar datos, y así la usamos. Pero decidir qué importa lo suficiente para probarlo sigue siendo una decisión humana. También es humano darse cuenta de que un flujo es correcto en lo técnico y confuso en la práctica, y hacerse cargo de que una versión no está lista.
La guía de accesibilidad de Playwright lo dice directo: las pruebas automatizadas detectan algunos problemas comunes, pero muchos problemas de accesibilidad solo se descubren con pruebas manuales. Y eso vale mucho más allá de la accesibilidad.
¿Qué conviene automatizar con Playwright?
Todo lo que un script puede verificar de forma idéntica en cada corrida y que dolería si se rompiera sin que nadie lo notara. Empieza por los recorridos críticos, con clics como un usuario: registro, inicio de sesión, el formulario que te genera ingresos. No “la página carga”, sino “el usuario llega al final”. Mientras corre el flujo, vigila la red (cualquier respuesta 4xx o 5xx, cualquier petición fallida) y la ejecución (excepciones no capturadas y errores de consola, que una captura de pantalla nunca muestra). Suma las reglas de accesibilidad que axe puede verificar, como etiquetas faltantes, contraste e IDs duplicados. Corre todo en cada tamaño de pantalla que soportas, como mínimo uno de escritorio y uno de teléfono.
Un test que solo toma una captura demuestra que la página se dibujó. Uno que recorre el flujo y falla ante cualquier error demuestra que funciona. Esta es la forma que usamos:
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";
test("el recorrido de contacto funciona y es accesible", async ({ page }) => {
const problemas: string[] = [];
page.on("pageerror", (e) => problemas.push(`excepción: ${e.message}`));
page.on("console", (m) => m.type() === "error" && problemas.push(`consola: ${m.text()}`));
page.on("requestfailed", (r) => problemas.push(`fallida: ${r.url()}`));
page.on("response", (r) => r.status() >= 400 && problemas.push(`${r.status()}: ${r.url()}`));
await page.goto("/es/");
await page.getByRole("link", { name: "Contacto" }).click();
await page.getByLabel("Correo").fill("qa@example.com");
await page.getByRole("button", { name: "Enviar" }).click();
await expect(page.getByRole("status")).toContainText("Gracias");
const axe = await new AxeBuilder({ page })
.withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"])
.analyze();
expect(axe.violations).toEqual([]);
expect(problemas).toEqual([]);
});
Se corre una vez por tamaño de pantalla con los projects de playwright.config.ts, por ejemplo uno a 1440 × 900 y otro a 390 × 844. Es la misma estructura del recorrido que hicimos para una plataforma que centraliza las solicitudes y aprobaciones entre áreas de una organización. En un build local, 10 pasos a 1440 y 390 píxeles de ancho, con cero peticiones fallidas, cero errores de consola y cero violaciones de axe en las páginas evaluadas.
¿Qué pruebas deben seguir siendo manuales?
Las que un script no puede juzgar. Primero, las pruebas exploratorias: una persona con un objetivo y un tiempo acotado, intentando romper la funcionalidad de formas que nadie escribió. Después la pregunta “¿esto tiene sentido?”, porque un flujo puede pasar todas las aserciones y aun así confundir. También los lectores de pantalla y el uso solo con teclado, de punta a punta. Las reglas automáticas detectan etiquetas faltantes, pero no te dicen si la experiencia funciona cuando no ves la pantalla. Y las funcionalidades nuevas cuyo comportamiento todavía cambia, porque automatizar un flujo que se modifica todos los días da tests que terminan borrados.
Mi regla es automatizar la verificación y dejar el testing en manos humanas. Verificar confirma lo que ya sabes que debe ser cierto. Probar descubre lo que no sabías que había que preguntar.
¿Cuánto cuesta tercerizar QA?
Con nosotros hay dos formas. Fundamentos de automatización de QA son USD 5,000 fijos, dos semanas, para una suite de Playwright con tus 5 flujos críticos en CI más controles de accesibilidad. O tomas un ingeniero de QA por hora vía staff augmentation: USD 30 como junior, 35 a 40 como semi senior, 45 a 50 como senior.
Como referencia de Estados Unidos, el BLS informa un salario mediano de USD 50.14 por hora para analistas de QA y testers de software en mayo de 2025. Es un salario. El costo total para el empleador es mayor, así que no se compara de forma directa con una tarifa facturada. Cómo compararlos bien está en el artículo sobre tarifas, y todo junto en precios.
¿Qué herramientas usamos para automatizar pruebas?
Para productos web partimos de Playwright para los recorridos en navegador (Chromium, Firefox y WebKit con una sola API) y @axe-core/playwright para las reglas de accesibilidad dentro de los mismos tests. Para la lógica usamos el runner de pruebas unitarias del proyecto (Jest, Vitest o el nativo del lenguaje). Las uniones entre componentes las cubren pruebas de integración contra un servidor y una base de datos locales reales, sin mocks.
Cuando el producto pide más, lo sumamos. En el portal de una plataforma de publicidad con IA que construimos para un cliente, los recorridos corren también solo con teclado, en modo oscuro, con colores forzados y con zoom al 400 %. Hay además verificaciones de fidelidad contra los diseños aprobados en Figma. En una plataforma PropTech de vivienda, los recorridos en navegador cubren 13 variantes, con comparación píxel a píxel contra los diseños aprobados y pruebas de punta a punta contra un servidor local real.
¿Vale la pena automatizar pruebas?
Cuando los tests fallan por razones reales. No cuando son inestables, verifican lo que no importa o tardan tanto que nadie los corre. Cuatro hábitos mantienen honesta a una suite.
Afirma sobre el resultado: “el mensaje de estado dice Gracias” vale más que “se hizo clic en el botón”. Junta los errores de consola y las peticiones fallidas en cada test, como arriba, para que los errores que no ves igual hagan fallar la corrida. Usa roles y etiquetas como selectores, porque getByRole y getByLabel se rompen cuando se rompe la accesibilidad, que es lo que quieres. Y nunca debilites un test para ponerlo en verde: un test que cambió para pasar sin que cambiara el requisito es un test borrado con pasos extra.
¿Cuáles son los tipos de pruebas de software?
Por nivel, de abajo hacia arriba. Las unitarias verifican una función o módulo aislado. Las de integración, varios componentes juntos, idealmente con dependencias reales. Las de punta a punta, la aplicación completa como la usa una persona, y las de aceptación, contra los criterios del negocio. Por objetivo, son funcionales (¿hace lo que debe?) o no funcionales (accesibilidad, rendimiento, seguridad). Una buena suite tiene muchas unitarias, las de integración necesarias y pocas de punta a punta, bien elegidas, porque son las más lentas y las más caras de mantener.
¿Cómo tercerizo QA sin perder el control?
Pídele a cualquier proveedor, a nosotros también, tres cosas por escrito. Dónde viven los tests: en tu repositorio, corriendo en tu pipeline, legibles para tu equipo. Qué rompe la compilación: qué controles frenan una versión y cuáles solo informan. Y qué cubre un “pasó”: qué recorridos, tamaños de pantalla y navegadores, para que un resultado verde signifique algo concreto. Si esas respuestas son vagas, los informes también lo serán.
Si quieres ver cómo quedaría en tu producto, nombra tus 5 flujos críticos y empieza Fundamentos de automatización de QA: USD 5,000, 2 semanas.
Fuentes
- W3C, WCAG 2.2, Recomendación publicada el 5 de octubre de 2023 y actualizada el 12 de diciembre de 2024. Consultada el 6 de octubre de 2026.
- Playwright, accessibility testing y documentación de la API de axe-core, consultadas el 6 de octubre de 2026. Versiones en el registro de npm ese día: Playwright 1.63.0, @axe-core/playwright 4.13.0.
- BLS, Occupational Employment and Wage Statistics: analistas de QA y testers de software (SOC 15-1253), mayo de 2025, mediana USD 50.14 por hora. Consultada el 6 de octubre de 2026.