4.1. Categorías de Técnicas de Prueba

NB-4.1.1 (K2) Explicar las características, los aspectos comunes y las diferencias entre las técnicas de prueba de caja negra, las técnicas de prueba de caja blanca y las técnicas de prueba basadas en la experiencia.

Las técnicas de prueba de caja negra, caja blanca y basadas en la experiencia tienen características, aspectos comunes y diferencias que se pueden resumir de la siguiente manera:

Técnicas de prueba de caja negra:

• Se basan en un análisis de la base de prueba adecuada, como documentos de requisitos formales, especificaciones, casos de uso, historias de usuarios o procesos de negocio.
• Se concentran en las entradas y salidas del objeto de prueba sin referencia a su estructura interna.
• Las condiciones de prueba, casos de prueba y datos de prueba se deducen de una base de prueba que puede incluir requisitos de software, especificaciones, casos de uso e historias de usuario.
• Los casos de prueba se pueden utilizar para detectar diferencias entre los requisitos y la implementación de los requisitos, así como desviaciones con respecto a los requisitos.

Técnicas de prueba de caja blanca:

• Se basan en un análisis de la arquitectura, el diseño detallado, la estructura interna o el código del objeto de prueba.
• Se concentran en la estructura y el procesamiento dentro del objeto de prueba.
• Las condiciones de la prueba, los casos de prueba y los datos de la prueba se deducen de una base de prueba que puede incluir el código, la arquitectura del software, el diseño detallado o cualquier otra fuente de información relacionada con la estructura del software.
• La cobertura se mide en base a los elementos probados dentro de una estructura seleccionada (por ejemplo, el código o las interfaces).

Técnicas de prueba basadas en la experiencia:

• Aprovechan la experiencia de desarrolladores, probadores y usuarios para diseñar, implementar y ejecutar pruebas.
• Se pueden combinar con técnicas de prueba de caja negra y caja blanca.
• Las condiciones de prueba, casos de prueba y datos de prueba se deducen de una base de prueba que puede incluir el conocimiento y la experiencia de probadores, desarrolladores, usuarios y otros implicados.
• Este conocimiento y experiencia incluye el uso esperado del software, su entorno, los posibles defectos y la distribución de dichos defectos.

En cuanto a los aspectos comunes, todas las técnicas de prueba buscan validar el comportamiento del sistema y detectar posibles defectos. Además, todas las técnicas de prueba pueden ser aplicadas tanto a la prueba funcional como a la no funcional.

En cuanto a las diferencias, las técnicas de prueba de caja negra se centran en la validación de la funcionalidad del sistema desde una perspectiva externa, sin conocer su estructura interna. Las técnicas de prueba de caja blanca se centran en la validación de la funcionalidad del sistema desde una perspectiva interna, conociendo su estructura interna. Las técnicas de prueba basadas en la experiencia se centran en la validación de la funcionalidad del sistema desde la perspectiva de la experiencia de los usuarios y otros implicados, sin necesidad de conocer la estructura interna del sistema.

En resumen, las técnicas de prueba de caja negra, caja blanca y basadas en la experiencia tienen características, aspectos comunes y diferencias que las hacen adecuadas para diferentes contextos y objetivos de prueba. 

4.2. Técnicas de Prueba de Caja Negra

NB-4.2.1 (K3) Aplicar la técnica de partición de equivalencia para obtener casos de prueba a partir de requisitos especificados.

La técnica de partición de equivalencia es una técnica de prueba de caja negra que se utiliza para diseñar casos de prueba a partir de requisitos especificados. Esta técnica se basa en dividir los datos de entrada en particiones o clases de equivalencia, de tal manera que se espera que todos los miembros de una partición dada sean procesados de la misma manera. A continuación, se explica cómo aplicar la técnica de partición de equivalencia para obtener casos de prueba a partir de requisitos especificados:

1. Identificar los requisitos de entrada: Identificar los requisitos de entrada del sistema que se van a probar.

