¿Quién debe probar lo que construimos? Independencia y equipo completo

Existe una creencia extendida entre quienes comienzan en la industria del software: el autor del código debe programar y otra persona totalmente aislada debe probar. La realidad técnica es distinta. Quién realiza la prueba cambia de forma directa qué clase de problemas se detectan antes de que el producto llegue al usuario.

El estándar internacional del ISTQB define dos conceptos centrales para abordar esta organización del trabajo:

• Independencia de la prueba: la separación de responsabilidades entre quien diseña o programa la solución y quien la evalúa, lo que favorece una mirada objetiva.
• Enfoque de equipo completo: la práctica de trabajo colaborativo donde cualquier miembro del equipo con los conocimientos necesarios realiza las tareas requeridas, y todos asumen la responsabilidad compartida de la calidad.

Una mirada independiente detecta aspectos que el autor pasa por alto debido a sus propios sesgos cognitivos. Sin embargo, el autor conoce la estructura interna del código mejor que nadie. El desafío metodológico consiste en equilibrar ambas posturas sin romper la colaboración.

Los grados de independencia en la evaluación

La independencia en las pruebas no funciona como una decisión binaria de todo o nada. Representa una escala con diferentes niveles de separación. El programa ISTQB CTFL distingue cuatro grados formales, a los que se suma la participación de los especialistas del negocio:

Grado 1: Pruebas del propio autor (sin independencia)

El desarrollador escribe y revisa su propia funcionalidad, como una pantalla de inicio de sesión o un cálculo de impuestos. Obtiene retroalimentación inmediata sobre la lógica interna del código. Su ventaja principal radica en la familiaridad técnica. Su limitación reside en la falta de distancia crítica: quien construye el camino esperado difícilmente imagina las rutas erróneas.

Grado 2: Compañeros del mismo equipo (alguna independencia)

Un programador revisa y ejecuta las pruebas de un componente construido por un colega del mismo proyecto. Esta dinámica favorece el intercambio de conocimiento dentro del equipo. Sin embargo, ambos comparten la misma visión del producto, las mismas suposiciones sobre los requerimientos y la misma presión por las fechas de entrega.

Grado 3: Equipo de pruebas dentro de la organización (independencia alta)

Personas dedicadas a pruebas que trabajan fuera del equipo de desarrollo, pero dentro de la misma empresa. Este grupo evalúa el sistema en su conjunto y busca activamente las condiciones bajo las cuales el software falla. Su mirada aporta antecedentes y puntos de vista técnicos diferentes a los del autor. Su riesgo principal es el aislamiento operativo y los problemas de comunicación si se les percibe como un obstáculo para las entregas.

Representantes del negocio: Pruebas de aceptación

Especialistas del dominio y usuarios finales evalúan si el sistema satisface sus necesidades de operación diarias. Por ejemplo, en un módulo de facturación, verifican que los impuestos locales se desglosen según la ley comercial vigente, sin importar la arquitectura técnica subyacente.

Grado 4: Especialistas externos a la organización (independencia muy alta)

Firmas de consultoría externa, laboratorios de certificación o equipos de auditoría. Tienen la libertad de reportar fallas críticas a la dirección sin temor a represalias laborales o fricciones internas de equipo. En algunos contextos, como los sistemas de seguridad crítica, puede requerirse un alto grado de independencia.

Por qué cambia la detección de defectos según quién evalúa

Un desarrollador y un especialista de pruebas abordan una misma pantalla con intenciones cognitivas opuestas. El autor busca confirmar que su solución funciona; el evaluador independiente busca descubrir en qué condiciones el sistema se rompe.

Un defecto es una imperfección en el producto producida por una equivocación humana (lo explicamos a fondo en nuestro artículo sobre errores, defectos y fallos). La detección de estos problemas depende de tres mecanismos cognitivos documentados:

