Por Que Importan los Principios
Antes de aprender tecnicas, herramientas o metodologias especificas de testing, cada tester necesita internalizar siete principios fundamentales. Estos principios, definidos por el ISTQB (International Software Testing Qualifications Board), representan decadas de sabiduria colectiva sobre lo que el testing puede y no puede hacer.
No son reglas abstractas. Son guias practicas que previenen errores costosos. Todo tester experimentado ha aprendido estos principios de la manera dificil — violandolos y sufriendo las consecuencias.
Principio 1: El Testing Muestra la Presencia de Defectos, No Su Ausencia
Este es el principio mas fundamental y el mas frecuentemente malinterpretado.
Que significa: El testing puede probar que existen defectos, pero no puede probar que no existen defectos. Incluso despues de ejecutar miles de pruebas con cero fallas, no puedes afirmar que el software esta libre de defectos.
Por que importa: Los stakeholders frecuentemente preguntan “esto esta libre de bugs?” La respuesta honesta siempre es “no, pero no hemos encontrado bugs bajo las condiciones que probamos.” Esta distincion no es pedanteria — establece expectativas correctas sobre lo que el testing entrega.
Ejemplo real: La mision Mars Pathfinder de la NASA (1997) paso todas las pruebas en tierra exitosamente. Sin embargo, en Marte, un bug de inversion de prioridades causaba que el sistema se reiniciara repetidamente. El defecto existia desde siempre pero no fue revelado por las condiciones de prueba en la Tierra.
Implicacion practica: Al reportar resultados, di “no se encontraron defectos” en lugar de “el software esta libre de defectos.”
Principio 2: El Testing Exhaustivo Es Imposible
Que significa: Probar cada posible combinacion de entradas, precondiciones, caminos y estados no es factible para ningun software no trivial. Un simple formulario de login con un campo de email de 50 caracteres y un campo de contrasena de 30 caracteres tiene mas combinaciones posibles que atomos en el universo observable.
Por que importa: Ya que no puedes probar todo, debes probar estrategicamente. Por esto existen las tecnicas de diseno de pruebas — te ayudan a seleccionar las pruebas mas valiosas de un conjunto infinito de posibilidades.
Las matematicas: Considera un formulario con solo 3 campos desplegables, cada uno con 10 opciones. Eso es 10 x 10 x 10 = 1,000 combinaciones. Agrega un campo de texto que acepta 100 caracteres de un conjunto de 96 caracteres, y tienes 96^100 combinaciones adicionales por cada conjunto de desplegables. Probarlas todas es fisicamente imposible.
Implicacion practica: En lugar de intentar probar todo, usa testing basado en riesgos para priorizar. Prueba las funcionalidades mas importantes, los modos de falla mas probables y las areas de mayor riesgo primero.
Principio 3: El Testing Temprano Ahorra Tiempo y Dinero
Que significa: Las actividades de testing deben comenzar lo mas temprano posible en el SDLC. Esto incluye revisar requisitos, analizar disenos y escribir casos de prueba antes de que se escriba el codigo.
Por que importa: Como cubrimos en la Leccion 1.2, el costo de corregir un defecto crece exponencialmente con cada fase del SDLC. Un defecto de requisitos detectado durante revision cuesta 1x. El mismo defecto en produccion cuesta 100x.
Shift-left testing: Este termino moderno describe la practica de mover actividades de testing mas temprano en el proceso de desarrollo. En lugar de testear solo despues de escribir codigo, shift-left significa:
- Revisar requisitos por testabilidad
- Escribir casos de prueba durante el diseno
- Implementar unit tests junto con el codigo (TDD)
- Ejecutar analisis estatico antes del code review
Implicacion practica: Comienza a escribir casos de prueba en el momento que recibes los requisitos. No esperes a tener un build para testear.
Principio 4: Agrupamiento de Defectos
Que significa: Un numero pequeno de modulos usualmente contiene la mayoria de los defectos. Esto sigue el principio de Pareto (regla 80/20): aproximadamente 80% de los defectos se encuentran en 20% de los modulos.
Por que importa: Si sabes donde tienden a concentrarse los defectos, puedes enfocar el esfuerzo de testing alli. Los datos historicos de defectos son una de las entradas mas valiosas para la planificacion de pruebas.
Por que se agrupan los defectos:
- Complejidad: Modulos complejos tienen mas puntos potenciales de falla
- Frecuencia de cambios: El codigo frecuentemente modificado es mas propenso a regresiones
- Experiencia del desarrollador: Modulos escritos por desarrolladores menos experimentados pueden tener mas defectos
- Acoplamiento fuerte: Modulos con muchas dependencias son mas dificiles de implementar correctamente
- Especificaciones pobres: Funcionalidades definidas vagamente llevan a malentendidos
Implicacion practica: Rastrea la densidad de defectos por modulo. Al planificar esfuerzo de testing, asigna mas tiempo a modulos con tasas historicamente altas de defectos.
Principio 5: La Paradoja del Pesticida
Que significa: Si las mismas pruebas se repiten una y otra vez, eventualmente dejaran de encontrar nuevos defectos — asi como los insectos desarrollan resistencia a los pesticidas con el tiempo.
Por que importa: Muchos equipos ejecutan el mismo suite de regresion durante meses o anos sin actualizarlo. Las pruebas pasan, todos se sienten confiados, pero nuevos defectos se cuelan en areas que el suite estatico nunca cubre.
Como contrarrestar la paradoja del pesticida:
- Revisar y actualizar casos de prueba regularmente
- Agregar nuevas pruebas por cada bug encontrado en produccion
- Usar testing exploratorio para descubrir areas no cubiertas por pruebas scripteadas
- Rotar testers entre funcionalidades para traer perspectivas frescas
- Complementar testing de regresion con pruebas aleatorias y basadas en propiedades
Implicacion practica: Un suite de pruebas con 100% de aprobacion no es necesariamente senal de calidad — podria ser senal de tests obsoletos. Si tus pruebas no han encontrado un bug en meses, quizas no estan buscando en los lugares correctos.
Principio 6: El Testing Depende del Contexto
Que significa: El testing se hace diferente en diferentes contextos. El enfoque para testear un dispositivo medico es fundamentalmente diferente de testear una app de redes sociales. El enfoque para un MVP de startup es diferente de un sistema bancario.
Por que importa: No hay una estrategia de testing universal que funcione para todo proyecto. Un tester que aplica el mismo enfoque en todos lados va a sobre-testear en algunas areas y sub-testear en otras.
Factores de contexto:
- Industria: Salud, finanzas y aviacion requieren testing mas estricto que apps de entretenimiento
- Nivel de riesgo: Sistemas criticos para la vida demandan testing mas exhaustivo que herramientas internas
- Metodologia de desarrollo: Testing agil difiere del testing en waterfall
- Requisitos regulatorios: Algunas industrias exigen tipos especificos de testing (FDA para medicos, PCI DSS para pagos)
- Presupuesto y plazos: Startups con sprints de 2 semanas no pueden testear como equipos enterprise con ciclos de 6 meses
Implicacion practica: Siempre pregunta “cual es el contexto?” antes de definir tu estrategia. La cantidad correcta de testing depende de lo que estas probando y las consecuencias de una falla.
Principio 7: Falacia de Ausencia de Errores
Que significa: Encontrar y corregir defectos no ayuda si el sistema construido es inutilizable o no satisface las necesidades y expectativas de los usuarios. Un producto sin defectos que nadie quiere usar sigue siendo un fracaso.
Por que importa: Este principio conecta directamente con la distincion verificacion vs. validacion de la Leccion 1.3. Puedes verificar un producto perfectamente (sin bugs) mientras fallas completamente en validarlo (producto equivocado).
Ejemplo real: Google Wave (2009) fue un producto tecnicamente impresionante y bien testeado que combinaba email, mensajeria instantanea y colaboracion. Tenia pocos bugs. Pero los usuarios lo encontraron confuso e innecesario — ya tenian email y chat. Google Wave fue cerrado despues de un ano a pesar de pasar todas las verificaciones de calidad.
Implicacion practica: Testing no se trata solo de encontrar bugs. Se trata de confirmar que el software entrega valor a sus usuarios. Un tester que solo caza bugs pero nunca cuestiona si la funcionalidad tiene sentido esta haciendo la mitad del trabajo.
Diagrama Resumen
de defectos, no ausencia"] --> Core[Siete Principios
del Testing] P2["2. Testing exhaustivo
es imposible"] --> Core P3["3. Testing temprano
ahorra tiempo y dinero"] --> Core P4["4. Agrupamiento de defectos
regla 80/20"] --> Core P5["5. Paradoja del pesticida
Actualiza tus tests"] --> Core P6["6. Testing depende
del contexto"] --> Core P7["7. Falacia de ausencia
de errores"] --> Core style Core fill:#3b82f6,color:#fff
Ejercicio: Que Principio Aplica?
Para cada escenario, identifica que principio del ISTQB se esta violando o ilustrando:
Un equipo ejecuta exactamente las mismas 200 pruebas de regresion cada sprint durante 18 meses. Recientemente, se encontraron varios bugs en produccion en areas que esas pruebas cubren.
El QA lead reporta al CEO: “Ejecutamos 5,000 casos de prueba y todos pasaron. Se garantiza que el producto esta libre de bugs.”
Una startup fintech aplica el mismo rigor de testing a su landing page de marketing que a su motor de procesamiento de pagos.
Despues de una caida en produccion, el equipo descubre que 7 de los ultimos 10 bugs en produccion provienen del servicio de notificaciones.
El equipo de desarrollo escribe codigo durante 3 meses antes de que QA vea el producto por primera vez.
Un equipo de e-commerce intenta probar cada combinacion posible de productos, cantidades, direcciones de envio y metodos de pago.
Una app de fitness tracking tiene cero bugs conocidos, pero los usuarios se quejan de que rastrea metricas que a nadie le importan.
Pista
Asocia cada escenario con uno de los siete principios. Algunos escenarios ilustran una violacion (hacer lo incorrecto) mientras otros ilustran el principio en accion (observar el fenomeno).Solucion
Paradoja del Pesticida (Principio 5) — Ejecutar las mismas pruebas por 18 meses sin actualizarlas. Las pruebas se volvieron obsoletas y ya no son efectivas para encontrar nuevos defectos.
Testing muestra presencia, no ausencia (Principio 1) — Violado. Nunca puedes garantizar que un producto esta libre de bugs. Lo correcto seria: “Los 5,000 casos pasaron. No se encontraron defectos bajo las condiciones probadas.”
Testing depende del contexto (Principio 6) — Violado. Una landing page de marketing y un motor de pagos tienen niveles de riesgo muy diferentes y requieren enfoques de testing distintos.
Agrupamiento de defectos (Principio 4) — Ilustrado. La mayoria de los defectos se concentran en un numero pequeno de modulos. El servicio de notificaciones deberia recibir mayor enfoque de testing.
Testing temprano ahorra tiempo y dinero (Principio 3) — Violado. Tres meses de desarrollo sin participacion de testing significa que los defectos se han acumulado y seran costosos de corregir.
Testing exhaustivo es imposible (Principio 2) — Violado. Intentar probar cada combinacion no es factible. El equipo deberia usar testing basado en riesgos y tecnicas combinatorias.
Falacia de ausencia de errores (Principio 7) — Ilustrado. Cero bugs no significa nada si el producto no satisface las necesidades del usuario. Las funcionalidades necesitan validarse contra las expectativas reales.
Tips Profesionales
Tip 1: Memoriza estos principios para la certificacion ISTQB. Si planeas certificarte en ISTQB, estos siete principios son material garantizado del examen. Pero mas alla de examenes, guian decisiones diarias de testing.
Tip 2: Usa los principios para responder a solicitudes irrazonables. Cuando un manager dice “prueba todo,” cita el Principio 2. Cuando alguien dice “no necesitamos testear hasta que el codigo este listo,” cita el Principio 3. Los principios te dan autoridad profesional respaldada por consenso de la industria.
Tip 3: La paradoja del pesticida es el principio mas accionable. La mayoria de los equipos la violan sin saberlo. Una practica simple: despues de cada bug en produccion, pregunta “por que nuestras pruebas existentes no detectaron esto?” y agrega una prueba que lo habria detectado. Tu suite de pruebas evoluciona continuamente en lugar de estancarse.
Puntos Clave
- El testing puede mostrar que existen defectos pero nunca probar que no existen (Principio 1)
- No puedes probar todo — usa priorizacion basada en riesgos (Principio 2)
- Comienza a testear temprano para detectar defectos cuando son mas baratos de corregir (Principio 3)
- La mayoria de defectos se agrupan en pocos modulos — enfoca el testing alli (Principio 4)
- Actualiza tus pruebas regularmente o dejaran de encontrar bugs (Principio 5)
- Adapta tu enfoque de testing al contexto (Principio 6)
- Un producto libre de bugs que nadie usa sigue siendo un fracaso (Principio 7)