2. Dividir los requisitos en particiones de equivalencia: Dividir los requisitos de entrada en particiones de equivalencia. Cada partición debe contener un conjunto de valores que se espera que produzcan el mismo resultado.

3. Identificar los valores límite: Identificar los valores límite para cada partición. Los valores límite son los valores que se encuentran en los extremos de cada partición y que tienen más probabilidades de producir errores.

4. Diseñar casos de prueba: Diseñar casos de prueba para cada partición de equivalencia, utilizando valores que representen la partición y los valores límite identificados. Se deben diseñar casos de prueba para cubrir todas las particiones de equivalencia y los valores límite.

5. Ejecutar los casos de prueba: Ejecutar los casos de prueba diseñados y verificar si el resultado obtenido es el esperado.

6. Repetir el proceso: Si se encuentran errores, volver a diseñar casos de prueba para cubrir los escenarios que produjeron los errores y repetir el proceso hasta que se hayan cubierto todas las particiones de equivalencia y se hayan detectado y corregido todos los errores.

En resumen, la técnica de partición de equivalencia es una técnica de prueba de caja negra que se utiliza para diseñar casos de prueba a partir de requisitos especificados. Esta técnica se basa en dividir los datos de entrada en particiones o clases de equivalencia y diseñar casos de prueba para cada partición y los valores límite identificados. 

NB-4.2.2 (K3) Aplicar la técnica de análisis de valores frontera para obtener casos de prueba a partir de los requisitos especificados.

La técnica de análisis de valores frontera es una técnica de prueba de caja negra que se utiliza para diseñar casos de prueba a partir de los requisitos especificados. Esta técnica se basa en identificar los valores límite de los datos de entrada y diseñar casos de prueba para probar estos valores límite. A continuación, se explica cómo aplicar la técnica de análisis de valores frontera para obtener casos de prueba a partir de los requisitos especificados:

1. Identificar los requisitos de entrada: Identificar los requisitos de entrada del sistema que se van a probar.

2. Identificar los valores límite: Identificar los valores límite para cada requisito de entrada. Los valores límite son los valores que se encuentran en los extremos de cada rango de valores y que tienen más probabilidades de producir errores.

3. Diseñar casos de prueba: Diseñar casos de prueba para cada valor límite identificado. Se deben diseñar casos de prueba para cubrir todos los valores límite identificados.

4. Ejecutar los casos de prueba: Ejecutar los casos de prueba diseñados y verificar si el resultado obtenido es el esperado.

5. Repetir el proceso: Si se encuentran errores, volver a diseñar casos de prueba para cubrir los escenarios que produjeron los errores y repetir el proceso hasta que se hayan cubierto todos los valores límite y se hayan detectado y corregido todos los errores.

En resumen, la técnica de análisis de valores frontera es una técnica de prueba de caja negra que se utiliza para diseñar casos de prueba a partir de los requisitos especificados. Esta técnica se basa en identificar los valores límite de los datos de entrada y diseñar casos de prueba para probar estos valores límite. 

NB-4.2.3 (K3) Aplicar la técnica de tablas de decisión para obtener casos de prueba a partir de requisitos especificados.

La técnica de tablas de decisión es una técnica de prueba que se utiliza para obtener casos de prueba a partir de requisitos especificados, especialmente en situaciones en las que el comportamiento del software depende de diferentes combinaciones de condiciones. A continuación, se explica cómo aplicar la técnica de tablas de decisión para obtener casos de prueba a partir de requisitos especificados:

1. Identificar las condiciones y acciones: Identificar las condiciones de entrada y las acciones resultantes que deben ser probadas. Las condiciones suelen ser las entradas del sistema, mientras que las acciones son las salidas o comportamientos esperados del sistema.

2. Crear la tabla de decisión: Crear una tabla que muestre todas las combinaciones posibles de las condiciones identificadas, junto con las acciones resultantes. Cada fila de la tabla representa una combinación única de condiciones, y cada columna representa una condición o una acción.

