análisis de valores frontera («boundary value analysis»)

El análisis de valores frontera (AVF) es una extensión de la partición de equivalencia, pero sólo se puede utilizar cuando la partición está ordenada, y consiste en datos numéricos o secuenciales. Los valores mínimo y máximo (o valores inicial y final) de una partición son sus valores frontera (Beizer 1990).
(ref. 4.2.2. Análisis de Valores Frontera)

El análisis de valores frontera se puede aplicar en todos los niveles de prueba. Esta técnica se utiliza generalmente para probar los requisitos que requieren un rango de números (incluyendo fechas y horas). La cobertura de frontera para una partición se mide como el número de valores frontera probados, dividido por el número total de valores frontera de prueba identificados, normalmente expresado como un porcentaje.
(ref. 4.2.2. Análisis de Valores Frontera)

Se pueden utilizar técnicas de caja negra (véase la sección 4.2) para obtener condiciones de prueba y casos de prueba para pruebas no funcionales. Por ejemplo, se puede utilizar el análisis de valores frontera para definir las condiciones de estrés para las pruebas de rendimiento.
(ref. 2.3.2. Prueba No Funcional)

cobertura («coverage»)

La cobertura se mide en función de los elementos probados en la base de prueba y de la técnica aplicada a la base de prueba.
(ref. 4.1.2. Categorías de Técnicas de Prueba y sus Características) Nota: como una de las características comunes de las técnicas de prueba de la caja negra.

La cobertura se mide en base a los elementos probados dentro de una estructura seleccionada (por ejemplo, el código o las interfaces).
(ref. 4.1.2. Categorías de Técnicas de Prueba y sus Características) Nota: como una de las características comunes de las técnicas de prueba de la caja blanca.

Para lograr una cobertura del 100% con esta técnica, los casos de prueba deben cubrir todas las particiones identificadas (incluidas las particiones no válidas) utilizando, como mínimo, un valor de cada partición. La cobertura se mide como el número de particiones de equivalencia probadas por al menos un valor, dividido por el número total de particiones de equivalencia identificadas, normalmente expresado como un porcentaje. La partición de equivalencia es aplicable a todos los niveles de prueba.
(ref. 4.2.1. Partición de Equivalencia)

La cobertura de frontera para una partición se mide como el número de valores frontera probados, dividido por el número total de valores frontera de prueba identificados, normalmente expresado como un porcentaje.
(ref. 4.2.2. Análisis de Valores Frontera)

La cobertura se mide, habitualmente, como el número de estados o transiciones identificados probados, dividido por el número total de estados o transiciones identificados en el objeto de prueba, normalmente expresado como un porcentaje. Para más información sobre los criterios de cobertura para la prueba de transición de estado, consultar el Programa de Estudio de Nivel Avanzado de Analista de Pruebas del ISTQB (ISTQB-ATA).
(ref. 4.2.4. Prueba de Transición de Estado)

cobertura de decisión («decision coverage»)

La cobertura se mide como el número de resultados de decisión ejecutados por las pruebas dividido por el número total de resultados de decisión en el objeto de prueba, normalmente expresado como un porcentaje.
(ref. 4.3.2. Prueba y Cobertura de Decisión)

Cuando se alcanza el 100% de cobertura de decisión, se ejecutan todos los resultados de decisión, lo que incluye probar el resultado verdadero y también el resultado falso, incluso cuando no hay una sentencia falsa explícita (por ejemplo, en el caso de una sentencia IF sin un ELSE en el código). La cobertura de sentencia ayuda a encontrar defectos en el código que no fueron comprobados por otras pruebas. La cobertura de decisión ayuda a encontrar defectos en el código donde otras pruebas no han tenido ambos resultados, verdadero y falso.
(ref. 4.3.3. El Valor de la Prueba de Sentencia y Decisión)

cobertura de sentencia («statement coverage»)

La prueba de sentencia comprueba las sentencias ejecutables en el código. La cobertura se mide como el número de sentencias ejecutadas por las pruebas dividido por el número total de sentencias ejecutables en el objeto de prueba, normalmente expresado como un porcentaje.
(ref. 4.3.1. Prueba y Cobertura de Sentencia)

La cobertura de sentencia ayuda a encontrar defectos en el código que no fueron comprobados por otras pruebas. La cobertura de decisión ayuda a encontrar defectos en el código donde otras pruebas no han tenido ambos resultados, verdadero y falso.
(ref. 4.3.3. El Valor de la Prueba de Sentencia y Decisión)

partición de equivalencia («equivalence partitioning»)

La partición de equivalencia divide los datos en particiones (también conocidas como clases de equivalencia) de tal manera que se espera que todos los miembros de una partición dada sean procesados de la misma manera (ver Kaner 2013 y Jorgensen 2014).
(ref. 4.2.1. Partición de Equivalencia)

