La Revolución del Pensamiento QA desde el Desarrollo
¿Alguna vez te has preguntado por qué algunos sistemas son más fáciles de probar que otros? La respuesta no está solo en nuestras habilidades como testers, sino en cómo se diseña el código desde el principio. Recientemente, un desarrollador compartió su experiencia construyendo un simulador de cajero automático que ‘funcionaba perfectamente’… hasta que decidió probarlo como un QA Tester.
Esta historia nos enseña algo fundamental: el design testeable no es un lujo, es una necesidad. Y como QA Testers hispanohablantes, necesitamos entender esta relación entre desarrollo y testing para elevar nuestro trabajo al siguiente nivel.
El Caso del ATM ‘Perfecto’: Cuando el Código Funciona Pero No Sirve
El desarrollador en cuestión construyó un sistema de cajero automático que desde su perspectiva técnica funcionaba sin problemas. El código ejecutaba, las transacciones se procesaban y no había errores en consola. ¿Problema resuelto? Para nada.
Cuando decidió ponerse el sombrero de QA Tester, la realidad fue completamente diferente:
- Transacciones que se procesaban sin validar el saldo disponible
- Números de cuenta que aceptaban cualquier formato
- Estados del sistema imposibles de verificar durante las pruebas
- Escenarios edge cases que causaban comportamientos inesperados
Este es un problema que vemos constantemente en Latinoamérica: desarrolladores que construyen funcionalidades sin considerar cómo van a ser probadas, y testers que tienen que ‘hacer magia’ para validar sistemas mal diseñados.
¿Qué es el Design Testeable y Por Qué Nos Importa Como QA?
El design testeable es una filosofía de desarrollo que considera la facilidad de testing desde la fase de diseño. No es solo escribir código que funcione, sino escribir código que se pueda probar efectivamente.
Características del código testeable:
- Observabilidad: Podemos ver qué está pasando internamente en el sistema
- Controlabilidad: Podemos manipular el estado del sistema para nuestras pruebas
- Modularidad: Componentes independientes que se pueden probar por separado
- Predecibilidad: Mismas entradas producen mismas salidas
Como QA Testers, cuando trabajamos con sistemas diseñados de esta manera, nuestro trabajo se vuelve más eficiente y efectivo. Podemos enfocar nuestro tiempo en encontrar bugs reales en lugar de luchar contra arquitecturas que no nos permiten probar adecuadamente.
La Experiencia Real: Lecciones Desde la Trinchera
En mi experiencia como QA Engineer, he visto cómo el design testeable marca la diferencia entre proyectos exitosos y pesadillas de testing. Permíteme compartir un ejemplo real:
Trabajé en un e-commerce donde el equipo de desarrollo inicialmente construyó el carrito de compras sin considerar el testing. El resultado: era imposible validar el estado intermedio del carrito, los cálculos de impuestos eran una caja negra, y simular diferentes métodos de pago requería configuraciones complejas.
Después de implementar principios de design testeable:
- Redujimos el tiempo de ejecución de pruebas manuales en un 40%
- Aumentamos la cobertura de casos edge cases en un 60%
- Los bugs encontrados en producción disminuyeron significativamente
Cómo Influir en el Design Testeable Como QA Tester
No necesitas ser developer para influir en el design testeable. Aquí te comparto estrategias que puedes implementar desde tu rol de QA:
1. Participa Desde el Diseño
No esperes a que el código esté listo. Involúcrate en las sesiones de planning y diseño técnico. Haz preguntas como:
- ‘¿Cómo vamos a validar que esta función calcula correctamente?’
- ‘¿Podemos tener visibilidad del estado interno durante las pruebas?’
- ‘¿Qué pasa si el usuario hace esto en lugar de aquello?’
2. Documenta los Pain Points
Cada vez que encuentres algo difícil de probar, documéntalo. Crea un registro de:
- Funcionalidades que requieren setup complejo
- Estados del sistema que no se pueden verificar
- Casos de prueba que no se pueden automatizar por limitaciones del diseño
3. Propón Soluciones, No Solo Problemas
En lugar de solo quejarte de que algo es difícil de probar, propón alternativas:
- ‘¿Podríamos exponer este cálculo a través de un endpoint de debug?’
- ‘¿Qué tal si agregamos logs más detallados para esta funcionalidad?’
- ‘¿Podemos separar esta lógica en un componente más pequeño?’
Herramientas y Técnicas Para Promover el Design Testeable
Como QA Testers hispanohablantes, tenemos herramientas específicas que nos ayudan a trabajar mejor con sistemas bien diseñados:
Para Testing Manual:
- Postman/Insomnia: Para validar APIs con endpoints bien documentados
- Browser DevTools: Para inspeccionar estados cuando el frontend está bien instrumentado
- Logs estructurados: Para entender el flujo de la aplicación
Para Colaboración con Developers:
- Swagger/OpenAPI: Documentación automática que facilita el testing de APIs
- Feature flags: Para probar funcionalidades de manera aislada
- Mocks y stubs: Para simular dependencias externas
El Impacto en Nuestra Carrera Como QA
Entender y promover el design testeable no solo mejora nuestro trabajo diario, sino que nos posiciona como QA Testers más valiosos. En el mercado latinoamericano, donde la competencia por roles senior de QA está creciendo, esta habilidad nos diferencia.
Beneficios para tu carrera:
- Mejor comunicación con equipos de desarrollo
- Participación más activa en decisiones arquitectónicas
- Mayor eficiencia en la ejecución de pruebas
- Preparación para roles de QA Lead o QA Architect
Conclusión: El Futuro del QA es Colaborativo
La historia del ATM simulator nos enseña que el mejor testing no viene solo de técnicas avanzadas o herramientas sofisticadas, sino de la colaboración inteligente entre desarrollo y QA desde el primer día del proyecto.
Como QA Testers hispanohablantes, tenemos la oportunidad de liderar esta transformación en nuestros equipos. No somos solo ‘los que encuentran bugs’, somos arquitectos de la calidad que influyen en cómo se construye el software desde sus cimientos.
El mensaje es claro: el mejor momento para pensar en testing es antes de escribir la primera línea de código. Y nosotros, como QA, tenemos el conocimiento y la responsabilidad de hacer que esto suceda.
¿Ya estás aplicando estos principios en tu trabajo? ¿Qué obstáculos has encontrado al intentar influir en el design testeable? Comparte tu experiencia en los comentarios y sigamos construyendo una comunidad de QA más fuerte en Latinoamérica.
¿Te resultó útil este artículo?
Compártelo con otros QA Testers hispanohablantes.
Si tienes preguntas o quieres profundizar en algún tema,
escríbeme — estoy aquí para ayudarte.
Fuente de referencia: https://dev.to/enayet_rashid_bd/bridging-development-and-qa-my-journey-from-code-design-to-manual-testing-mastery-jnm