3. Identificar las reglas de decisión: Identificar las reglas de decisión a partir de la tabla, donde cada regla representa una combinación única de condiciones y la acción resultante asociada.

4. Diseñar casos de prueba: Diseñar casos de prueba para cubrir cada regla de decisión identificada en la tabla. Cada caso de prueba debe representar una combinación única de condiciones y la acción resultante asociada.

5. Ejecutar los casos de prueba: Ejecutar los casos de prueba diseñados y verificar si el resultado obtenido es el esperado.

6. Repetir el proceso: Si se encuentran errores, volver a diseñar casos de prueba para cubrir los escenarios que produjeron los errores y repetir el proceso hasta que se hayan cubierto todas las reglas de decisión y se hayan detectado y corregido todos los errores.

En resumen, la técnica de tablas de decisión es una técnica de prueba que se utiliza para obtener casos de prueba a partir de requisitos especificados, especialmente en situaciones en las que el comportamiento del software depende de diferentes combinaciones de condiciones. Esta técnica se basa en identificar las condiciones y acciones, crear una tabla de decisión, identificar las reglas de decisión y diseñar casos de prueba para cubrir cada regla de decisión identificada en la tabla. 

NB-4.2.4 (K3) Aplicar la técnica de prueba de transición de estado para obtener casos de prueba a partir de requisitos especificados.

La técnica de prueba de transición de estado es una técnica de prueba que se utiliza para obtener casos de prueba a partir de requisitos especificados, especialmente en situaciones en las que el comportamiento del software depende de diferentes estados del sistema. A continuación, se explica cómo aplicar la técnica de prueba de transición de estado para obtener casos de prueba a partir de requisitos especificados:

1. Identificar los estados del sistema: Identificar los diferentes estados del sistema que deben ser probados. Los estados pueden ser físicos o lógicos, y pueden ser representados mediante diagramas de estado o tablas de transición de estado.

2. Identificar los eventos y transiciones: Identificar los eventos que causan la transición de un estado a otro, y las condiciones que deben cumplirse para que la transición sea válida. Estos eventos y condiciones pueden ser representados mediante diagramas de estado o tablas de transición de estado.

3. Diseñar casos de prueba: Diseñar casos de prueba para cubrir cada transición de estado identificada. Cada caso de prueba debe representar una secuencia única de eventos y condiciones que causan la transición de un estado a otro.

4. Ejecutar los casos de prueba: Ejecutar los casos de prueba diseñados y verificar si el resultado obtenido es el esperado.

5. Repetir el proceso: Si se encuentran errores, volver a diseñar casos de prueba para cubrir los escenarios que produjeron los errores y repetir el proceso hasta que se hayan cubierto todas las transiciones de estado y se hayan detectado y corregido todos los errores.

En resumen, la técnica de prueba de transición de estado es una técnica de prueba que se utiliza para obtener casos de prueba a partir de requisitos especificados, especialmente en situaciones en las que el comportamiento del software depende de diferentes estados del sistema. Esta técnica se basa en identificar los estados del sistema, los eventos y transiciones, diseñar casos de prueba para cubrir cada transición de estado identificada y ejecutar los casos de prueba diseñados.

NB-4.2.5 (K2) Explicar cómo obtener casos de prueba a partir de un caso de uso.

Los casos de uso son una forma específica de diseñar interacciones con elementos de software, incorporando requisitos para las funciones del software representadas por los casos de uso. A continuación, se explica cómo obtener casos de prueba a partir de un caso de uso:

1. Identificar los flujos básicos y alternativos: Identificar los flujos básicos y alternativos del caso de uso. El flujo básico describe la secuencia de eventos que ocurren cuando el caso de uso se ejecuta correctamente, mientras que los flujos alternativos describen las secuencias de eventos que ocurren cuando se producen errores o excepciones.

2. Identificar las condiciones de entrada y salida: Identificar las condiciones de entrada y salida para cada flujo del caso de uso. Las condiciones de entrada son los datos que se ingresan en el sistema para ejecutar el caso de uso, mientras que las condiciones de salida son los resultados esperados del caso de uso.

