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

• 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.

LOS REQUISITOS Y CASOS DE USO SON INSUMO PARA FASE DE PRUEBAS

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!