testing_Tipos_de_testing_de_software.pptx

Tipos de testing de software

1. Tipos de testing

2. Í ndice 1- CONCEPTOS BASICOS 2- PROCESO DEL TESTING 3- TIPOS DE TESTING

3. ¿ Qué hace el testing ? El testing apunta a la búsqueda y pr ev ención de defectos, proporcionando información sobre la calidad de un sistema o aplicación para poder tener un grado determinado de confianza sobre el mismo. 1-CONCEPTOS BASICOS

4. ¿QUÉ HACE EL TESTING? • Investiga técnica y empíricamente un producto, con la intención de mejorar su calidad. • Diseña casos de prueba en base a un objetivo que luego sean ejecutadas sobre un sistema. • Ejecuta pruebas a un software, intentando que un encontrar sus posibles errores. • Recopila información mediante observaciones y compararlas con las expectativas.

5. ¿ QUÉ ES LA C ALI D AD? Según la definición del ISO 9000 la calidad es el g r ado en el que un conjunto de ca r acterísticas inherentes de un objeto cumple con los requisitos. P a r a la Real Academia de la L engu a Española (RAE) la calidad es una propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valo r .

6. REQUISITOS DE CALIDAD Esto requiere que un intermediario se concentre en el producto como un todo. Aquí es donde aparece el analista de control de calidad. Esos requisitos de desarrollo se dividen en tres categorías: Funcionales : función que el software debe realizar. N o funcionales : no es lo que ha r á, sino cómo lo ha r á. De desempeño : la calidad de una función, qué tan bien se desempeña.

7. PRINCIPI O S DEL TESTING

8. 2- PROCESO DEL TESTING

9. TIPOS DE PRUEBAS Son las técnicas para ejecutar las pruebas en cada nivel de pruebas y tienen como finalidad llevarse a cabo mediante la agrupación de diferentes métodos para cubrir un objetivo en particular. Pruebas Funcionales. Responden al “qué” debe hacer y hace el sistema. Están destinadas a probar la funcionalidad del sistema, centrándose en las prestaciones que se desprenden de la especificación de requisitos. Deberían realizarse en todos los niveles de pruebas. Ejemplos: pruebas exploratorias, pruebas de APIs (manual o automation ), pruebas de user interface ( frontend ), pruebas E2E, pruebas de base de datos, pruebas unitarias, pruebas de componente, pruebas de regresión, pruebas de humo( sanity testing ). 2) Pruebas No Funcionales. Se refieren al “cómo”. Miden los atributos del sistema de acuerdo con lo establecido en la norma ISO/IEC 9126: fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Ejemplos: pruebas de carga, pruebas de rendimiento, pruebas de estabilidad, pruebas de volumen, pruebas de robustez, pruebas de usabilidad, pruebas de estrés, pruebas de seguridad

10. 3) Pruebas Estructurales: sirven para probar la estructura interna del programa utilizando técnicas de caja blanca. Se pueden realizar en cualquier nivel de prueba. Puede ser llevada a cabo por el are de desarrollo. 4) Pruebas Asociadas a cambios: se emplean al momento de probar que el software o alguna funcionalidad no haya tenido un cambio producto de la corrección de errores o de actualizaciones. En caso de haber cambios, que sean los esperados en los resultados de las pruebas. Ejemplos: re- testing , pruebas de regresión.

11. NIVELES DE PRUEBAS Se definen por la etapa del desarrollo del software. Tenemos cuatro niveles, a saber: 1) Pruebas de Componentes. Son la fase inicial de las pruebas dinámicas (aquellas donde se ejecuta el software) y se realizan sobre cada componente del software que sea susceptible de pruebas independientes. Son también conocidas como pruebas unitarias o de modulo. Las realiza el desarrollador. ¿Por Qué? 2) Pruebas de Integración. Su función es afianzar que los datos, comunicación y enlaces compartidos entre los diferentes módulos del sistema funcionan de manera adecuada, es decir: sistema operativo + sistema de archivos + (otros sistemas) + hardware = 100% OK.

12. 3) Pruebas de Sistema . Consisten en la verificación de la integración de todos los módulos del software con la finalidad de que el sistema funcione en un completa integridad. 4) Pruebas de Aceptación. Son llevadas a cabo por los responsables de dichas pruebas y se ejecutan en un entorno lo más cercano posible a producción. Generalmente las ejecuta el cliente, usuario final.

13. RESUMEN 1) Pruebas de humo Una de las pruebas iniciales que permiten identificar si las funcionalidades más importantes se encuentran bien, ayuda a testear el funcionamiento general de los aspectos críticos y básicos del sistema como el inicio de sesión. El resultado permite decidir si el software es suficientemente estable para afrontar un ciclo de pruebas más exhaustivas y costosas, o si es necesario revertir la producción. 2) Pruebas unitarias Realizadas por el equipo de desarrollo, consisten en comprobar el correcto funcionamiento de las unidades de código, validan el funcionamiento de los elementos más pequeños del sistema. Al fomentar el cambio y la refactorización en etapas tempranas del desarrollo, reducen drásticamente los problemas y tiempos dedicados a la integración y permiten probar o depurar el código sin necesidad de disponer del sistema completo.

14. 3) Pruebas de integración Testean cómo funciona el sistema al unir los códigos unitarios, buscando defectos entre sus integraciones. Se implementan luego de chequear que las unidades por separado funcionan correctamente. Ejemplo: mediante un login se accede a una cuenta personal. De forma unitaria se probaría que el login valide usuario y clave, e independientemente la cuenta. En las pruebas de integración se valida que el login se envié a la cuenta personal con toda la información correcta. 4 ) Pruebas de regresión Este tipo de pruebas de regresión son las más utilizadas mient r as a vanza un pr o y ecto, ya que se realizan pa ra validar que las correcciones o modificaciones del código no hayan impactado negativamente las funcionalidades pr e viamente e xistentes del producto.

15. 5 ) Pruebas de aceptación Donde el usuario final se relaciona directamente con el sistema, validando que funcione correctamente en escenarios reales. Uso exploratorio por parte del cliente o usuarios. Para obtener mejores resultados en esta etapa, se recomienda que los analistas de prueba apoyen a los usuarios con los datos de prueba y con los paso a paso de los flujos .

16. ¡GRACIAS!