3. Diseñar casos de prueba: Diseñar casos de prueba para cubrir cada condición de entrada y salida identificada. Cada caso de prueba debe representar una combinación única de condiciones de entrada y salida.

4. Ejecutar los casos de prueba: Ejecutar los casos de prueba diseñados y verificar si el resultado obtenido es el esperado.

5. Repetir el proceso: Si se encuentran errores, volver a diseñar casos de prueba para cubrir los escenarios que produjeron los errores y repetir el proceso hasta que se hayan cubierto todas las condiciones de entrada y salida y se hayan detectado y corregido todos los errores.

En resumen, para obtener casos de prueba a partir de un caso de uso, se deben identificar los flujos básicos y alternativos, las condiciones de entrada y salida, diseñar casos de prueba para cubrir cada condición de entrada y salida identificada y ejecutar los casos de prueba diseñados. 

4.3. Técnicas de Prueba de Caja Blanca

NB-4.3.1 (K2) Explicar la cobertura de sentencia.

La cobertura de sentencia es una medida de la cantidad de sentencias de código que han sido ejecutadas durante la ejecución de las pruebas. Esta medida se utiliza para evaluar la efectividad de las pruebas en términos de la cantidad de código que se ha cubierto. La cobertura de sentencia se expresa como un porcentaje de las sentencias de código ejecutadas en relación con el total de sentencias de código en el programa.

La cobertura de sentencia se logra cuando todas las sentencias de código ejecutables han sido ejecutadas al menos una vez durante la ejecución de las pruebas. Esto significa que cada línea de código ha sido ejecutada al menos una vez durante la ejecución de las pruebas. La cobertura de sentencia es una medida importante de la calidad de las pruebas, ya que indica la cantidad de código que ha sido probado y, por lo tanto, la cantidad de posibles errores que se han detectado.

Es importante tener en cuenta que la cobertura de sentencia no garantiza que todo el código sea correcto o que se hayan detectado todos los errores. Es posible que haya errores en el código que no se hayan detectado durante la ejecución de las pruebas, incluso si se ha logrado una cobertura del 100% de sentencia. Por lo tanto, la cobertura de sentencia debe ser utilizada en conjunto con otras medidas de cobertura, como la cobertura de decisión y la cobertura de condición, para evaluar la efectividad de las pruebas.

En resumen, la cobertura de sentencia es una medida de la cantidad de sentencias de código que han sido ejecutadas durante la ejecución de las pruebas. Esta medida se utiliza para evaluar la efectividad de las pruebas en términos de la cantidad de código que se ha cubierto. La cobertura de sentencia se expresa como un porcentaje de las sentencias de código ejecutadas en relación con el total de sentencias de código en el programa. 

NB-4.3.2 (K2) Explicar la cobertura de decisión.

La cobertura de decisión es una medida de la cantidad de decisiones que han sido ejecutadas durante la ejecución de las pruebas. Una decisión es una estructura de control de flujo que se utiliza para tomar decisiones en el código, como una instrucción «if» o «switch». La cobertura de decisión se utiliza para evaluar la efectividad de las pruebas en términos de la cantidad de decisiones que se han cubierto. La cobertura de decisión se expresa como un porcentaje de las decisiones ejecutadas en relación con el total de decisiones en el programa.

La cobertura de decisión se logra cuando todas las decisiones del código han sido ejecutadas al menos una vez durante la ejecución de las pruebas. Esto significa que cada posible resultado de cada decisión ha sido ejecutado al menos una vez durante la ejecución de las pruebas. La cobertura de decisión es una medida importante de la calidad de las pruebas, ya que indica la cantidad de decisiones que se han probado y, por lo tanto, la cantidad de posibles errores que se han detectado.

