QualityLabs

La IA ha acelerado el desarrollo.
Las pruebas no han seguido el ritmo.

Ponemos tus pruebas a ese mismo ritmo: automatización, carga y rendimiento, y un equipo formado para hacerse cargo de ellas.

Empieza con una auditoría gratuita o escribe a hello@qualitylabs.eu

Para qué nos llaman

Cinco problemas, y rara vez llegan solos.

  • La IA escribió las pruebas, y nunca pueden fallar.

    Pide a la IA que pruebe tu proceso de compra y obtendrás pruebas que pasan a la primera y todas las veces siguientes. Pulsan un botón solo si da la casualidad de que está ahí, esperan tres segundos fijos y no comprueban nada importante. La cifra de cobertura sube. El riesgo no baja.

    Leemos lo generado, nos quedamos con las pruebas que detectarían un problema por el que merecería la pena despertar a alguien, arreglamos las que casi lo harían y borramos el resto. Después fijamos un estándar de revisión para que las próximas mil no lleguen igual.

    Generado, sin revisar típico 
    test('checkout works', async ({ page }) => {
  await page.goto('/checkout');
  await page.waitForTimeout(3000);

  const btn = page.locator('.btn-primary').first();
  if (await btn.isVisible()) await btn.click();

  expect(true).toBeTruthy(); // siempre en verde
});
    Lo que sobrevive a la revisión se queda 
    test('charged exactly once', async ({ page }) => {
  const cart = await seedCart({ sku: 'SKU-118' });

  await page
    .getByRole('button', { name: 'Place order' })
    .click();

  await expect(page).toHaveURL(/\/confirmation\//);
  expect(await chargesFor(cart)).toHaveLength(1);
});

  • La IA multiplicó los cambios. El tiempo para revisarlos sigue siendo el mismo.

    Cuando un equipo empieza a escribir código con IA, el número de cambios pendientes de revisar sube mucho antes de que nadie piense en cambiar cómo se revisan. Las dos o tres personas que el año pasado podían revisar cada cambio ya no pueden, así que la revisión se convierte en comprobaciones puntuales, sin que nadie lo haya decidido.

    Contratar no cierra una brecha así, y pedir a la gente que vaya más rápido tampoco. Lo que la cierra es decidir qué necesita de verdad una prueba, hacer que el resto sea rápido y automático, y dar a quienes revisan el trabajo las mismas herramientas de IA que ya tienen los desarrolladores.

    Cambio que llega, frente a capacidad para revisarlo La forma de la brecha. No es una medición de tu equipo. Cambios hechos por semana Capacidad para revisarlo y probarlo antes ahora

  • Funciona en las pruebas y se cae en tu día de más tráfico.

    El tráfico intenso saca a la luz problemas a los que las pruebas normales nunca llegan: una base de datos dimensionada para el año pasado, una página que iba rápida con mil clientes y se arrastra con cincuenta mil, un proveedor que te corta el servicio en plena campaña.

    Simulamos el tráfico que de verdad esperas, sobre un entorno lo bastante parecido al real como para que signifique algo, y encontramos lo primero que cede. Te llevas el punto en el que se rompe, con una cifra, y la pieza responsable, no un gráfico con el que nadie puede hacer nada.

    Qué ejecutamos
    Un día normal, tu hora de más tráfico y una prueba lo bastante larga como para que las fugas lentas se dejen ver.
    Qué buscamos
    La primera parte del sistema que llega a su tope, y luego la que tiene detrás, que era el verdadero límite desde el principio.
    Qué te quedas
    El punto de ruptura, lo que lo provoca y el cambio que haríamos para subirlo.

  • Las pruebas antiguas que nadie quiere tocar.

    Seis años de pruebas en una herramienta antigua como Selenium, servidores que alguien tiene que mantener vivos para ejecutarlas y unos resultados que la gente ha aprendido a poner en duda en lugar de creérselos. Aun así, guardan conocimiento real sobre el producto, y por eso borrarlas todas es tan erróneo como reescribirlas todas.

    Cuando merece la pena conservar las pruebas antiguas tal como están, las cuidamos allí. Cypress, Selenium y WebdriverIO incluidos.

    Paso uno
    Un inventario. Buena parte de casi cualquier conjunto de pruebas antiguas no merece la pena moverla, y decimos cuál es la parte valiosa.
    Paso dos
    Un piloto con entre el 10 y el 15 % de las pruebas, funcionando de verdad, para que el coste del resto se conozca en lugar de adivinarse.
    Paso tres
    El resto, con una persona concreta de tu lado implicada desde el primer día y no solo en el traspaso.

  • Todas las pruebas pasan. La aplicación sigue yendo lenta.

    Todas las pruebas pueden pasar y el producto seguir dando mala sensación. Toques que tardan un momento en responder, una página que salta mientras carga, una primera pantalla que llega a trozos. Nada de eso aparece en los resultados de las pruebas, y todo aparece en cómo se comportan tus clientes.

    Lo medimos en los dispositivos de tus usuarios reales y no en un laboratorio, rastreamos cada problema hasta su causa y proponemos el cambio que lo arregla, no un panel que lo reporta.

    LCP
    Cuánto tarda en aparecer en pantalla aquello para lo que existe la página.
    INP
    Cuánto tarda la interfaz en responder a un toque. La que la mayoría de los equipos nunca ha mirado, y la que los usuarios describen como que el sitio pesa.
    CLS
    Cuánto se mueve la página después de que alguien haya empezado a leerla.

Nuestro equipo ha construido y entregado calidad en

Mercados regulados y no regulados: servicios financieros y trading de alta frecuencia, cripto y activos digitales, portales inmobiliarios, navegadores a escala de consumo y unos cuantos nichos entre medias.

El argumento

Lo que falta nunca ha sido una herramienta.

La mayoría de los equipos con los que hablamos ya han probado alguna herramienta para esto, a menudo varias. Las herramientas cumplen lo que prometen. Ninguna puede decirte cuáles son los doce de tus cuatrocientos comportamientos sobre los que se sostiene el negocio, y decidirlo es la mayor parte del trabajo. Cuatro generaciones de herramientas se han vendido como sustituto de la persona que toma esa decisión. Ese sustituto no existe.

Esto no es un argumento contra la IA. Buena parte de nuestro propio trabajo funciona con ella. La mejor medición independiente cifró su ahorro en este trabajo en un 24,9 %, frente a una categoría que anuncia minutos. Recuperar una cuarta parte del esfuerzo es una ganancia real. Sigue sin ser el trabajo.

La plataforma
Era dueña de tus pruebas. Arreglar una suponía abrir un ticket de soporte.
La prueba que se repara sola
Repara igual un botón que se ha movido y una regla de negocio que ha cambiado. Solo uno de los dos debería pasar.
Las pruebas escritas por IA
Amplitud sin prioridades, cuando el riesgo está repartido de cualquier forma menos uniforme.
El revisor con IA
Ve el cambio en el código, no el incidente pasado que explica por qué ese código estaba ahí.

La versión larga, generación a generación (en inglés)

Qué hacemos

Probar no es toda la calidad.

Desde la primera prueba hasta la carga que tumba el sistema, y el equipo que se hace cargo después.

Tu web, probada automáticamente

Pruebas automáticas para los recorridos de los que vive tu negocio, como el registro o la compra, comprobando lo que importa y ejecutándose con cada cambio. Hechas en Playwright.

Los sistemas detrás de tu aplicación

Pruebas para los servicios y datos de los que depende tu aplicación, incluido lo que pasa cuando algo falla. Rápidas, porque no interviene ninguna pantalla.

Tus apps de iOS y Android

Pruebas automáticas para tus apps móviles con Appium, o con las herramientas propias de Apple y Google cuando encajan mejor.

Mover o mantener pruebas antiguas

Pruebas en herramientas antiguas como Selenium o Cypress, pasadas a Playwright: un inventario, un piloto y después el resto. O las dejamos donde están y las cuidamos.

Revisión de pruebas generadas por IA

Nos quedamos con las pruebas que comprueban algo real, arreglamos las que casi lo hacen y fijamos un estándar de revisión para el siguiente lote.

Pruebas de carga

Cuánto tráfico aguanta tu sistema antes de romperse, y qué parte se rompe primero. Hechas en k6 e incluidas con una migración.

Rendimiento y experiencia de usuario

Lo rápido que se siente tu producto para los usuarios reales, medido en sus dispositivos y rastreado hasta la causa, con la solución propuesta en lugar de un panel.

Pruebas con cada cambio

Tus pruebas ejecutándose solas cada vez que cambia el código, en las herramientas que ya usas, y lo bastante rápidas como para que nadie se las salte.

Formación

Playwright, flujos automatizados y cómo usar la IA en el trabajo de calidad sin fiarse de ella a ciegas. Codo con codo durante el proyecto, talleres en el traspaso.

Herramientas con las que trabajamos

  • Playwright
  • TypeScript
  • Python
  • k6
  • Lighthouse
  • Web Vitals
  • Selenium
  • Cypress
  • WebdriverIO
  • Appium
  • XCUITest
  • Espresso
  • GitHub Actions
  • GitLab CI
  • Azure DevOps
  • Jenkins

Cómo funciona

Cuatro pasos, y puedes parar después de cualquiera.

  1. Auditoría

    Alrededor de una semana, gratis. Recibes un inventario por escrito de tus pruebas, un plan sobre qué hacer con ellas y una opinión sin rodeos sobre qué merece la pena conservar. Es tuyo tanto si nos contratas como si no.

  2. Piloto

    Una parte real de tus pruebas, no una demo, trasladada y pasando con cada cambio que hace tu equipo. Aquí es donde descubres si la estimación se sostiene, mientras cambiar de rumbo todavía sale barato.

  3. Migración y formación

    El grueso del trabajo, por etapas, con tus ingenieros trabajando a nuestro lado. La formación no es solo un taller al final. Es la forma en que se hace el trabajo.

  4. Traspaso

    Documentación del proyecto, talleres de transferencia de conocimiento y un equipo capaz de ampliar las pruebas por su cuenta. Soporte después, si lo quieres.

Notas

Lo que pensamos, con el razonamiento a la vista.

En esta página no hay logotipos de clientes haciéndose pasar por recomendaciones. Lee los argumentos y decide si sabemos lo que hacemos. Las notas están en inglés.

Empieza aquí

Cuatro generaciones de pruebas que se reparan solas, y la misma persona que falta

Una plataforma que era dueña de tus pruebas, luego pruebas que se reparaban solas, luego una IA que escribe las pruebas y ahora una IA que revisa cada cambio. Cada una es mejor ingeniería que la anterior, y cada una se vendió como una forma de prescindir de la persona que entiende el producto. Esa persona era la única pieza que sostenía el peso.

Leer la nota

Lo que no aceptamos

Las migraciones que rechazamos, y los casos en los que borrar las pruebas es mejor que moverlas.

Leer la nota

Dónde falla de verdad la IA al migrar pruebas

Un estudio controlado cifró el ahorro en un 24,9 %, no en «minutos». Estos son los seis puntos donde falla una y otra vez, y por qué.

Leer la nota

Las pruebas inestables vienen en grupos

Tres cuartas partes de las pruebas inestables comparten causa con una docena más. Arreglarlas de una en una es la razón por la que la cola nunca se vacía.

Leer la nota

Tu suite no es lenta. Te está mintiendo.

La duración es la métrica fácil. La confianza es la que decide si merece la pena ejecutar las pruebas. Aquí van cuatro formas de medirla.

Leer la nota

Análisis

Las migraciones de otros, leídas con atención.

No tenemos casos de clientes que enseñarte, así que no vamos a inventarnos ninguno. En su lugar, tomamos los relatos públicos mejor documentados de este campo y los leemos a fondo, incluidas las partes que argumentan en contra de contratar a nadie. Cada cifra de abajo remite a una fuente publicada que puedes comprobar. Los análisis están en inglés.

Cómo es el calendario real de una migración de Selenium

Cien pruebas, ocho meses, dos conjuntos de pruebas funcionando en paralelo. La cifra con la que los proveedores nunca abren.

Leer el análisis

Dos semanas, 200 pruebas y la parte que todos se saltan

Quince días para 200 pruebas, GPT-4 inventándose comprobaciones que no existen, y por qué un 71 % de éxito en un portátil se quedó en un 44 % en el servidor de integración.

Leer el análisis

El proyecto de automatización que encontró ocho bugs en tres años

Una directora de calidad publicó su propio fracaso de tres años. Volver a las pruebas manuales quizá fue lo correcto.

Leer el análisis

Zalando hace pruebas de carga en producción. Esta es la razón.

A 7200 pedidos por minuto, una copia de pruebas del sitio deja de decirte nada que merezca la pena saber.

Leer el análisis

Nadie va a venir a probarlo por ti

Amazon pasó de diez ingenieros por tester a cien. El trabajo de pruebas no desapareció.

Leer el análisis

Empieza por la auditoría.

Cuéntanos con qué está hecho tu producto y cómo lo pruebas hoy. Volvemos con lo que tus pruebas comprueban de verdad, los riesgos que nada cubre y dónde lo que falta es criterio y no herramientas. A veces la respuesta es menos de lo que piensas. El documento te lo quedas en cualquier caso.

Solicitar la auditoría o escribe a hello@qualitylabs.eu

Quiénes somos

Un equipo pequeño, con más de 30 años de este trabajo a la espalda.

Somos una boutique, no una agencia. Quienes definen el trabajo son quienes lo hacen, y aceptamos pocos proyectos a la vez porque es lo que hace falta para hacerlos bien.

Estamos en la UE y trabajamos en horarios europeos y de EE. UU. Usamos mucho la IA en nuestro propio trabajo y hablamos claro sobre dónde ayuda y dónde no. Es el mismo criterio que enseñamos a tu equipo.

Preguntas

Lo que nos preguntan antes de la auditoría.

Si falta algo aquí, pregúntalo en el correo. La respuesta tampoco cuesta nada.

¿Qué obtenemos exactamente de la auditoría gratuita?

Un inventario por escrito de tus pruebas, lo que cada parte comprueba de verdad, las partes del producto con un riesgo que nada cubre y un plan para mover las pruebas cuando tiene sentido. Nos lleva alrededor de una semana de nuestro tiempo y muy poco del tuyo.

El documento es tuyo tanto si nos contratas como si no. A veces la respuesta es que necesitas menos de lo que crees, y te lo diremos.

¿Cómo se desarrolla un proyecto?

En cuatro pasos: la auditoría, un piloto que pasa con cada cambio, el grueso del trabajo con tus ingenieros a nuestro lado, y un traspaso. Cada uno termina con algo que puedes usar por sí solo, así que puedes parar después de cualquiera.

El piloto existe para que la estimación del resto se mida sobre tu código y no se adivine a partir del nuestro. Los pasos, en detalle.

¿Hacéis vosotros el trabajo, o lo hace nuestro equipo?

Ambos, desde el primer día. Nosotros hacemos el trabajo pesado, y un responsable con nombre y apellidos en tu lado trabaja con nosotros en lugar de conocer las pruebas al final. Cuánto lleva cada parte se acuerda desde el principio y puede cambiar a medida que tu equipo gana soltura.

Quienes definen el trabajo son quienes lo hacen. No hay un traspaso a un equipo de entrega al que no conoces.

Hoy tenemos muy poca automatización. ¿Es pronto para llamaros?

Es un buen momento. Empezar con poco significa que no hay nada que deshacer. Montamos cobertura donde no la hay, separamos tus comprobaciones manuales entre lo que merece la pena automatizar y lo que no, y lo ponemos a funcionar en las herramientas que ya usas. Tu equipo aprende los hábitos mientras las pruebas son pocas, que es cuando menos cuesta aprenderlos.

Nuestras pruebas usan una herramienta antigua como Selenium o Cypress. ¿Tenemos que cambiar?

No. Cuando merece la pena conservar tus pruebas tal como están, las mantenemos y las mejoramos ahí: Cypress, Selenium y WebdriverIO incluidos. Cuando pasarlas a Playwright se paga solo, las movemos por etapas, nunca todas de golpe, y algunas pruebas es mejor borrarlas que moverlas. La auditoría dice cuál es cuál, prueba a prueba.

¿Hay trabajos que no aceptáis?

Sí. Una migración sin nadie en tu lado que se haga cargo después. Un encargo de mover todas las pruebas antes de una fecha sin un piloto previo. Y automatizar trabajo que necesita el criterio de una persona, como las pruebas exploratorias y las revisiones de accesibilidad. Si las pruebas fallan al azar porque la aplicación no se puede devolver al mismo punto de partida antes de cada una, lo decimos antes de migrar nada, porque mover las pruebas solo movería el problema. La lista completa, y por qué (en inglés).

¿Cuánto se tarda?

La auditoría lleva alrededor de una semana. Todo lo que viene después depende del tamaño y el estado de tus pruebas, y precisamente por eso lo siguiente es el piloto: convierte la estimación del grueso en una cifra medida sobre tu código. Desconfía de quien te presupueste una migración completa antes de haber visto una parte funcionando. Cómo es un calendario real (en inglés).

¿Qué pasa cuando os vais?

Tu equipo está preparado para seguir sin nosotros. El traspaso consiste en documentación del proyecto y talleres de transferencia de conocimiento.

Seguimos ofreciendo soporte una vez terminado el proyecto. Tiene distintos niveles, según cuánto quieras tenernos cerca, y puede ampliarse según las condiciones que acordemos.