Pruebas de SW-MATD

Pruebas de software

Pruebas de software

01

Pruebas de sw

“Es el proceso que consiste en evaluar todas las actividades del ciclo de vida, tanto estáticas como dinámicas relacionadas con la planificación, preparación y evaluación de productos de software y productos relacionados con el trabajo para determinar que cumplen los requisitos especificados, para demostrar que son aptos para el propósito y para detectar defectos”.

El ISTQB (International Software Testing Qualifications Board)

Pruebas de sw

“Las pruebas de software consisten en una investigación empírica y técnica , realizada para facilitar a los interesados información sobre la calidad del producto o servicio bajo pruebas”.

Cem Kaner,2002

Pruebas de sw

“Es el proceso de ejecución de un programa con la intención de encontrar errores”.

Myers, 2004

terminología

Necesariamente se deben diferenciar los siguientes términos:

BUG

DEFECTO

FALLO

Error

terminología

Necesariamente se deben diferenciar los siguientes términos:

BUG

DEFECTO

Error

FALLO

Son provocados por acciones humanas. Ejemplo: Errores de código

Son provocados al ejecutar el programa con un defecto, lo que arroja resultados no deseados Ejemplo: Salidas inesperadas

Son provocados por un error de implementación Ejemplo: No tomar en cuenta las RDN

Son inconsistencias del Sw encontradas en la etapa de pruebas

Bug

Errores en el código de un programa informático que provocan resultados no deseados

Cualquier elemento que ocasiona que un programa colapse o genere errores

Se puede pesentar en cualquier etapa del desarrollo de Sw

PRUEBAS DE SW

verificACIÓN

VALIDACIÓN

Demuestra que un producto (Sw) cumple con los requisitos especificados en en los Hitos predefinidos durante el ciclo de vida de desarrollo

Comprueba que el sistema cumple con los requisitos del cliente en la finalización del ciclo de vida de desarrollo.

¿Estamos construyendo el producto correcto?

¿Estamos construyendo el producto correctamente?

Pruebas de sw

Es el proceso de verificar y validar un producto (Sw), con la intención de encontrar defectos. Se valida que el producto cumple con los requerimientos del cliente y que está libre de errores, para ser liberado con la mejor calidad posible.

pruebas de software

• Es un proceso

• Verificación y validación

• Requerimientos Vs Funcionalidades

• Calidad/Libre de defectos

objetivos de las pruebas de software

• Encontrar errores

• Proporcionar información sobre la calidad

• Prevenir defectos

• Asegurar que el producto cumple con los requerimientos del cliente

OBJETIVO DE LAS PRUEBAS DE SW

Aportar calidad al Software que se está desarrollando.

IMPORTANTE

IMPORTANCIA

• Detectar errores para su corrección y aseguramiento de la calidad

Importancia de las pruebas de software

• No probar adecuadamente un software, antes de ponerlo en producción, puede generar pérdidas económicas

• Afecta la reputación del equipo de desarrollo y empresa en general

Desarrollo de sw

Fuente: International Software Benchmarking Standards Group (ISBSG)

CONTEXTO DE LAS pruebas de sw

Configuración del Sw

Fallos

Resultados de la prueba

Depuración

Corrección de errores

Evaluación

Tasa de error

Prueba

Modelo de Fiabilidad

Resultados inesperados

Confiabilidad

Configuración de la Prueba

tipos de Pruebas de software

02

PRUEBAS DE SW

Pruebas Estáticas

Pruebas Dinámicas

PRUEBAS ESTÁTICAS

OBJETIVO

Son aquellas que se realizan a través de la documentación: requerimientos, casos de uso y líneas de código

Prevenir defectos

TÉCNICAS

Inspección Revisión de códigos

PRUEBAS DINÁMICAS

OBJETIVO

Son aquellas que se realizan mientras el código está en ejecución.

Detectar de defectos en el software.

TÉCNICAS

Asegurar que el software se comporte de acuerdo con los requerimientos del negocio

Pruebas funcionales y no funcionales.

PRUEBAS DE SW

Alfa

Beta

PRUEBAS ALFA

Se realizan en un ambiente controlado y simulado antes de que el software sea lanzado al público en general.

OBJETIVO

Evaluar la funcionalidad del software en diferentes escenarios y detectar errores y problemas en su desempeño.

Usuario

Permiten a los desarrolladores detectar errores y problemas en el software antes de que llegue a los usuarios finales.

Participación limitada del usuario

PRUEBAS BETA

Se lleva a cabo en un ambiente más amplio y diverso, con la participación de usuarios reales, antes de que el software sea lanzado al público en general.

OBJETIVO