Es importante tener en cuenta que la cobertura de decisión no garantiza que todo el código sea correcto o que se hayan detectado todos los errores. Es posible que haya errores en el código que no se hayan detectado durante la ejecución de las pruebas, incluso si se ha logrado una cobertura del 100% de decisión. Por lo tanto, la cobertura de decisión debe ser utilizada en conjunto con otras medidas de cobertura, como la cobertura de condición y la cobertura de sentencia, para evaluar la efectividad de las pruebas.

En resumen, la cobertura de decisión es una medida de la cantidad de decisiones que han sido ejecutadas durante la ejecución de las pruebas. Esta medida se utiliza para evaluar la efectividad de las pruebas en términos de la cantidad de decisiones que se han cubierto. La cobertura de decisión se expresa como un porcentaje de las decisiones ejecutadas en relación con el total de decisiones en el programa. 

NB-4.3.3 (K2) Explique el valor de la cobertura de sentencia y la cobertura de decisión.

La cobertura de sentencia y la cobertura de decisión son medidas importantes para evaluar la efectividad de las pruebas de software. Ambas medidas proporcionan información valiosa sobre la cantidad de código que ha sido probado y la cantidad de decisiones que han sido evaluadas durante la ejecución de las pruebas.

El valor de la cobertura de sentencia radica en su capacidad para garantizar que todas las sentencias ejecutables del código se han probado al menos una vez. Esto significa que la cobertura de sentencia ayuda a identificar áreas específicas del código que no han sido ejecutadas durante las pruebas, lo que puede revelar posibles errores o comportamientos inesperados. Sin embargo, es importante tener en cuenta que la cobertura de sentencia no garantiza la ausencia de errores en el código, ya que no evalúa todas las posibles combinaciones de condiciones y decisiones.

Por otro lado, la cobertura de decisión proporciona un valor adicional al evaluar la ejecución de todas las decisiones del código, incluyendo la evaluación de todas las posibles ramas de decisión. Esto significa que la cobertura de decisión ayuda a identificar áreas críticas del código donde diferentes caminos de ejecución pueden conducir a resultados distintos. Al lograr una cobertura del 100% de decisión, se garantiza que se han evaluado todas las posibles combinaciones de condiciones y decisiones, lo que puede revelar errores lógicos y comportamientos inesperados en el código.

En resumen, el valor de la cobertura de sentencia radica en su capacidad para identificar áreas específicas del código que no han sido ejecutadas durante las pruebas, mientras que la cobertura de decisión proporciona un valor adicional al evaluar todas las decisiones del código, incluyendo la evaluación de todas las posibles ramas de decisión. Ambas medidas son fundamentales para evaluar la efectividad de las pruebas de software y para identificar posibles áreas de mejora en el proceso de pruebas.

4.4. Técnicas de Prueba Basadas en la Experiencia

NB-4.4.1 (K2) Explicar la predicción de errores.

La predicción de errores es una técnica utilizada en el campo de pruebas de software para identificar posibles errores, defectos y fallos que podrían ocurrir durante la ejecución del software. Esta técnica se basa en la creación de listas de posibles equivocaciones, defectos y fallos, y en el diseño de pruebas que expongan esos fallos y los defectos que los causaron.

La predicción de errores se apoya en la experiencia previa, los datos de defectos y fallos, así como en el conocimiento común sobre las posibles causas de fallos en el software. Al identificar y prever posibles errores, los equipos de pruebas pueden diseñar pruebas específicas para exponer esos fallos potenciales, lo que permite una mayor cobertura y detección temprana de posibles problemas en el software.

Además, la predicción de errores puede ayudar a mejorar la calidad del software al identificar áreas críticas que requieren una mayor atención durante el proceso de pruebas. Al anticipar posibles fallos y defectos, los equipos de pruebas pueden enfocar sus esfuerzos en las áreas más propensas a errores, lo que contribuye a una estrategia de pruebas más efectiva y eficiente.

En resumen, la predicción de errores es una técnica que se basa en la identificación y anticipación de posibles errores, defectos y fallos que podrían ocurrir durante la ejecución del software. Esta técnica permite diseñar pruebas específicas para exponer esos fallos potenciales, mejorar la calidad del software y enfocar los esfuerzos de pruebas en las áreas más críticas. 