Los valores válidos son los valores que debe aceptar el componente o el sistema. Una partición de equivalencia que contiene valores válidos se llama «partición de equivalencia válida».
Los valores no válidos son valores que deben ser rechazados por el componente o sistema. Una partición de equivalencia que contiene valores no válidos se llama «partición de equivalencia no válida».
Cada valor debe pertenecer a una y sólo a una partición de equivalencia.
(ref. 4.2.1. Partición de Equivalencia)

El análisis de valores frontera (AVF) es una extensión de la partición de equivalencia, pero sólo se puede utilizar cuando la partición está ordenada, y consiste en datos numéricos o secuenciales. Los valores mínimo y máximo (o valores inicial y final) de una partición son sus valores frontera (Beizer 1990).
(ref. 4.2.2. Análisis de Valores Frontera)

predicción de errores («error guessing»)

La predicción de errores es una técnica utilizada para anticipar la ocurrencia de equivocaciones, defectos y fallos, basada en el conocimiento del probador, incluido:
Cómo ha funcionado la aplicación en el pasado.
Qué tipo de equivocaciones tienden a cometer los desarrolladores.
Fallos que se han producido en otras aplicaciones.
(ref. 4.4.1. Predicción de Errores)

Un enfoque metódico de la técnica de predicción de errores es crear una lista de posibles equivocaciones, defectos y fallos, y diseñar pruebas que expongan esos fallos y los defectos que los causaron.
(ref. 4.4.1. Predicción de Errores)

prueba basada en listas de comprobación («checklist-based testing»)

En la prueba basada en listas de comprobación, los probadores diseñan, implementan y ejecutan pruebas para cubrir las condiciones de prueba que se encuentran en una lista de comprobación.
(ref. 4.4.3. Prueba Basada en Listas de Comprobación)

prueba de caso de uso («use case testing»)

Las pruebas se pueden obtener a partir de casos de uso, que son una forma específica de diseñar interacciones con elementos software, incorporando requisitos para las funciones del software representadas por los casos de uso. Los casos de uso están asociados con actores (usuarios humanos, hardware externo u otros componentes o sistemas) y sujetos (el componente o sistema al que se aplica el caso de uso).
(ref. 4.2.5. Prueba de Caso de Uso)

prueba de tabla de decisión («decision table testing»)

Las técnicas de prueba combinatorias son útiles para probar la implementación de requisitos de sistema que especifican cómo diferentes combinaciones de condiciones generan diferentes resultados. Un enfoque para este tipo de prueba es la prueba de tabla de decisión.
(ref. 4.2.3. Prueba de Tabla de Decisión)

La cobertura estándar mínima habitual para la prueba de tabla de decisión es tener al menos un caso de prueba por regla de decisión en la tabla.
(ref. 4.2.3. Prueba de Tabla de Decisión)

La fortaleza de la prueba de tabla de decisión es que ayuda a identificar todas las combinaciones importantes de condiciones, algunas de las cuales, de otra manera, podrían ser ignoradas.
(ref. 4.2.3. Prueba de Tabla de Decisión)

prueba de transición de estado («state transition testing»)

La prueba de transición de estado se utiliza para aplicaciones basadas en menús y es extensamente utilizada en la industria del software embebido. La técnica también es adecuada para modelar un escenario de negocio con estados específicos o para probar la navegación en pantalla.
(ref. 4.2.4. Prueba de Transición de Estado)

La cobertura se mide, habitualmente, como el número de estados o transiciones identificados probados, dividido por el número total de estados o transiciones identificados en el objeto de prueba, normalmente expresado como un porcentaje.
(ref. 4.2.4. Prueba de Transición de Estado)

prueba exploratoria («exploratory testing»)

En la prueba exploratoria, se diseñan, ejecutan, registran y evalúan de forma dinámica pruebas informales (no predefinidas) durante la ejecución de la prueba. Los resultados de la prueba se utilizan para aprender más sobre el componente o sistema, y para crear pruebas para las áreas que pueden necesitar ser probadas con mayor intensidad.
(ref. 4.4.2. Prueba Exploratoria)

Reactiva: En este tipo de estrategia de prueba, la prueba es reactiva al componente o sistema que se está probando, y a los eventos que ocurren durante la ejecución de la prueba, en lugar de ser planificada con antelación (como lo son las estrategias anteriores). Las pruebas se diseñan e implementan, y pueden ser ejecutadas inmediatamente en respuesta al conocimiento obtenido a partir de los resultados de prueba anteriores. La prueba exploratoria es una técnica común que se utiliza en estrategias reactivas.
(ref. 5.5.2. Estrategia y Enfoque de la Prueba)

técnica de prueba («test technique»)

El objetivo de una técnica de prueba, es ayudar a identificar las condiciones de prueba, los casos de prueba y los datos de prueba.
(ref. 4.1. Categorías de Técnicas de Prueba)