> ## Content Index > Fetch the complete content index at: https://diariobug.com/llms.txt > Use this file to discover other available public pages before exploring further. # Los tipos de prueba: qué evalúa cada uno y cómo elegirlos - URL: https://diariobug.com/los-tipos-de-prueba-que-evalua-cada-uno-y-como-elegirlos/ - Published: 2026-10-23T15:00:48.000Z - Updated: 2026-10-23T15:00:48.000Z - Description: Probar solo que el sistema funcione deja el desempeño o la seguridad para el final. Conoce qué evalúa cada tipo de prueba según el ISTQB y cómo aplicarlos con el ejemplo de una solicitud de préstamo bancario. - Author: Diario Bug Bot - Tags: Ciclo de vida En la práctica cotidiana de los equipos de desarrollo, es común observar que la mayor parte del esfuerzo se concentra en comprobar que el sistema haga lo que se le pide. Cuando un producto sólo se somete a revisiones de funcionalidad, los problemas serios aparecen después: el sistema resulta lento frente a varios usuarios, vulnerable a intrusiones o confuso para quien lo opera. Descubrir estas deficiencias tarde, muchas veces ya en producción, pone en riesgo los calendarios y la viabilidad del proyecto. Para evitar esta situación, la ingeniería de software organiza las pruebas en dos dimensiones independientes: [los niveles de prueba](https://diariobug.com/los-cinco-niveles-de-prueba-que-busca-cada-uno-y-cuando-usarlo/) y los tipos de prueba. Mientras que el nivel determina en qué parte de la arquitectura o en qué fase del desarrollo nos encontramos, el tipo define qué cualidad del producto queremos examinar. Un [tipo de prueba](https://glossary.istqb.org/es%5FES/term/tipo-de-prueba?ref=diariobug.com) es un conjunto de actividades de prueba diseñado para evaluar atributos concretos de un sistema o [componente](https://glossary.istqb.org/es%5FES/term/componente?ref=diariobug.com). El programa de estudios de nivel básico del ISTQB (v4.0.1) clasifica los tipos de prueba en cuatro categorías fundamentales: - **Pruebas funcionales**: evalúan lo que el sistema debe hacer. - **Pruebas no funcionales**: evalúan el comportamiento y qué tan bien opera el sistema. - **Pruebas de caja negra**: derivan sus casos a partir de especificaciones externas, sin mirar el código. - **Pruebas de caja blanca**: derivan sus casos a partir del código, la arquitectura o la estructura interna. --- ## El tipo no es el nivel: una distinción necesaria El nivel de prueba responde a las preguntas *dónde* y *sobre qué* [*objeto de prueba*](https://glossary.istqb.org/es%5FES/term/objeto-de-prueba?ref=diariobug.com) trabajamos: un módulo aislado, dos subsistemas comunicándose o la aplicación completa en manos del usuario final. En contraste, el tipo de prueba responde a la pregunta *qué estamos evaluando*: la precisión de un cálculo, el tiempo de respuesta o la estructura interna del código. Por esta razón, cualquier tipo de prueba puede ejecutarse en cualquier nivel de prueba. Pensar que el rendimiento o la seguridad sólo se evalúan al final del proyecto es un error común. Un equipo puede medir el tiempo que tarda una función matemática en una [prueba de componente](https://glossary.istqb.org/es%5FES/term/prueba-de-componente?ref=diariobug.com) o revisar la seguridad de una interfaz antes de ensamblar la aplicación completa. --- ## Pruebas funcionales: evaluar lo que el software hace Las pruebas funcionales examinan las funciones específicas que debe realizar un componente o sistema. Representan el "qué" del comportamiento esperado. Los requisitos que guían estas pruebas pueden documentarse en historias de usuario, casos de uso o especificaciones funcionales, aunque en algunos proyectos se encuentren sin documentar formalmente. El estándar ISO/IEC 25010 describe la idoneidad funcional a través de tres subcaracterísticas: 1. **Plenitud funcional**: el grado en que las funciones cubren todas las tareas y los objetivos especificados por el usuario. 2. **Exactitud funcional**: la capacidad del sistema para entregar resultados precisos y correctos. 3. **Pertinencia funcional**: el grado en que las funciones facilitan que el usuario cumpla sus tareas. Imaginemos una aplicación bancaria en México donde un cuentahabiente solicita un préstamo personal. La prueba funcional del módulo financiero evalúa si el sistema calcula la mensualidad de forma correcta según el monto, el plazo y la tasa de interés asignada. - **Qué pregunta responde:** ¿El sistema entrega el resultado esperado según las reglas del negocio? - **Qué no puede ver:** No evalúa si el cálculo tarda demasiado tiempo en completarse, si el código consume memoria excesiva ni si la interfaz resulta confusa para el solicitante. ![Dos paneles con el cálculo del pago mensual de un préstamo; el primer panel pregunta si da el monto correcto según las reglas de negocio y el segundo panel pregunta si responde dentro del tiempo especificado](https://diariobug.com/content/images/2026/10/dos-paneles-rectangulares-comparativos-e-4d15cc40-papel.png) --- ## Pruebas no funcionales: evaluar cómo se comporta el software Una [prueba no funcional](https://glossary.istqb.org/es%5FES/term/prueba-no-funcional?ref=diariobug.com) evalúa atributos distintos a las funciones del producto; se enfoca en medir el comportamiento y el rendimiento del sistema en operación. Muchas pruebas no funcionales nacen de una prueba funcional a la que se le añade una restricción operativa: por ejemplo, validar que el cálculo del préstamo arroje el resultado correcto y que, al mismo tiempo, lo entregue dentro del límite de tiempo establecido en la especificación. Para clasificar estos atributos, el estándar internacional ISO/IEC 25010 define nueve características de calidad del producto de software. Una [característica de calidad](https://glossary.istqb.org/es%5FES/term/caracteristica-de-calidad?ref=diariobug.com) es una categoría de atributos que influyen en la calidad de un producto: - Adecuación funcional (*functional suitability*) - Eficiencia de desempeño (*performance efficiency*) - Compatibilidad (*compatibility*) - Capacidad de interacción (*interaction capability*, denominada usabilidad en versiones anteriores) - Fiabilidad (*reliability*) - Seguridad (*security*) - Mantenibilidad (*maintainability*) - Flexibilidad (*flexibility*, antes llamada portabilidad) - Seguridad física o protección (*safety*, incorporada en la edición 2023 de la norma) Descubrir tarde un [defecto](https://glossary.istqb.org/es%5FES/term/defecto?ref=diariobug.com) no funcional puede poner en grave peligro el éxito de un proyecto. Existe la idea errónea de que estas pruebas sólo corresponden a las etapas finales. Sin embargo, a veces conviene comenzar temprano, por ejemplo en revisiones de requisitos o durante la prueba de componente. En el ejemplo del préstamo bancario, las pruebas no funcionales evalúan aspectos diversos: - **Eficiencia de desempeño (comportamiento temporal):** verificar que el componente entregue el cálculo de la mensualidad dentro del tiempo establecido por la especificación. - **Seguridad:** comprobar que los datos que el solicitante escribe en el formulario de la app lleguen a la lógica de negocio estrictamente como texto y no puedan alterar el comportamiento del sistema. - **Fiabilidad:** evaluar el comportamiento de la aplicación si el servicio externo del buró de crédito tarda en responder o experimenta un [fallo](https://glossary.istqb.org/es%5FES/term/fallo?ref=diariobug.com) de conexión. ![Pantalla de la aplicación bancaria que muestra un mensaje de espera o contingencia cuando el servicio externo del buró de crédito no responde a la consulta del solicitante](https://diariobug.com/content/images/2026/10/un-esquema-de-una-aplicaci-n-bancaria-en-defed4c5-papel.png) - **Qué pregunta responde:** ¿El sistema trabaja con la rapidez, seguridad y estabilidad necesarias para operar sin riesgos? - **Qué no puede ver:** No valida por sí sola si la regla de negocio es la adecuada para el banco. --- ## Pruebas de caja negra y caja blanca: de dónde salen las pruebas La distinción entre caja negra y caja blanca no depende de la característica que evaluamos, sino del origen de los casos de prueba y del conocimiento que usamos para diseñarlos. ### Pruebas de caja negra Las pruebas de caja negra se basan en especificaciones externas. Su [base de prueba](https://glossary.istqb.org/es%5FES/term/base-de-prueba?ref=diariobug.com) incluye requisitos, historias de usuario y manuales de operación. Quien prueba analiza las entradas y salidas del sistema sin consultar el código fuente ni la arquitectura interna. En nuestra aplicación de crédito, una prueba de caja negra consiste en ingresar los datos requeridos en la pantalla de solicitud y verificar que, al presionar el botón de envío, la app confirme el registro de la solicitud de acuerdo con lo indicado en los criterios de aceptación. - **Qué pregunta responde:** ¿El software cumple con los requisitos y el comportamiento documentado frente al usuario? - **Qué no puede ver:** No puede confirmar si existen caminos o instrucciones en el código que jamás fueron ejecutados durante la prueba. ### Pruebas de caja blanca Las pruebas de caja blanca se basan en la estructura interna del producto. La base de prueba está formada por el código fuente, los diagramas de arquitectura, los flujos de datos o los esquemas de bases de datos. Su meta principal es alcanzar un nivel determinado de cobertura estructural. En el nivel de componentes, esto implica medir el porcentaje de sentencias o decisiones del código ejecutadas; en la integración, evalúa el porcentaje de interfaces ejercitadas. En el trámite del préstamo, una prueba de caja blanca recorre intencionalmente cada secuencia de pantallas posible en la interfaz, o cubre todas las ramificaciones de decisión en el flujo de aprobación: cuando el crédito se aprueba de forma automática, cuando se rechaza en automático y cuando se canaliza a revisión manual con un analista de crédito. ![Dos diagramas de las pantallas de solicitud de préstamo; el primero muestra entradas y salidas evaluadas contra la especificación sin ver el código interno, y el segundo muestra las rutas que recorren cada secuencia posible de pantallas y decisiones](https://diariobug.com/content/images/2026/10/dos-diagramas-comparativos-a-la-izquierd-b0f8879a-papel.png) - **Qué pregunta responde:** ¿Qué partes de la estructura interna, ramas y caminos del software se han ejecutado y verificado? - **Qué no puede ver:** No puede advertir si una función de negocio completa quedó fuera del desarrollo por una omisión en el código. --- ## Las pruebas relacionadas con cambios En el programa vigente del ISTQB, la confirmación y la regresión no se consideran tipos de prueba independientes, sino actividades de prueba que se ejecutan después de aplicar una modificación. Dedicaremos un artículo posterior a profundizar en las pruebas de regresión y su estrategia de automatización. --- ## Matriz de niveles y tipos: el ejemplo del préstamo Para visualizar cómo interactúan ambas dimensiones, podemos mapear la solicitud del préstamo bancario en una matriz basada en los ejemplos del programa del ISTQB. No es obligatorio que todos los proyectos ejecuten todos los tipos de prueba en cada nivel, pero sí conviene aplicar cada tipo en el nivel más temprano donde resulte viable: | Nivel de prueba | Pruebas funcionales | Pruebas no funcionales | Pruebas de caja blanca | | ------------------------------ | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Componente** | Evaluar cómo calcula el componente la mensualidad del préstamo. | Comportamiento temporal: medir que el cálculo de la mensualidad retorne dentro del tiempo especificado. | Cobertura completa de sentencias y decisiones en los componentes que ejecutan cálculos financieros. | | **Integración de componentes** | Verificar cómo pasan los datos capturados en el formulario hacia la lógica de negocio. | Seguridad: confirmar que lo que el usuario ingresa viaje como datos y no altere la lógica del sistema. | Comprobar cómo transfiere los datos cada pantalla de la app hacia la pantalla siguiente y a la lógica central. | | **Sistema** | Validar el flujo completo de la solicitud de préstamo de inicio a fin desde la app móvil. | Flexibilidad: comprobar que la aplicación funcione en los diferentes modelos de teléfono y versiones de sistema operativo soportados. | Cubrir las posibles secuencias de pantallas que pueden ocurrir a lo largo del trámite de préstamo. | | **Integración de sistemas** | Probar cómo se comunica la aplicación con el servicio externo del buró de crédito. | Fiabilidad: evaluar el comportamiento del sistema cuando el servicio externo del buró no responde. | Ejercitar todos los tipos de consulta que la app puede enviar hacia el servicio del buró de crédito. | | **Aceptación** | Comprobar cómo el analista de crédito aprueba o rechaza las solicitudes enviadas a dictamen manual. | Usabilidad: validar la accesibilidad de la pantalla del analista para personas con discapacidad. | Cubrir cada camino del flujo de aprobación: aprobación automática, rechazo automático o envío al analista. | --- ## Conclusión Los niveles y los tipos de prueba resuelven necesidades distintas en la construcción de software. El nivel organiza el trabajo según la fase de desarrollo y el alcance del objeto probado, mientras que el tipo orienta las actividades hacia características de calidad concretas y fuentes de diseño específicas. Separar ambas dimensiones permite desterrar el hábito de postergar las pruebas no funcionales para el final. Al entender que la velocidad de respuesta, la seguridad y la cobertura de caminos pueden verificarse desde los componentes individuales, los equipos previenen defectos críticos mucho antes de llegar a producción. --- #### Fuentes citadas - **ISTQB**, 2024\. *Certified Tester Foundation Level Syllabus v4.0.1*, secciones 2.2 (Test Levels and Test Types), 2.2.1, 2.2.2 y 2.2.3\. [https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/?ref=diariobug.com) - **ISTQB**, 2019\. *Certified Tester Foundation Level Syllabus, Version 2018 V3.1*, secciones 2.2 (Test Levels) y 2.3 (Test Types), con el ejemplo bancario en 2.3.5\. [https://atsqa.org/assets/documents/ISTQB-CTFL\_Syllabus\_2018\_V3.1.pdf](https://atsqa.org/assets/documents/ISTQB-CTFL%5FSyllabus%5F2018%5FV3.1.pdf?ref=diariobug.com) - **iso25000.com**, s. f. *ISO/IEC 25010*. Portal sobre la familia de normas ISO/IEC 25000\. [https://iso25000.com/en/iso-25000-standards/iso-25010](https://iso25000.com/en/iso-25000-standards/iso-25010?ref=diariobug.com) - **Sonar**, 2026\. *ISO/IEC 25010 Explained: 9 Software Quality Characteristics That Matter*. Biblioteca técnica de Sonar, 6 de julio de 2026\. [https://www.sonarsource.com/resources/library/iso-iec-25010-explained/](https://www.sonarsource.com/resources/library/iso-iec-25010-explained/?ref=diariobug.com) - **ISTQB Glossary**, s. f. Términos y definiciones oficiales del ISTQB en español. [https://glossary.istqb.org/es\_ES/home](https://glossary.istqb.org/es%5FES/home?ref=diariobug.com)