Introducción a las pruebas de calidad de software 4 de mayo de 2013.
Experto: Johann Paul Echavarría Zapata – Ingeniero Informático http://video.futurodigital.org/webinar_testing http://appsmedellin.com/ http://apps.co/
CONTEXTO
•
FASES DE DESARROLLO DE SOFTWARE
•
Cambian según la metodología usada pero todas incluyen pruebas y aseguramiento de la calidad. – Programación estructurada 1969 / POO 90’s – CASCADA 1970 – POR PROTOTIPOS 1970 – RAD 1991 INCREMENTALES – RUP 1998 – XP 1999 – SCRUM 1995 – TDD 1999 – 2003 – http://www.agilemanifesto.org/
ASEGURAMIENTO DE LA CALIDAD COMO ACTIVIDAD TRANSVERSAL A TODAS LAS FASES DE DESARROLLO
ACTIVIDADES TRANSVERSALES: 1. ASEGURAMIENTO DE CALIDAD 2. GESTIÓN DE RIESGOS 3. GESTIÓN DE CAMBIO 4. GESTIÓN DEL PROYECTO
Pruebas del sistema deben tener trazabilidad con actividades trasversales GESTION DEL PROYECTO GENERALIDADES DE DOCUMENTOS DE ANÁLISIS Y DISEÑO: Deben definir el sistema sin ambigüedades. La tendencia en los últimos años con las metodologías ágiles ha sido evitar exceso de documentación que muchas veces nadie lee. El objetivo es que el sistema esté definido de forma precisa en la menor cantidad de texto y diagramas. Debe agregarse descripciones y diagramas adicionales cuando los requisitos sean complejos y requieran mayor claridad. Mientras más corto y preciso mejor. Técnica moderna de documentación en metodologías ágiles: Historias de usuario
Ítems mínimos recomendados en documentación del sistema LOS REQUISITOS Y CASOS DE USO SON INSUMO PARA FASE DE PRUEBAS • • • •
• • •
•
Objetivos del negocio: Qué quiere lograr el negocio con el sistema. Objetivos del sistema: Qué debe hacer el sistema. Requisitos de usuario: Qué podrá hacer el usuario con el sistema. Requisitos no funcionales: restricciones de diseño (herramientas que deban usarse), requisitos de desempeño, tiempos de respuesta indispensables para que sistema sea viable. Número de usuarios concurrentes que debe soportar. MUY RELACIONADOS CON GESTIÓN DE RIESGOS Requisitos de información: Datos a almacenar, reportes… Casos de uso: cada una de las formas principales en las cuales se puede usar el sistema. Diagramas de diseño – Cuando sea necesario aclarar y eliminar ambigüedades. – UML – Ejemplos de diagramas: Procesos, flujo, arquitectura, despliegue, clases, modelo entidad relación, actividades, estados, secuencias, mapa conceptual… – Herramientas como MS VISIO, www.cacoo.com Versión del documento: Muy importante, el software cambia, el documento cambia.
Pruebas del sistema deben tener trazabilidad con actividades trasversales GESTION DE CAMBIO: Es recomendable utilizar algún sistema de control de versiones para el código: Recomiendo: SVN y GIT También puede usarse servicios de almacenamiento en la nube que manejen versionamiento: https://drive.google.com https://www.dropbox.com/home https://skydrive.live.com/
MODELO EN V aseguramiento de la calidad
Niveles de las pruebas
•
• •
Pruebas unitarias (caja blanca): pruebas en el código. Las suele hacer el desarrollador. Prueba componente por componente. Pruebas de Integración (gris): Se prueba todos los componentes del sistema trabajando en conjunto. Pruebas funcionales (caja negra): Se prueba el sistema sin revisar el código: Testers.
Tipos de pruebas funcionales • • •
•
•
Pruebas de navegación: verificar transiciones entre una pantalla y otra. Pruebas de usabilidad: comodidad, número de clic, practicidad, agilidad, eficiencia. Pruebas de seguridad: (si es requerido ): – Roles, grupos y permisos de usuario. Acceso a datos sensibles. Pruebas de desempeño: (generalmente requisitos no funcionales) velocidad, tiempos de respuesta, concurrencia, pruebas de estrés. Pruebas con diferentes configuraciones.
Diseño de casos de pruebas •
Los planes de pruebas deben tener alcance y objetivos.
•
Usando como insumo los requisitos documentados se debe diseñar pruebas por cada caso de uso, requisito funcional y requisito no funcional.
•
Cada prueba contendrá como mínimo a siguiente información (Jorge Abad): – Objetivo de la prueba. – Descripción de la prueba. – Técnica. – Criterio de Completitud. – Consideraciones Especiales.
EJEMPLO DE PLANTILLA DE CASOS DE PRUEBAS
DATOS DE PRUEBA PARECIDOS A LOS REALES
HERRAMIENTAS COLABORATIVAS PARA SEGUIMIENTO DE BUGS PARA INSTALACIÓN EN HOSTING PROPIO • • •
http://www.bugzilla.org/ PERL (http://demo.bugzilla.org/create.cgi) http://www.mantisbt.org/ PHP y MYSQL http://www.thebuggenie.com/
HERRAMIENTAS COLABORATIVAS ONLINE • •
https://github.com/ Para open source. https://bitbucket.org hasta cinco usuarios o cinco repositorios.
HERRAMIENTAS SIMPLES DE PROPÓSITO GENERAL EN LA NUBE • https://drive.google.com • https://www.dropbox.com/home • https://skydrive.live.com/
Testing en móviles Aspectos a incluir en plan de pruebas • •
• • • • • • • • • • •
Hay muchas diferencias con respecto al testing de las aplicaciones WEB. El testing para aplicaciones móviles es más complejo. Hay muchos más eventos que probar que simples clic. Ejemplos de nuevos eventos en javascript para pantallas “touch”: – Onclick - Touchend – Touchmove - Touchstart Evitar onMouseOver, onMouseOut ¿Cómo reacciona la aplicación si se acaba la batería? ¿Qué pasa si hay llamadas entrantes mientras se usa la app? Soporte multidispositivos (además de los multinavegadores de la aplicaciones WEB) Deben enfocarse en usabilidad. Diseño adaptable para diferentes resoluciones. ¿Que pasa cuando se cambia la orientación en el dispositivo? Asegurarse de que todas las interaciones del usuario con el sistema tengan alguna retroalimentación o feedback para el usuario. ¿Como se comporta la aplicación con un plan de datos 3G o 2G? ¿Y con WIFI? Consumo de CPU. Liberación de recursos. ¿Qué pasa cuando se cae un servicio o el internet?
REFERENCIAS • •
http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-de-software.html http://slashmobility.com/blog/2011/09/410/
ยกGRACIAS!