QA y automatización de pruebas

No. Automatice lo que se ejecuta con frecuencia y debe dar siempre el mismo resultado: pruebas unitarias, pruebas de API y los recorridos de extremo a extremo más importantes. Reserve a las personas para las pruebas exploratorias, la usabilidad y las funcionalidades nuevas que todavía cambian. Un conjunto más pequeño que se ejecuta con cada cambio y nunca falla al azar vale más que uno grande en el que nadie confía.

Usamos las herramientas que encajan con su stack y su equipo: Playwright o Cypress para las pruebas web de extremo a extremo, Appium para aplicaciones móviles, Jest, JUnit o pytest para las pruebas unitarias, Postman para las comprobaciones de API, k6 o JMeter para el rendimiento y OWASP ZAP para los análisis de seguridad. Siempre que podemos, mantenemos las pruebas en su repositorio y en el lenguaje de sus ingenieros, para que puedan mantenerlas.

El número de aplicaciones y recorridos incluidos, lo fácil que sea probar el código actual, el estado de sus datos y entornos de prueba, y cuántas integraciones hay que simular. Una aplicación antigua sin puntos de prueba estables requiere más esfuerzo que una nueva desarrollada pensando en las pruebas. Empezamos por los recorridos de mayor riesgo, para que el valor llegue pronto.

Sí. A menudo nos sumamos a un equipo de QA propio para aportar competencias de automatización, asumir las pruebas de rendimiento o de seguridad, o cubrir un periodo de mucha carga. Acordamos cómo se reparte el trabajo, usamos las mismas herramientas y el mismo backlog, y formamos a sus probadores para que amplíen los conjuntos que creamos.

Usamos el entorno de pruebas o sandbox del socio cuando existe, y simuladores cuando no, para que las pruebas puedan ejecutarse con cada cambio sin depender de un tercero. Los datos de prueba cubren los casos desfavorables: pagos rechazados, tiempos de espera agotados, mensajes duplicados y fallos parciales. Las comprobaciones de extremo a extremo confirman que los totales concilian entre sistemas, no solo que cada llamada devolvió un resultado correcto.

Tratamos una prueba poco fiable como un defecto. Se aparta para que no bloquee las publicaciones, se busca y corrige su causa, y se reincorpora. Las causas habituales son los datos de prueba compartidos, las suposiciones sobre tiempos y los entornos inestables. Hacemos un seguimiento de la estabilidad de las pruebas a lo largo del tiempo, para que el conjunto siga siendo uno en el que su equipo pueda confiar.

Tiene un responsable de entrega designado y un ritmo regular: planificación al inicio de cada iteración, una demostración de software funcionando al final y un breve informe escrito sobre avances, riesgos y decisiones. Puede consultar el backlog, el repositorio de código y los resultados de las pruebas en cualquier momento. Las reuniones de seguimiento con sus patrocinadores se celebran con la periodicidad que usted elija.