NB-4.4.2 (K2) Explicar la prueba exploratoria.

La prueba exploratoria es una técnica de prueba dinámica en la que los probadores diseñan, ejecutan, registran y evalúan pruebas de forma dinámica durante la ejecución de la prueba, sin seguir un plan de pruebas predefinido. En lugar de seguir un conjunto de pasos detallados, los probadores utilizan su experiencia, conocimientos y habilidades para explorar el software y descubrir posibles defectos, comportamientos inesperados y áreas críticas.

Durante la prueba exploratoria, los probadores toman decisiones en tiempo real sobre qué áreas del software probar, qué datos de prueba utilizar y cómo interactuar con el sistema. Esta flexibilidad permite a los probadores adaptarse a medida que descubren nuevas características, problemas o riesgos, lo que les permite centrarse en áreas críticas y realizar pruebas más efectivas.

La prueba exploratoria es especialmente útil en situaciones donde las especificaciones son escasas o inadecuadas, ya que permite a los probadores descubrir y comprender el software a medida que lo prueban. Además, esta técnica es valiosa cuando hay presión significativa en cuanto al tiempo para la prueba, ya que permite a los probadores realizar pruebas efectivas de manera ágil y eficiente.

Es importante destacar que la prueba exploratoria no reemplaza otras técnicas de prueba más formales, sino que complementa el proceso de pruebas al proporcionar una perspectiva única y flexible. Además, la prueba exploratoria puede incorporar el uso de otras técnicas de caja negra, caja blanca y basadas en la experiencia para mejorar la cobertura y la efectividad de las pruebas.

En resumen, la prueba exploratoria es una técnica de prueba dinámica en la que los probadores exploran el software de forma flexible y adaptativa, utilizando su experiencia y conocimientos para descubrir posibles defectos y áreas críticas. Esta técnica es especialmente útil en situaciones donde las especificaciones son escasas o inadecuadas, y cuando se requiere realizar pruebas de manera ágil y eficiente. 

NB-4.4.3 (K2) Explicar la prueba basada en una lista de comprobación.

La prueba basada en una lista de comprobación es una técnica en la que los probadores diseñan, implementan y ejecutan pruebas para cubrir las condiciones de prueba que se encuentran en una lista de comprobación. Esta lista de comprobación consiste en un conjunto de preguntas o condiciones específicas que deben ser evaluadas durante la ejecución de las pruebas.

La principal ventaja de la prueba basada en una lista de comprobación es la cobertura sistemática de los tipos de defectos típicos. Al seguir la lista de comprobación, los probadores pueden asegurarse de que se evalúan de manera exhaustiva las condiciones de prueba específicas, lo que contribuye a una mayor cobertura y detección temprana de posibles problemas en el software.

Es importante tener en cuenta que las listas de comprobación deben ser específicas para el tipo de producto de trabajo que se está probando y deben mantenerse regularmente para cubrir los tipos de cuestiones que no se han tenido en cuenta en revisiones anteriores. Además, los probadores deben tener cuidado de no solo seguir la lista de comprobación de manera mecánica, sino también buscar defectos fuera de la lista para garantizar una evaluación exhaustiva del software.

La prueba basada en una lista de comprobación puede ser especialmente útil en situaciones donde se requiere una evaluación sistemática de condiciones específicas, como en el caso de pruebas funcionales y no funcionales. Además, esta técnica puede proporcionar directrices y un cierto grado de consistencia en ausencia de casos de prueba detallados, lo que la hace valiosa en contextos donde la documentación de pruebas es limitada.

En resumen, la prueba basada en una lista de comprobación es una técnica en la que los probadores diseñan, implementan y ejecutan pruebas para cubrir condiciones específicas que se encuentran en una lista de comprobación. Esta técnica proporciona una cobertura sistemática de los tipos de defectos típicos y puede ser especialmente útil en situaciones donde se requiere una evaluación exhaustiva de condiciones específicas del software.