Palma Rodríguez Uzziel N.

T: 07
Describir los tipos de Pruebas de Software
El ISTQB ha emergido como una organización que ha ayudado a definir estándares en el
cambio de las pruebas de software. El Syllabus del Nivel Foundation del ISTQB, en su
sección 2.3 Test Types establece los tipos de pruebas de software.
Un tipo de prueba es un grupo de actividades de prueba destinadas a probar características
específicas de un sistema de software, o un parte de un sistema, basado en objetivos de
prueba específicos. Tales objetivos pueden incluir:

 Evaluar características de calidad funcional, como integridad, corrección y

oportunidad
 Evaluar características de calidad no funcionales, como la confiabilidad, la eficiencia de
rendimiento,
Seguridad, compatibilidad y usabilidad.
 Evaluar si la estructura o arquitectura del componente o sistema es correcta, completa,
y como se especifica
 Evaluar los efectos de los cambios, como confirmar que se han solucionado los defectos
(confirmación pruebas) y buscando cambios no deseados en el comportamiento que
resultan del software o del entorno cambios (pruebas de regresión)

Pruebas funcionales

-Las pruebas funcionales de un sistema involucran pruebas que evalúan las funciones que
el sistema debe realizar. Los requisitos funcionales se pueden describir en productos de
trabajo, como los requisitos comerciales especificaciones, epopeyas, historias de usuarios,
casos de uso o especificaciones funcionales, o pueden estar sin documentar. Las funciones
son "qué debería hacer el sistema”.
-Las pruebas funcionales deben realizarse en todos los niveles de prueba (por ejemplo, las
pruebas para componentes pueden basarse en una especificación del componente),
aunque el enfoque es diferente en cada nivel.
-Las pruebas funcionales consideran el comportamiento del software, por lo que se pueden
utilizar técnicas de caja negra para derivar condiciones de prueba y casos de prueba para
la funcionalidad del componente o sistema.
-La minuciosidad de las pruebas funcionales se puede medir a través de la cobertura
funcional. La cobertura funcional es la medida en que algún tipo de elemento funcional ha
sido ejercido por pruebas y es expresado como un porcentaje del tipo(s) de elemento
cubierto. Por ejemplo, utilizando la trazabilidad. entre las pruebas y los requisitos
funcionales, el porcentaje de estos requisitos que se abordan mediante la prueba se puede
calcular, identificando potencialmente brechas de cobertura.
-El diseño y la ejecución de pruebas funcionales pueden involucrar habilidades o
conocimientos especiales como el conocimiento del problema empresarial particular que
resuelve el software (por ejemplo, software de modelado geológico para el petróleo y el gas
industrias) o la función particular que cumple el software (por ejemplo, software de juegos
de computadora que proporciona entretenimiento interactivo).
Pruebas no funcionales

-La prueba no funcional de un sistema evalúa las características de los sistemas y el

software, como la facilidad de uso, eficiencia de rendimiento o seguridad.
-La prueba no funcional es la prueba de "qué tan bien se comporta el sistema”.
Contrariamente a las percepciones erróneas comunes, las pruebas no funcionales deben
realizarse en todos los niveles de pruebas. El descubrimiento tardío de defectos no
funcionales puede ser extremadamente peligroso para el éxito de un proyecto.
-Se pueden utilizar técnicas de caja negra para derivar las condiciones de prueba y los
casos de prueba para funciones no funcionales. Por ejemplo, el análisis del valor límite se
puede usar para definir las condiciones de tensión para pruebas de rendimiento.
-La minuciosidad de las pruebas no funcionales se puede medir a través de una cobertura
no funcional. La cobertura no funcional es la medida en que algún tipo de elemento no
funcional ha sido ejercido por pruebas, y se expresa como un porcentaje del tipo(s) de
elemento que se cubre. Por ejemplo, usando trazabilidad entre pruebas y dispositivos
compatibles para una aplicación móvil, el porcentaje de dispositivos los cuales se abordan
mediante pruebas de compatibilidad pueden calcularse, identificando potencialmente
brechas de cobertura.
-El diseño y la ejecución de pruebas no funcionales pueden involucrar habilidades o
conocimientos especiales, como el conocimiento de las debilidades inherentes de un diseño
o tecnología (por ejemplo, vulnerabilidades de seguridad asociadas con lenguajes de
programación) o la base de usuarios en particular (por ejemplo, las personas de los usuarios
de instalaciones sanitarias de sistemas de gestión).