1. Sesgo de confirmación: tendencia psicológica a buscar únicamente los datos que respaldan una idea previa. Si un programador crea un formulario de registro, ingresará datos válidos de longitud promedio porque espera que el botón de envío responda correctamente.
2. Ceguera por proximidad: familiarizarse con la estructura interna dificulta anticipar acciones atípicas del usuario. Un evaluador externo prueba con campos vacíos, textos con caracteres especiales o clics dobles repetidos sobre el botón de cobro.
3. Sesgo de congruencia: verificar una hipótesis sólo de forma directa sin poner a prueba las alternativas posibles. Si quien programa interpreta que el descuento comercial aplica sólo a clientes nuevos, sus pruebas verificarán esa condición, pasando por alto qué sucede cuando compra un cliente recurrente.

Por estos factores, los desarrolladores resuelven con alta eficiencia los errores de sintaxis y la lógica interna de los componentes aislados. Por su parte, la mirada independiente destaca en el descubrimiento de casos límite, desbordamientos de datos y comportamientos inesperados en las fronteras del sistema.

El enfoque de equipo completo y el modelo de Quality Assistance

Llevar la independencia al extremo genera fricción organizativa. Cuando el equipo de pruebas trabaja aislado, suelen surgir barreras de comunicación y relaciones de rivalidad con desarrollo. Un efecto adverso frecuente ocurre cuando los programadores descuidan sus revisiones internas bajo el supuesto de que el departamento de pruebas filtrará cualquier error.

El enfoque de equipo completo, una práctica que viene de Extreme Programming, ofrece otra forma de organizarse. Bajo este principio, la calidad no recae en un grupo aislado: es un compromiso colectivo de programadores, analistas y especialistas de pruebas. Tampoco es una receta universal: en algunos contextos, como los de seguridad crítica, puede requerirse un alto grado de independencia.

Dentro de esta colaboración, el papel de quien prueba evoluciona de ser un simple filtro de defectos hacia un modelo de facilitación técnica:

Empresas como Atlassian y Wolt transformaron su estructura hacia la asistencia de calidad (Quality Assistance). En este esquema, el especialista de pruebas no ejecuta cada caso de forma manual; su objetivo es capacitar a los desarrolladores en técnicas de diseño de pruebas, proveer herramientas y señalar los riesgos de cada historia antes de que se conviertan en defectos.

Esta postura preventiva se alinea con la disciplina del aseguramiento de la calidad, la cual busca optimizar los métodos de trabajo para evitar que los problemas aparezcan. Las habilidades necesarias para ejercer este rol de análisis crítico van más allá de dominar un lenguaje de programación (las revisamos a detalle en nuestra guía sobre curiosidad y pensamiento analítico).

Arquitectura de equilibrio en tres niveles

Para la mayoría de los proyectos, el programa CTFL recomienda combinar varios grados de independencia: los desarrolladores hacen las pruebas de componentes y de integración de componentes, un equipo de pruebas hace las pruebas de sistema y de integración de sistemas, y los representantes del negocio hacen las pruebas de aceptación. Una forma práctica de organizarlo es en tres niveles de trabajo complementarios:

• Retroalimentación inmediata: el desarrollador asume la prueba de componente unitaria durante la integración continua. Valida cálculos aritméticos y transformaciones de datos en segundos.
• Colaboración continua: el especialista de pruebas colabora en el diseño de los criterios de aceptación, realiza sesiones de prueba exploratoria junto a los desarrolladores y ayuda a modelar rutas críticas complejas.
• Validación del sistema e independencia especializada: grupos independientes ejecutan pruebas de carga masiva, auditorías de accesibilidad e inspecciones de seguridad antes de los lanzamientos a producción.

La inteligencia artificial y la independencia en la evaluación

El uso de modelos de lenguaje de gran escala (LLM) para generar código plantea interrogantes sobre cómo cambia la independencia técnica. La respuesta honesta es que todavía no lo sabemos: no encontramos ningún estudio que mida cómo cambia la independencia de las pruebas cuando la inteligencia artificial escribe el código, las pruebas o ambos. Lo que hay son indicios aislados y argumentos de práctica.

