ISTQB – Cap 2 – Testing a través del ciclo de vida del software – II

En esta nueva entrada vamos a continuar con los Niveles de Pruebas y los tipos de pruebas.

Niveles de Pruebas

Testing de Componentes

También denominadas pruebas de Desarrollador (developer’s test), se prueba cada componente tras su realización/construcción. Dadas las convenciones de cada lenguaje de programación para la asignacion de nombres a sus respectivos componentes, se podrá hacer referencia a una componente como:

• Prueba de modulo: En C
• Prueba de Clase: En java o C++
• Pruebas de unidad: En pascal

Alcance:

• Solo se prueban componentes individuales
• Cada componente es probado de forma independiente
• Los casos de prueba tienen 3 fuentes

Las pruebas de componentes buscan defectos y verifican el funcionamiento del software (por ejemplo, módulos, programas, objetos, clases, etc) que son testeables por separado. Se puede realizar de forma aislada del resto del sistema, en función del contexto del ciclo de vida de desarrollo y el sistema.

El Testing de componentes puede incluir el testing de elementos funcionales y no funcionales, tales como recursos del sistema (por ejemplo, mal uso de memoria), así como las pruebas estructurales. Los casos de prueba son derivados de los trabajos como una especificación de los componentes, el diseño del software o el modelo de datos.

Típicamente, el testing de componentes se produce con acceso al código bajo pruebas y con el apoyo del entorno de desarrollo, tales como un framework de pruebas unitarias o herramientas de depuración, y, en la práctica, por lo general involucra al programador que escribió el código. Los errores se suelen reparar tan pronto como se encuentran, sin constancia oficial de los incidentes.

Un enfoque para el testing de componentes es la de preparar y automatizar casos de prueba antes de codificar. Esto se conoce como enfoque “desarrollo basado en pruebas” (TDD). Este enfoque es muy repetitivo y se basa en los ciclos de desarrollo de casos de prueba, a continuación, construcción e integración de pequeños trozos de código y ejecución de las pruebas de componentes hasta que pasen.

Testing de Integración

Verifica las interfaces entre componentes, las interacciones entre las diferentes partes de un sistema, tales como el sistema operativo, sistema de archivos, hardware, o interfaces con otros sistemas.

Puede haber más de un nivel de pruebas de integración y puede llevarse a cabo sobre objetos de prueba de tamaño variable. Por ejemplo: Pruebas de integración de componentes verifican las interacciones entre las  los componentes del software y se realiza después de las pruebas de componentes.

Cuanto mayor sea el alcance de la integración, más difícil se hace para aislar las fallas de un elemento o sistema específico, que puede conducir a un aumento del riesgo.

Las estrategias sistemáticas de integración pueden estar basadas en la arquitectura del sistema (por ejemplo, de arriba abajo y de abajo hacia arriba), tareas funcionales, las secuencias de procesamiento de transacciones, o algún otro aspecto del sistema o componente. Con el fin de reducir el riesgo de encontrar errores demasiado tarde, la integración normalmente es incremental.

Alcance:

• Se prueban grupos de componentes
• Se puede implementar a nivel subsistemas si se tiene un grupo de los mismos
• Comprueban la interacción entre componentes respecto de la especificación de interfaces.

Testing de Sistema

La calidad del software es observada desde el punto de vista del usuario. El entorno de prueba debe corresponder al entorno de producción tanto como sea posible para reducir al mínimo el riesgo de incidentes debidos al ambiente específicamente y que no se encontraron en las pruebas. Pueden incluir pruebas basadas en los riesgos y/o especificaciones sobre los requerimientos, procesos de negocio, casos de uso, u otras descripciones de alto nivel del comportamiento del sistema, las interacciones con el sistema operativo y los recursos del sistema.

Deben investigar tanto requerimientos funcionales y no funcionales del sistema. Estos requerimientos pueden existir como texto y/o modelos.

Alcance:

• Adecuacion (Suitability): ¿Las funcoines implementadas son adecuadas para su uso esperado?
• Exactitud (Accuracy): ¿Las funciones presentan los resultados correctos (acordados)?
• Interoperabilidad (Interoperability):  ¿Las interacciones con el entorno del sistema presentan algun problema?
• Cumplimiento de Funcionalidad (Compliance): ¿El sistema cumple con normas y reglamentos aplicables?
• Seguridad (Security): ¿Están protegidos los datos/programas contra acceso no deseado o perdida?

Testing de Aceptación

Son a menudo responsabilidad de los clientes y/o usuarios de un sistema; otras partes interesadas pueden participar también. La meta en las pruebas de aceptación es el de establecer confianza en el sistema, las partes del sistema o las características específicas y no funcionales del sistema. Encontrar defectos no es el foco principal en las pruebas de aceptación. Las pruebas de aceptación pueden evaluar la disposición del sistema para el uso, aunque no es necesariamente el nivel final de las pruebas. Por ejemplo, una prueba de integración de sistemas a gran escala puede venir en pos de la prueba de aceptación para un sistema.

La prueba de aceptación se puede presentar como algo más que una prueba de nivel único, por ejemplo: Se pueden realizar pruebas de aceptación sobre un producto de software cuando se instala o se integra. Las pruebas de aceptación de la usabilidad de un componente puede hacerse durante las pruebas de componentes. Las pruebas de aceptación de una nueva mejora funcional puede hacerse antes de la prueba del sistema.

 Alcance:

• Se verificará que el software satisface los requisitos del cliente

Tipos de pruebas según Objetivos

Testing Funcional:

Las pruebas se basan en funciones y características (descripta en los documentos o entendidas por los testers) y su interoperabilidad con sistemas específicos, y puede llevarse a cabo en todos los niveles del Testing (por ejemplo, las pruebas de unidad pueden estar basadas en la especificación de componentes). Se pueden llevar a cabo en todos los niveles de pruebas.

Objetivo: la función del objeto de prueba.

Testing no Funcional

Es la prueba de «cómo» funciona el sistema. Incluyen, pero no se limitan a, las pruebas de rendimiento, pruebas de carga, pruebas de estrés, pruebas de usabilidad, pruebas de mantenimiento, pruebas de fiabilidad y pruebas de portabilidad.

Las pruebas no funcionales se pueden realizar en todos los niveles del Testing. El termino pruebas no funcionales describe las pruebas necesarias para medir las características de los sistemas y software que se puede cuantificar en una escala variable, tales como tiempos de respuesta para las pruebas de rendimiento.

Objetivo: Describir las pruebas necesarias para medir las características de los sistemas que se puede cuantificar en una escala variable

Testing Estructural

 Puede realizarse en todos los niveles del testing. Las técnicas estructuradas son las mejores, usadas después de las técnicas basadas en especificaciones, con el fin de ayudar a medir el rigor de las pruebas mediante la evaluación de la cobertura de un tipo de estructura.

La cobertura es la medida en que una estructura ha sido llevada a cabo por una serie de pruebas, expresado como porcentaje de los puntos que son cubiertos. Si la cobertura es del 100%, luego más pruebas pueden ser diseñadas para probar a los elementos que se han perdido y, por tanto, incrementar la cobertura.

 Objetivo: La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba.