Antes de montar Nika Studio trabajé dos años como QA Engineer, como único responsable de calidad de una app móvil para iOS y Android con su backend y su panel de administración. Mi trabajo era encontrar lo que fallaba antes de que lo encontrara el usuario. Ahora construyo webs, y esa forma de mirar el software no se ha ido.
Los casos de prueba como puerta de salida
En aquel equipo, una tarea solo avanzaba cuando todos sus casos de prueba estaban en verde. Hoy hago lo mismo con mi código: antes de dar algo por terminado, defino qué tiene que pasar y en qué casos no puede romperse.
Pensar en el usuario que no sigue el camino feliz
Como QA aprendí que los fallos no aparecen cuando todo va bien, sino con un campo vacío, un dato raro, un móvil pequeño o una conexión lenta. Por eso valido en el servidor todo lo que llega, pruebo las webs en móvil y reviso la accesibilidad.
Automatizar lo que se repite
Una regresión manual antes de cada release es cara y se acaba saltando. En mis proyectos, cada cambio pasa automáticamente por una pipeline con tests unitarios, tests de API, tests E2E con Playwright y revisiones de accesibilidad con axe. Si algo se rompe, me entero yo antes que el cliente.
Un fallo bien reportado ya está medio resuelto
Pasos para reproducirlo, qué se esperaba y qué pasó, evidencias. Lo aplico ahora cuando un cliente me avisa de algo: primero lo reproduzco, después lo arreglo y por último añado un test para que no vuelva.
Qué gana el cliente
Webs que no solo funcionan el día de la entrega, sino que siguen funcionando cuando se cambian, porque cada cambio pasa por los mismos controles.
