Aprender / Glosario
Glosario de testing de software
Definiciones claras de los términos que los QA y SDET usan cada día, cada una con un ejemplo y enlaces a las lecciones, laboratorios y preguntas de entrevista que la tratan.
77 términos · Fundamentos de testing 26 · Diseño de pruebas 5 · Automatización de UI 18 · Testing de APIs 8 · CI/CD y DevOps 5 · Rendimiento 5 · Seguridad 4 · IA en el testing 6
Fundamentos de testing
- Caso de prueba Test case Conjunto concreto de precondiciones, datos de entrada, pasos y resultados esperados que verifica un comportamiento del sistema y produce un veredicto claro de pasa o falla.
- Cobertura de código Code coverage Porcentaje del código fuente (líneas, sentencias, ramas o funciones) que se ejecuta durante las pruebas. Muestra qué no está probado, no qué está bien probado.
- Criterios de aceptación Acceptance criteria Las condiciones concretas y verificables que una historia de usuario o funcionalidad debe cumplir para que el product owner la acepte como terminada.
- Escenario de prueba Test scenario Enunciado de alto nivel de un objetivo del usuario o funcionalidad que probar, como "verificar el checkout con tarjeta guardada", que luego se divide en casos de prueba.
- Flaky test (prueba inestable) Flaky test Una prueba que pasa y falla con el mismo código sin ningún cambio, normalmente por tiempos, estado compartido, orden de las pruebas o un entorno inestable.
- Matriz de trazabilidad de requisitos Requirements traceability matrix Tabla que relaciona cada requisito con los casos de prueba que lo verifican y sus resultados, para que se vean los huecos de cobertura y el impacto de los cambios.
- Oráculo de prueba Test oracle La fuente de verdad que usa un test para decidir si una salida es correcta, como una especificación, una versión anterior, un modelo de referencia o una regla.
- Pirámide de pruebas Test pyramid Modelo para equilibrar una suite automatizada: muchos tests unitarios rápidos en la base, menos tests de integración encima y pocos tests end-to-end en la cima.
- Plan de pruebas Test plan Documento que define alcance, enfoque, recursos, calendario, entornos, riesgos y criterios de entrada y salida de las pruebas de una release o un proyecto.
- Prioridad de un bug Bug priority Qué tan urgente es corregir un defecto frente al resto del trabajo, según las necesidades del negocio. Suele fijarla el product owner o el triage de bugs.
- Prueba de integración Integration test Una prueba que comprueba si dos o más componentes, como un servicio y su base de datos o dos APIs, funcionan bien juntos a través de sus interfaces reales.
- Prueba end-to-end (E2E) End-to-end test Una prueba que recorre un flujo de usuario completo en el sistema real y totalmente desplegado, desde la UI o la API pública hasta la base de datos y de vuelta.
- Prueba unitaria (unit test) Unit test Test automatizado que comprueba una pequeña pieza de código, como una función o una clase, de forma aislada de bases de datos, redes y otros servicios.
- Pruebas basadas en riesgo Risk-based testing Enfoque que prioriza el esfuerzo de pruebas según el riesgo, probabilidad de fallo por impacto, para probar primero y con más profundidad las áreas más arriesgadas.
- Pruebas de aceptación de usuario (UAT) User acceptance testing Fase final de pruebas en la que usuarios reales o representantes del negocio confirman que el sistema cubre sus necesidades y está listo para aceptarse y publicarse.
- Pruebas de caja blanca White-box testing Pruebas diseñadas a partir del conocimiento del código interno, como sus ramas, condiciones y caminos, para asegurar que la implementación se comporta correctamente.
- Pruebas de caja negra Black-box testing Probar un sistema a través de sus entradas y salidas frente a los requisitos, sin mirar ni depender del código ni del diseño interno.
- Pruebas de mutación Mutation testing Técnica que introduce pequeños errores deliberados (mutantes) en el código y vuelve a ejecutar los tests para medir si la suite realmente detecta fallos.
- Pruebas de regresión Regression testing Volver a ejecutar los tests existentes tras un cambio para confirmar que lo que ya funcionaba sigue funcionando y que la corrección o la funcionalidad no rompió nada más.
- Pruebas exploratorias Exploratory testing Pruebas en las que el tester diseña y ejecuta las pruebas al mismo tiempo, usando lo que revela cada resultado para decidir qué probar a continuación.
- Sanity testing (prueba de cordura) Sanity testing Comprobación acotada y enfocada tras un cambio pequeño o una corrección, para confirmar que el área afectada funciona como se espera antes de seguir con pruebas más amplias.
- Severidad de un bug Bug severity Cuánto impacto tiene un defecto sobre el sistema o sus usuarios, desde una caída total o pérdida de datos hasta un problema estético. Suele fijarla QA.
- Shift-left testing Adelantar las pruebas y las actividades de calidad en el ciclo de entrega, para prevenir los defectos o detectarlos cuando son más baratos de corregir.
- Smoke testing (prueba de humo) Smoke testing Comprobación rápida y superficial de las funciones más críticas de un build nuevo para decidir si es lo bastante estable como para someterlo a pruebas más profundas.
- Test double (doble de prueba) Test double Cualquier objeto que sustituye a una dependencia real en un test, como un dummy, stub, fake, spy o mock, para que el código bajo prueba se ejecute rápido y predecible.
- Verificación y validación Verification and validation La verificación pregunta "¿estamos construyendo el producto correctamente?" según la especificación; la validación, "¿estamos construyendo el producto correcto?".
Diseño de pruebas
- Análisis de valores límite Boundary value analysis Técnica de diseño de pruebas de caja negra que elige entradas justo en los bordes de los rangos válidos y a su alrededor, donde se concentran los errores de uno.
- Partición de equivalencia Equivalence partitioning Técnica de diseño de pruebas que divide las entradas en grupos que el sistema debe tratar igual y prueba un valor representativo de cada grupo.
- Pruebas con tablas de decisión Decision table testing Técnica de diseño de pruebas que enumera combinaciones de condiciones y la acción que cada una debe provocar, para que cada regla de negocio tenga su prueba.
- Pruebas de transición de estados State transition testing Técnica de diseño de pruebas que modela un sistema como estados y los eventos que lo mueven entre ellos, y luego prueba las transiciones válidas y las no válidas.
- Pruebas por pares (pairwise) Pairwise testing Técnica combinatoria que selecciona un conjunto reducido de casos de prueba en el que cada par de valores de parámetros aparece junto al menos una vez.
Automatización de UI
- Aislamiento de tests Test isolation Propiedad por la que cada test prepara su propio estado y puede pasar por sí solo, en cualquier orden y en paralelo, sin depender de otros tests ni afectarlos.
- Auto-waiting (espera automática) Auto-waiting Función de un framework que espera a que un elemento esté listo (visible, estable y habilitado) antes de actuar sobre él, en lugar de usar pausas fijas.
- Desarrollo guiado por comportamiento (BDD) Behavior-Driven Development Práctica colaborativa en la que negocio, desarrollo y testing acuerdan el comportamiento mediante ejemplos concretos, a menudo escritos en Gherkin y automatizados.
- Espera explícita (explicit wait) Explicit wait Una espera que comprueba repetidamente una condición concreta, como que un elemento sea clicable, hasta un timeout. En Selenium se escribe con WebDriverWait.
- Espera implícita (implicit wait) Implicit wait Un ajuste global de Selenium que hace que cada llamada a findElement siga buscando durante un tiempo fijo antes de lanzar NoSuchElementException.
- Gherkin La sintaxis de texto plano Given-When-Then (Dado-Cuando-Entonces) para escribir escenarios BDD en archivos .feature, que herramientas como Cucumber ejecutan como pruebas.
- Locator (localizador) Locator La consulta que usa un test de UI para encontrar un elemento en la página, como un rol y nombre, un test id, un selector CSS o una expresión XPath.
- Navegador headless Headless browser Un motor de navegador real que se ejecuta sin ventana visible, usado para ejecutar pruebas de UI en servidores de CI y otras máquinas sin pantalla.
- Page Object Model (POM) Page Object Model Patrón de diseño que encapsula cada página o componente de la UI en una clase, para que los tests llamen a métodos de intención en lugar de repetir locators.
- Pruebas basadas en datos (data-driven testing) Data-driven testing Ejecutar la misma lógica de prueba con muchos conjuntos de entradas y resultados esperados, guardados en una tabla, archivo o fuente de datos y no copiados en cada test.
- Pruebas de regresión visual Visual regression testing Comparar capturas de la UI con imágenes de referencia aprobadas para detectar cambios visuales no deseados, como saltos de layout, estilos ausentes o solapamientos.
- Selector CSS CSS selector Un patrón del lenguaje CSS que localiza elementos por etiqueta, id, clase, atributo o posición; muy usado como locator rápido y legible en pruebas de UI.
- Selenium Grid Servidor de Selenium que enruta sesiones de WebDriver a nodos de navegador remotos para ejecutar tests en paralelo en muchos navegadores, versiones y máquinas.
- StaleElementReferenceException Error de Selenium que se lanza cuando un test usa un WebElement cuyo nodo del DOM se eliminó o se reemplazó después de encontrarlo, normalmente tras un re-render.
- Test fixture La preparación fija que un test necesita antes de ejecutarse, como una página del navegador, un usuario sembrado o una base de datos, más la limpieza posterior (teardown).
- Test sharding Dividir una suite de tests en porciones, llamadas shards, que se ejecutan a la vez en máquinas distintas, para que una suite larga termine en una fracción del tiempo.
- Web-first assertion (aserción web-first) Web-first assertion Aserción de Playwright que recibe un locator y reintenta hasta que se cumple la condición esperada o vence el timeout, en lugar de comprobar un valor una sola vez.
- XPath Lenguaje de consulta para seleccionar nodos en un documento XML o HTML, que se usa en la automatización de UI para localizar elementos por estructura, atributos o texto.
Testing de APIs
- API REST REST API API HTTP diseñada en torno a recursos identificados por URLs, que se manipulan con métodos estándar como GET, POST, PUT, PATCH y DELETE mediante solicitudes sin estado.
- Código de estado HTTP HTTP status code El número de tres dígitos de cada respuesta HTTP que indica si la petición tuvo éxito, fue redirigida o falló por culpa del cliente o del servidor.
- Idempotencia Idempotency La propiedad de que enviar la misma petición una o muchas veces deje el servidor en el mismo estado. GET, PUT y DELETE son idempotentes; POST no.
- JSON Schema Un vocabulario JSON para describir la estructura esperada de unos datos JSON, incluidos tipos, campos obligatorios y formatos, usado para validar respuestas de API.
- JWT (JSON Web Token) JWT Un JSON Web Token es un token compacto y firmado con la forma header.payload.signature que transporta claims como el id del usuario, la caducidad y la audiencia.
- OAuth 2.0 Marco de autorización que permite a una aplicación obtener un token de acceso limitado para llamar a una API en nombre de un usuario o propio, sin manejar contraseñas.
- Pruebas de contrato (contract testing) Contract testing Verificar que el proveedor de una API y sus consumidores coinciden en las peticiones y respuestas que intercambian, sin desplegar ambos juntos para una prueba end-to-end.
- Rate limiting (limitación de tasa) Rate limiting Limitar cuántas solicitudes puede hacer un cliente a una API en una ventana de tiempo y rechazar el exceso, normalmente con 429 Too Many Requests y una cabecera Retry-After.
CI/CD y DevOps
- Contenedor Docker Docker container Una instancia aislada y en ejecución de una imagen Docker que empaqueta una app o servicio con sus dependencias, para que funcione igual en un portátil y en CI.
- Feature flag Un interruptor en tiempo de ejecución que activa o desactiva un camino del código sin desplegar, para publicar trabajo oculto, liberar gradualmente y revertir rápido.
- Integración continua (CI) Continuous integration La práctica de integrar cambios pequeños en una rama compartida con frecuencia, compilando y probando cada push automáticamente para detectar roturas en minutos.
- Quality gate (puerta de calidad) Quality gate Comprobación automática de aprobado/fallido en un pipeline, como que pasen los tests o que la cobertura supere un umbral, necesaria antes de fusionar o publicar código.
- Testcontainers Librería que arranca dependencias reales, como bases de datos, brokers o navegadores, en contenedores Docker desechables desde tu código de test y luego los elimina.
Rendimiento
- Latencia por percentiles Percentile latency Medida del tiempo de respuesta, como p95 o p99, que indica el tiempo en que terminó esa proporción de solicitudes y revela la cola lenta que ocultan los promedios.
- Prueba de carga Load testing Prueba de rendimiento que somete un sistema al tráfico real esperado para verificar tiempos de respuesta, tasa de errores y throughput frente a objetivos acordados.
- Pruebas de estrés Stress testing Prueba de rendimiento que lleva la carga más allá de lo esperado para encontrar el punto de ruptura, ver cómo falla el sistema y comprobar que se recupera después.
- Pruebas de resistencia (soak testing) Soak testing Prueba de rendimiento que mantiene una carga normal y realista durante muchas horas para revelar problemas que solo se acumulan con el tiempo, como fugas de memoria.
- Throughput (rendimiento) Throughput Cantidad de trabajo que un sistema completa por unidad de tiempo, normalmente solicitudes o transacciones por segundo, medida junto con la latencia y la tasa de errores.
Seguridad
- Cross-site scripting (XSS) Cross-site scripting XSS es una vulnerabilidad en la que una entrada no confiable se renderiza como script ejecutable en el navegador de otro usuario, lo que permite al atacante actuar como él.
- IDOR Insecure Direct Object Reference, un fallo de control de acceso en el que cambiar un ID en una petición permite leer o modificar los datos de otro usuario.
- Inyección SQL SQL injection Vulnerabilidad en la que la entrada del usuario se concatena en una consulta SQL, lo que permite a un atacante cambiar su lógica para leer, alterar o borrar datos.
- OWASP Top 10 Lista de concienciación de OWASP con las diez categorías de riesgo de seguridad más críticas en aplicaciones web, muy usada para delimitar pruebas de seguridad y revisiones.
IA en el testing
- Evaluación de LLM (evals) LLM evaluation Medir sistemáticamente la calidad de una funcionalidad con LLM sobre un conjunto fijo de entradas y criterios, ya que las salidas varían y las assertions exactas no sirven.
- Golden dataset (conjunto de referencia) Golden dataset Un conjunto curado y versionado de entradas con salidas esperadas verificadas, usado como referencia fija en las pruebas de regresión de modelos, prompts o pipelines.
- LLM-as-judge (LLM como juez) LLM-as-judge Usar un modelo de lenguaje con una rúbrica escrita para calificar las salidas de otro modelo, un sustituto escalable pero sesgado de la revisión humana en las evals.
- Model Context Protocol (MCP) Model Context Protocol MCP es un protocolo abierto para conectar asistentes y agentes de IA con herramientas y datos externos, como un navegador, un repositorio o un gestor de pruebas.
- Prompt injection (inyección de prompts) Prompt injection Ataque en el que un texto que recibe un LLM, escrito por el usuario u oculto en contenido que lee, anula las instrucciones del desarrollador y cambia su comportamiento.
- Self-healing locator (localizador autorreparable) Self-healing locator Locator que, cuando deja de coincidir, hace que la herramienta elija un elemento sustituto probable a partir de atributos guardados o de un modelo, y deja continuar el test.