Evaluar la facilidad de uso, la satisfacción del usuario y la funcionalidad general del software en un ambiente más cercano a la realidad.

Usuario

Aunque las pruebas beta implican la participación de usuarios reales, el número de usuarios que pueden participar suele ser limitado.

Implican la participación de usuarios reales, quienes pueden utilizar el software en un ambiente más cercano a la realidad.

TÉCNICAS DE PRUEBAS DE SW

Caja blanca

Caja Negra

Pruebas de Caja Blanca

• Consiste en verificar la estructura interna de un software
• Se enfoca en el código, no en las especificaciones

Pruebas de Caja Negra

Caja Negra

• Enfoque exhaustivo
• No se revisa estructura Interna
• Los datos de entrada son derivados de los requisitos expresados por el cliente
• No se enfoca a errores de código

Salidas

Entradas

Software

Niveles de Pruebas de software

03

NIVELES DE PRUEBAS DE SW

Funcionales

No Funcionales

PRUEBAS FUNCIONALES

Pruebas que evalúan las características o requerimientos funcionales de una aplicación.

NIveles de pruebAS

PRUEBAS DE ACEPTACIÓN. Probar que el sistema esta listo para su entrega.

ACEPTACIÓN

sistema

PRUEBAS DE SISTEMAS. Son pruebas del sistema como un todo.

INTEGRACIÓN

PRUEBAS DE INTEGRACIÓN. Son pruebas que evalúan GRUPOS de elementos o módulos.

UNIDAD

PRUEBAS DE UNIDAD. Son pruebas que evalúan elementos o módulos aislados.

NIVELES DE PUEBAS

También llamadas de componentes. Consisten en la verificación de unidades del software de forma aislada. Pueden ser de código y/o de funciones. Las hace el equipo de desarrollo

Se ocupan de probar las interfaces o comunicación entre los componentes, las interacciones con distintas partes de un mismo sistema.

Unitarias

Integración

Las pruebas de sistema deben de estudiar los requisitos funcionales y no funcionales del sistema y las características de calidad.

Pruebas UAT (User Aceptation Testing). Se llevan a cabo antes de que el programa se ponga en funcionamiento en real y tienen que satisfacer las expectativas del cliente.

sistema

aceptación

PRUEBAS NO FUNCIONALES

Evalúan:

• Performance (rendimiento)
• Usabilidad
• Seguridad
• Estrés
• Portabilidad

TIPOS DE PRUEBAS

PERFORMANCE. Pruebas que validan las características NO FUNCIONALES del Sw. Por ejemplo: - Tiempos de respuesta -

USABILIDAD. Evalúan el grado en que el sistema puede ser utilizado por usuarios específicos con efectividad, eficiencia y satisfacción en un contexto de uso específico.

SEGURIDAD. identifica las vulnerabilidades, riesgos y amenazas en una red, sistema o sw

TIPOS DE PRUEBAS

HUMO. Son pruebas básicas que sirven para comprobar la funcionalidad básica de la aplicación.Están concebidas para ejecutarse de manera rápida OBJETIVO: Ofrecer la seguridad de que las principales funciones del sistema funcionan, según lo previsto.

PRUEBAS DE STRESS. Pruebas de carga extrema en el sistema, hasta lograr colapsarlo

OBJETIVO:Detectar cual es el primer componente crítico que falla. Verificar si el sistema es capaz de auto recuperarse después de colapsar

PRUEBAS DE SW FORMAS DE EJECUCIÓN

MANUALES

AUTOMATIZADAS

- Valida que el Sw funcione correctamente a través de ejecución de scripts - Son ejecutadas a través de herramientas automatizadas o framework

Validan lo que el Sw debe o no debe de hacer, con base a los requerimientos especificados por el usuario - Las pruebas son realizadas por el equipo de calidad Puede aplicarse a aplicaciones Web, Móviles, APIS, Cliente servidor

PRUEBAS DE REGRESIÓN

PRUEBAS FUNCIONALES

FUENTES

https://www.bbvaopenmind.com/tecnologia/innovacion/5-bugs-informaticos-que-marcaron-la-historia/

https://www.atlassian.com/es/continuous-delivery/software-testing/types-of-software-testing

Toro, A. y Peláez, L. E. Validación de un modelo para el aseguramiento de la calidad del software en MIPYMES que desarrollan software en el Eje Cafetero, Entre Ciencia e Ingeniería, Vol. 12, No. 23, pp. 84-92, enero-junio, 2018. DOI: http://dx.doi.org/10.31908/19098367.3707

https://www.diariodeqa.com/post/buenas-pr%C3%A1cticas-al-escribir-casos-de-prueba