La calidad de un producto de software no depende de una sola persona. Aunque muchas organizaciones tienen roles específicos de testing o QA, la calidad se construye con la participación de todo el equipo: testers, desarrolladores, analistas, diseñadores, responsables del negocio, líderes técnicos y usuarios.
En un proyecto sano, el testing no aparece solamente al final para "aprobar" lo que otros hicieron. El tester participa, pregunta, revisa, diseña pruebas, ejecuta verificaciones, reporta defectos y aporta información sobre riesgos. El desarrollador también prueba, revisa y cuida la calidad técnica del código.
En este tema veremos qué hace cada rol, cómo se complementan y por qué la colaboración es más importante que la separación rígida de responsabilidades.
Una idea fundamental es que la calidad no se agrega al final. Si un requisito es ambiguo, si el diseño es confuso, si el código es difícil de mantener o si nadie revisa los riesgos, las pruebas finales llegarán tarde para resolver todos los problemas de forma eficiente.
La calidad se construye desde el inicio del proyecto. Cada rol aporta algo diferente:
Un tester es una persona que evalúa el software para descubrir información relevante sobre su calidad. Su trabajo no se limita a ejecutar pasos escritos en una planilla. También implica pensar, analizar, priorizar y comunicar.
Entre sus tareas habituales se encuentran:
Un tester eficaz no solo pregunta "¿funciona?". También pregunta "¿qué podría fallar?", "¿qué impacto tendría?", "¿qué no está claro?" y "¿qué evidencia tenemos?".
El testing requiere habilidades técnicas y habilidades de análisis. Algunas de las más importantes son:
No todos los testers hacen exactamente las mismas tareas. Algunos se enfocan más en pruebas manuales, otros en automatización, otros en análisis funcional, seguridad, rendimiento o calidad de procesos. En este curso introductorio nos concentraremos en las bases comunes a todos esos caminos.
También es importante aclarar algunos malentendidos. El tester no debería ser visto como:
El valor del tester está en aportar una mirada crítica y ordenada sobre el producto. Esa mirada debe ayudar al equipo, no generar enfrentamientos innecesarios.
El desarrollador tiene un rol central en la calidad porque construye el código que sostiene el sistema. Su responsabilidad no termina cuando una funcionalidad "compila" o se ve correctamente en pantalla.
En relación con testing y calidad, un desarrollador debería:
Un código difícil de probar suele ser también difícil de mantener. Por eso el desarrollo y el testing están más conectados de lo que parece.
Desarrolladores y testers pueden probar la misma funcionalidad, pero suelen hacerlo con enfoques distintos. Ambos enfoques son necesarios.
| Aspecto | Mirada del desarrollador | Mirada del tester |
|---|---|---|
| Foco principal | Confirmar que la implementación técnica funciona. | Evaluar el comportamiento desde requisitos, riesgos y usuario. |
| Conocimiento del código | Alto conocimiento de cómo está construido internamente. | Puede usar una mirada más externa e independiente. |
| Tipo de casos | Validaciones técnicas, pruebas unitarias, integración inicial. | Escenarios funcionales, casos límite, flujos alternativos y regresión. |
| Riesgo habitual | Puede confirmar demasiado el camino que programó. | Puede no conocer detalles técnicos internos si no hay comunicación. |
La combinación de ambas miradas produce mejores resultados que cualquiera de las dos por separado.
En algunas organizaciones existe un equipo de calidad o QA. Su estructura puede variar mucho según el tamaño del proyecto, la industria y la forma de trabajo.
Un equipo de calidad puede ocuparse de:
El objetivo no es crear una "policía de calidad", sino ayudar a que el producto sea más confiable y que las decisiones se tomen con información suficiente.
Las siglas QA vienen de Quality Assurance, que suele traducirse como aseguramiento de la calidad. En la práctica, muchas empresas usan QA como sinónimo de tester, aunque técnicamente no son exactamente lo mismo.
El testing se enfoca en evaluar el producto mediante pruebas. QA puede tener una mirada más amplia, incluyendo procesos, estándares, prevención de defectos, métricas y mejora continua.
| Concepto | Enfoque | Ejemplo |
|---|---|---|
| Testing | Evaluar el producto para encontrar defectos y conocer su estado. | Ejecutar casos de prueba sobre una nueva funcionalidad. |
| QA | Mejorar el proceso para prevenir defectos y elevar la calidad general. | Definir una estrategia de revisión de requisitos antes de desarrollar. |
Para un curso introductorio, lo importante es entender que ambos conceptos están relacionados y que en el trabajo diario pueden mezclarse según la organización.
Los analistas funcionales, product owners, usuarios clave o responsables del negocio también influyen directamente en la calidad. Ellos ayudan a definir qué debe hacer el sistema y qué reglas son importantes.
Su aporte es fundamental para responder preguntas como:
Cuando el equipo de testing no tiene acceso a esta información, aumenta el riesgo de diseñar pruebas incompletas o interpretar mal los resultados.
La colaboración entre roles puede ocurrir en distintas etapas:
Cuanto más temprano colaboren los roles, menor será la probabilidad de descubrir problemas graves al final.
Una buena comunicación entre tester y desarrollador evita pérdidas de tiempo. Cuando se reporta un defecto, el desarrollador necesita entender qué ocurrió y cómo reproducirlo. Cuando se corrige, el tester necesita saber qué cambió y qué debería verificar.
Algunas buenas prácticas son:
El objetivo común es resolver el problema. Una incidencia bien escrita y una conversación clara aceleran mucho ese proceso.
La independencia en testing significa que una persona distinta a quien desarrolló puede revisar el producto con una mirada más fresca. Esto suele ayudar a encontrar problemas que el autor no vio.
Sin embargo, independencia no significa aislamiento. Un tester independiente igual necesita conversar con desarrolladores, analistas y usuarios para entender el contexto.
Hay distintos niveles de independencia:
Cada nivel aporta una mirada diferente. La elección depende del riesgo, del tamaño del proyecto y de los recursos disponibles.
Supongamos que el equipo debe implementar el registro de usuarios en una aplicación web.
| Rol | Aporte |
|---|---|
| Analista o negocio | Define qué datos son obligatorios, qué mensajes deben mostrarse y qué reglas aplican. |
| Desarrollador | Implementa formulario, validaciones, guardado de datos y pruebas técnicas iniciales. |
| Tester o QA | Diseña casos con datos válidos, datos inválidos, campos vacíos, correos duplicados y errores de servidor. |
| Diseñador UX | Revisa claridad visual, mensajes, orden de campos y experiencia de uso. |
| Responsable del proyecto | Decide prioridad de defectos y si la funcionalidad está lista para publicarse. |
Este ejemplo muestra que la calidad final depende de muchas contribuciones coordinadas.
Algunos problemas frecuentes en equipos que recién comienzan a organizar su proceso de calidad son:
Estos problemas no se resuelven solo con herramientas. Se resuelven con acuerdos de trabajo, comunicación y responsabilidad compartida.
El rol del tester es fundamental, pero no existe separado del resto del equipo. El tester ayuda a mirar el producto con criterio crítico, a descubrir defectos, a formular mejores preguntas y a comunicar riesgos. El desarrollador construye la solución y también participa activamente en la calidad mediante buen código, pruebas técnicas y corrección responsable de defectos.
Un equipo madura cuando deja de ver el testing como una barrera final y empieza a verlo como una práctica de colaboración. La calidad mejora cuando todos entienden qué deben aportar y trabajan con información clara.
En el próximo tema estudiaremos los principios fundamentales del testing, que resumen ideas esenciales para planificar y ejecutar pruebas de manera realista.