Sin embargo, existen hallazgos preliminares sobre el comportamiento de quienes programan con estas herramientas. En el congreso ICSE 2026, Zhou y sus colaboradores presentaron un estudio realizado con 14 desarrolladores a lo largo de 2,013 acciones de programación. Los autores reportaron que el 48.8% de todas las acciones observadas estuvo vinculado con al menos un sesgo cognitivo. Cuando las acciones involucraron interactuar con el modelo de lenguaje, la cifra se elevó al 56.4% (456 de 808 acciones), una diferencia estadísticamente significativa según los autores. Los sesgos más notorios consistieron en aceptar el código del modelo sin revisarlo a fondo porque funcionó en la primera ejecución, y asumir que la solución de la máquina era superior al criterio propio. Es una muestra pequeña, y el estudio trata de los sesgos de quien programa con un modelo de lenguaje: no compara pruebas hechas por el autor con pruebas independientes.

Hay además un argumento de práctica, sin medición detrás, que recuerda al sesgo del autor: si la misma herramienta de inteligencia artificial escribe el código de una tienda en línea y genera sus casos de prueba, ambos productos comparten el mismo modelo mental. Si el asistente malinterpreta la regla de cálculo de cupones de descuento, las pruebas automáticas resultantes verificarán ese cálculo erróneo como correcto. Quien lo plantea recomienda diseñar los escenarios de prueba tomando como base directa los requisitos del negocio, evitando derivar las validaciones únicamente del código generado por la máquina.

Conclusión

La independencia en las pruebas no busca separar a las personas en departamentos incomunicados, sino aportar perspectivas analíticas que contrarresten los sesgos naturales de la programación. El autor cuenta con la agilidad y el detalle estructural de su trabajo; el evaluador independiente posee la distancia crítica para cuestionar los supuestos y anticipar el uso adverso.

Construir software confiable requiere articular ambos frentes mediante un enfoque de equipo completo. La calidad deja de ser una estación de inspección tardía cuando los desarrolladores asumen la verificación de sus componentes y los especialistas de pruebas guían la estrategia para desafiar el sistema en su totalidad.

Fuentes

• ISTQB. (2024). Certified Tester Foundation Level Syllabus v4.0.1, secciones 1.2.2, 1.5.2 y 1.5.3. https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
• ISTQB. (s. f.). Glosario ISTQB. https://glossary.istqb.org/es_ES/home
• Try QA. (s. f.). What is independent testing? It's benefits and risks. https://tryqa.com/what-is-independent-testing-its-benefits-and-risks/
• BetterQA. (s. f.). Benefits of test independence - complete 2026 guide. https://betterqa.co/benefits-of-test-independence/
• Mırmırık, T. (2018). Cognitive Bias in Software Testing. TesterYou. https://testeryou.com/cognitive-bias-in-software-testing/
• Mahesh, H. (2025). Independent Testing: The Key to Product Quality Assurance. testRigor. https://testrigor.com/blog/independent-testing/
• Hrynczak, M. (s. f.). Developing quality assistance skills. Atlassian. https://www.atlassian.com/inside-atlassian/software-QA-skills
• Wolt. (2022). From Quality Assurance to Quality Assistance at Wolt. Wolt Careers. https://careers.wolt.com/en/blog/tech/from-quality-assurance-to-quality-assistance-at-wolt
• Zhou, X., Saghi, Z., Sabouri, S., Pandita, R., McGuire, M., & Chattopadhyay, S. (2026). Cognitive Biases in LLM-Assisted Software Development. Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering (ICSE 2026). DOI 10.1145/3744916.3773104. https://arxiv.org/abs/2601.08045
• JIN. (2026). Testing AI-Generated Code: The QA Engineer's New Blind Spot. SHIFT ASIA. https://shiftasia.com/column/testing-ai-generated-code-the-qa-engineers-new-blind-spot/