Construcción y pruebas de software
Qué debe dominar el sustentante
La construcción cubre codificación, estándares, refactorización y manejo de versiones. Debe conocer niveles de prueba: unitaria (una unidad aislada), integración (interacción entre componentes), sistema (comportamiento global) y aceptación (valida necesidades del usuario). Diferencie pruebas de caja blanca (estructura interna: cobertura de sentencias, ramas, caminos) de caja negra (particiones de equivalencia, valores límite, tablas de decisión).
Comprenda verificación (“¿construimos bien el producto?”) frente a validación (“¿construimos el producto correcto?”). Sepa qué es una prueba de regresión, una prueba de humo y la diferencia entre error, defecto y falla: el error es humano, el defecto es su manifestación en el código y la falla es el comportamiento incorrecto en ejecución.
Trampas frecuentes
- Creer que cobertura del 100% de sentencias garantiza ausencia de defectos; no cubre todas las combinaciones de condiciones.
- Confundir prueba de integración con prueba de sistema.
- Elegir valores límite sin incluir los extremos exactos y sus vecinos.
- Asumir que las pruebas unitarias reemplazan las de aceptación.
Ejemplo trabajado
Una función acepta edades de 18 a 65 años. Con valores límite, los casos relevantes son 17, 18, 65 y 66. Con particiones de equivalencia, bastaría un valor por rango válido (p. ej. 30) y uno por cada rango inválido (menor de 18, mayor de 65). Si además se exige cubrir cada rama del if, se añade una prueba de caja blanca. Combinar ambas técnicas es la respuesta más completa cuando el reactivo pide “máxima detección con mínimo de casos”.
Regla práctica: para entradas numéricas, piense siempre en “frontera menos uno, frontera, frontera más uno”.