¿Qué es Testing?
Definición, objetivos, conceptos clave, técnicas, tipos y niveles de prueba, más los 7 principios del testing según ISTQB.
Basado en el Syllabus ISTQB v4.0.1
En el mundo del desarrollo de software, el testing es un conjunto de actividades que buscan verificar y validar que una aplicación cumple con sus requisitos y funciona correctamente, ayudando a prevenir defectos y minimizar riesgos.
Objetivos
- Evaluar requisitos, historias de usuario, diseños y código.
- Provocar fallos y encontrar defectos.
- Asegurar la cobertura necesaria del objeto de prueba.
- Reducir riesgos y costos asociados a fallos en producción.
- Verificar que se cumplan requisitos especificados, contractuales, legales y regulatorios.
- Proporcionar información a los interesados para que tomen decisiones informadas.
- Generar confianza en la calidad del objeto de prueba.
- Validar que el objeto de prueba esté completo y funcione como lo esperan los interesados.
Conceptos clave
Defecto (Bug)
Imperfección en un sistema que puede causar fallos. Ej: un error en el código genera un comportamiento inesperado.
Fallo (Failure)
Evento en el cual un sistema no realiza una función requerida. Ej: con ciertos datos, el sistema deja de funcionar.
Error
Acción humana que produce un resultado incorrecto. Ej: malinterpretar un requisito y escribir una condición equivocada.
Plan de pruebas
Documento que describe el alcance, enfoque, recursos y cronograma de las actividades de prueba previstas.
Cobertura de pruebas
Porcentaje del producto que ha sido probado. NO garantiza calidad: indica QUÉ se probó, no QUÉ TAN BIEN.
Caso de prueba
Conjunto de condiciones diseñadas para verificar el sistema.
Técnicas de prueba
Caja negra
Basadas en la especificación, sin conocer el código. Se enfocan en entradas y salidas. Ej: probar el login con credenciales válidas e inválidas.
Caja blanca
Basadas en la estructura interna, la lógica y el flujo del código. Ej: probar todas las ramas de un condicional (if/else).
Basadas en la experiencia
Dependen del conocimiento y experiencia del tester. Ej: explorar una app sin casos definidos, buscando fallos.
Funcionales
Evalúan si el sistema satisface los requisitos funcionales. Ej: verificar que el total del carrito se actualice al agregar productos.
No funcionales
Evalúan cómo funciona el sistema: rendimiento, seguridad, usabilidad. Ej: medir el tiempo de respuesta con 1.000 usuarios concurrentes.
Tipos de prueba
Pruebas de humo
Conjunto inicial de pruebas para verificar que las funciones críticas del sistema funcionan correctamente.
Pruebas de sanidad
Verificación rápida y focalizada que asegura que una función específica o un defecto corregido trabaja como se espera.
Pruebas de regresión
Confirman que las modificaciones no hayan introducido nuevos defectos en otras áreas del software.
Pruebas exploratorias
El tester diseña, ejecuta y aprende sobre el sistema simultáneamente, adaptando las pruebas según lo descubierto.
Pruebas de rendimiento
Evalúan el tiempo de respuesta y la estabilidad del sistema bajo una carga definida.
Pruebas de estrés
Analizan el comportamiento del sistema más allá de sus límites normales, hasta el punto de falla.
Niveles de prueba (según el SDLC)
Unitarias
Prueban componentes individuales en aislamiento, normalmente por desarrolladores. Ej: verificar que una función calcule el total de un pedido.
Integración
Evalúan las interfaces y la interacción entre módulos o sistemas. Ej: comprobar que el módulo de pagos se conecte con PayPal.
Sistema
Validan el sistema completo e integrado frente a los requisitos. Ej: probar un e-commerce: búsqueda, carrito, pago y confirmación.
Aceptación
Confirman que el sistema cumpla los criterios del negocio y las necesidades del usuario.
Los 7 principios del testing
- Las pruebas muestran la presencia de defectos, no la ausencia.
- Las pruebas exhaustivas son imposibles: se usan técnicas, priorización y pruebas basadas en riesgos.
- Detectar a tiempo es más barato: encontrar defectos temprano reduce costos y tiempo.
- Los defectos tienden a agruparse: unos pocos módulos suelen contener la mayoría.
- Las pruebas se desgastan: repetir siempre los mismos tests los hace menos efectivos.
- Las pruebas dependen del contexto: deben adaptarse al proyecto y sus objetivos.
- Falacia de ausencia de defectos: un software sin defectos no es exitoso si no satisface al usuario.
Guarda o comparte este contenido
Descárgalo en PDF o Markdown para guardarlo o compartirlo.