Pruebas de caja blanca

-Las pruebas de caja blanca derivan pruebas basadas en la estructura interna o la

implementación del sistema. La estructura interna puede incluir código, arquitectura, flujos
de trabajo y / o flujos de datos dentro del sistema.
-La minuciosidad de las pruebas de caja blanca se puede medir a través de la cobertura
estructural. La cobertura estructural es la medida en que algún tipo de elemento estructural
ha sido ejercido por pruebas, y se expresa como un porcentaje del tipo de elemento
cubierto.
-En el nivel de prueba de componentes, la cobertura del código se basa en el porcentaje de
código de componente que tiene ha sido probado, y se puede medir en términos de
diferentes aspectos del código (elementos de cobertura) como el porcentaje de sentencias
ejecutables probadas en el componente, o porcentaje de resultados de decisión probado,
estos tipos de cobertura se denominan colectivamente cobertura de código.
-En la integración de componentes a nivel de prueba, la prueba de caja blanca puede
basarse en la arquitectura del sistema, como las interfaces entre los componentes, y la
cobertura estructural puede medirse en términos del porcentaje de interfaces ejercitado por
pruebas.
-El diseño y la ejecución de pruebas de caja blanca pueden involucrar habilidades o
conocimientos especiales, como la forma en que el código es construido (por ejemplo, para
usar herramientas de cobertura de código), cómo se almacenan los datos (por ejemplo,
para evaluar posibles consultas de base de datos), y cómo utilizar las herramientas de
cobertura e interpretar correctamente sus resultados.
Pruebas relacionadas con el cambio

-Cuando se realizan cambios en un sistema, ya sea para corregir un defecto o debido a una
nueva o funcionalidad cambiante, se deben realizar pruebas para confirmar que los cambios
han corregido el defecto o han implementado la funcionalidad correctamente, y no ha
causado consecuencias adversas imprevistas.
-Pruebas de confirmación: una vez que se soluciona un defecto, el software se
puede probar con todos los casos de prueba que fallo debido al defecto, que debe volver a
ejecutarse en la nueva versión del software. El software también se puede probar con
nuevas pruebas si, por ejemplo, si faltaba la funcionalidad del defecto. A menos en la
misma, los pasos para reproducir los fallos causados por el defecto deben volver a
ejecutarse en la nueva versión del software. El propósito de una prueba de confirmación es
confirmar si el defecto original ha sido arreglado exitosamente.
-Pruebas de regresión: es posible que un cambio realizado en una parte del código
ya sea una corrección u otro tipo de cambio, puede afectar accidentalmente el
comportamiento de otras partes del código, pudiendo ser dentro del mismo componente,
en otros componentes del mismo sistema, o incluso en otros sistemas. Los cambios pueden
incluir cambios en el entorno, como una nueva versión de un sistema operativo o sistema
de gestión de bases de datos. Tales efectos secundarios no deseados se denominan
regresiones. Las pruebas de regresión implican la ejecución de pruebas para detectar
dichos efectos secundarios no deseados.
Las pruebas de confirmación y las pruebas de regresión se realizan en todos los niveles de
prueba.
Especialmente en los ciclos de vida de desarrollo iterativo e incremental (por ejemplo,
Agile), nuevas características, cambios en las características existentes y la refactorización
del código dan como resultado cambios frecuentes en el código, lo que también requiere
pruebas relacionadas con el cambio. Debido a la naturaleza evolutiva del sistema, las
pruebas de confirmación y regresión son muy importantes. Esto es particularmente
relevante para los sistemas de Internet de las cosas donde los objetos individuales (p. e.
dispositivos) son frecuentemente actualizados o reemplazados. Los conjuntos de pruebas
de regresión se ejecutan muchas veces y, en general, evolucionan lentamente, por lo que
las pruebas de regresión son fuertes candidatos a la automatización.

Referencias:
ISTBQ(International Software Testing Qualifications Board). Foundation Levels Syllabus
2018. Recuperado el 22 de octubre del 2018 en: https://www.istqb.org/downloads/send/51-
ctfl2018/208-ctfl-2018-syllabus.html