Ingeniería de Software
Pruebas que detectan regresiones, no pruebas que inflan un porcentaje de cobertura
Una suite de pruebas vale la pena cuando te permite desplegar un viernes. La mayoría no lo hacen, por una de dos razones: prueban el código en lugar del comportamiento, por lo que se rompen cada vez que se refactoriza algo y pasan aunque el proceso de pago esté roto — o son tan inestables que todo el mundo las vuelve a ejecutar hasta que se ponen en verde.
Orientativo
Desde £4,500
Precio fijo acordado por escrito antes de comenzar cualquier desarrollo.
Solicitar presupuesto+44 7488 265083El problema que resuelve
El porcentaje de cobertura es la métrica que causa esto. Perseguir el 80% produce cientos de pruebas en funciones triviales y ninguna en los cuatro flujos que generan tus ingresos. Mientras tanto, una suite inestable es activamente perjudicial: enseña al equipo a ignorar el rojo, lo que es peor que no tener pruebas en absoluto.
Qué obtendrá
Prueba los flujos que generan ingresos
Registro, inicio de sesión, búsqueda, añadir al carrito, proceso de pago, pago, gestión de pedidos. Primero, cobertura completa de extremo a extremo de estos; solo después, pruebas en cualquier otro lugar.
La prueba adecuada en el nivel adecuado
Pruebas unitarias para lógica, pruebas de integración para la capa de datos, pruebas de extremo a extremo solo para flujos reales. Las pruebas de extremo a extremo son lentas y frágiles; usarlas para todo es la razón por la que las suites se abandonan.
Tolerancia cero a la inestabilidad
Una prueba inestable es un defecto y se soluciona o elimina, nunca se vuelve a ejecutar hasta que pase. Esperas deterministas y datos generados en lugar de pausas arbitrarias.
Integrado en CI como bloqueo
Se ejecuta en cada solicitud de extracción y bloquea la fusión si falla, con un tiempo de ejecución lo suficientemente corto como para que nadie sienta la tentación de saltárselo.
Verificaciones de accesibilidad y compatibilidad entre navegadores
Verificaciones automatizadas con axe en páginas clave y ejecuciones reales en Chrome, Safari y Firefox. Los errores de diseño exclusivos de Safari son comunes e invisibles si solo pruebas en Chrome.
Fallos que puedes diagnosticar
Capturas de pantalla, vídeo y trazas registradas al fallar, para que un build en rojo sea un diagnóstico de dos minutos en lugar de una tarde de reproducción local.
Cómo trabajamos
Identificar los flujos críticos
Qué flujos, si se rompen durante una hora, te costarían dinero o clientes. Esa lista es el plan de pruebas.
Evaluar lo existente
Revisión de las pruebas actuales para determinar qué verifican realmente. Algunas se conservan, otras se eliminan: una prueba que no puede fallar de manera significativa es peor que no tener ninguna.
Construir el arnés
Carga de datos de prueba, fixtures y un entorno contra el que las pruebas puedan ejecutarse de forma repetible.
Automatizar los flujos críticos
Cobertura de extremo a extremo de los flujos prioritarios primero.
Proteger el pipeline
Integración en CI con comprobaciones obligatorias y mantenimiento de un conjunto de pruebas rápido.
Entrega
Que tus desarrolladores escriban pruebas siguiendo los mismos patrones, porque un conjunto de pruebas mantenido por un solo contratista desaparece cuando este se va.
Qué esperar
- Regresiones en flujos críticos para los ingresos detectadas antes del lanzamiento
- Un conjunto de pruebas en el que el equipo confía, de modo que el rojo significa detenerse
- Despliegues que ya no requieren una revisión manual previa
- Fallos diagnosticables desde CI sin necesidad de reproducirlos localmente
Desarrollado con
- Playwright
- Cypress
- Vitest
- Jest
- PHPUnit
- Pest
- Testing Library
- axe-core
- GitHub Actions
- Lighthouse CI
- k6
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
Pruebas de calidad y testing de software — your questions
Incluyendo las preguntas sobre coste, que la mayoría de las agencias omiten en la página.
Automatizar los recorridos críticos de una aplicación web típica cuesta entre £4,500 y £12,000, dependiendo de cuántos sean y de lo testeable que sea actualmente la aplicación. Cuando la app no tiene puntos de integración para pruebas, primero hay que refactorizar y lo presupuestamos por separado en lugar de ocultarlo.
No nos basamos en un porcentaje, porque es la métrica equivocada: un 90% de cobertura sin una prueba de pago es peor que un 40% con una. El objetivo es cubrir de extremo a extremo cada ruta crítica para los ingresos y que cada error corregido incluya una prueba que lo hubiera detectado.
Playwright para nuevos proyectos: soporte real multiplataforma incluyendo Safari, mejor paralelismo y su visor de trazas acelera mucho el diagnóstico de fallos. Cypress es una buena herramienta y mantenemos suites existentes en Cypress sin insistir en reescribirlas.
Sí. A veces la aplicación necesita pequeños cambios para ser testeable: selectores estables, un método para cargar datos de prueba o un gancho para controlar el tiempo. Esos cambios merecen la pena, porque el código difícil de probar suele ser también difícil de modificar.
Para pruebas exploratorias antes de un lanzamiento importante, sí: un humano detecta problemas de usabilidad que ninguna aserción encontraría. Para pruebas de regresión, no: repetir manualmente las mismas comprobaciones en cada lanzamiento es caro, poco fiable y es justo lo que automatizamos.
Servicios relacionados
La mayoría de los proyectos abarcan más de uno de estos servicios.
Software personalizado
Sistemas a medida que sustituyen las hojas de cálculo, los procesos manuales y las herramientas genéricas que tu empresa ha superado.
Leer másDevOps e ingeniería en la nube
Pipelines automatizados, infraestructura definida en código y monitorización que te avisa de un problema antes de que lo detecte un cliente.
Leer másDesarrollo e integración de APIs
APIs que otros desarrolladores pueden usar sin tener que preguntarte, e integraciones que se degradan correctamente cuando el servicio externo falla.
Leer másHabla con alguien que ya lo haya construido
A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.