www.mtp.es
Testing para Desarrolladores
La calidad del software (también) es nuestra
responsabilidad
Gira SSTQB 2016Noviembre de 2016
Índice• Motivación
• Responsabilidades
• Herramientas
• Técnicas
• Las pruebas integradas en el desarrollo
• Futuro
• Conclusiones y siguientes pasos
2
Motivación
3
MotivaciónMotivación
• ¿ISTQB está enfocado a desarrolladores?
• ¿Un desarrollador está preparado en testing?
• ¿Sabe probar un desarrollador?
• ¿Qué conciencia tiene un desarrollador de su responsabilidad en la calidad del software?
• ¿Quién tiene la responsabilidad de la calidad?.
• Desarrolladores y testers:
• ¿Cómo se relacionan?
• ¿Qué objetivos comparten?
4
Responsabilidad del desarrolladorDefiniciones
¿Qué se entiende por buen software?
• Cumplir especificaciones
• Fácil de usar, ergonómico,
• Sin errores
• Simple, sencillo
• Robusto
• Mantenible
• Evolucionable
• Arquitectura, reutilizable
• UTIL
5
Responsabilidad del desarrolladorDefiniciones
Desarrollo software, Ingeniería softwareAplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo (creación), operación y mantenimiento de software
Software Craftmanship. Proceso intrínsecamente creativo de creación de software.
Pruebas, Testing (ISTQB)Proceso que consiste en todas las actividades del ciclo de vida software, tanto estáticas como dinámicas, concernientes con la planificación, preparación y evaluación de productos software y los productos de trabajo relacionados para determinar que éstos satisfacen los requisitos especificados, para demostrar que se ajustan al propósito y para detectar defectos.
• ¿Comparten el mismo objetivo?
6
Responsabilidad del desarrolladorResponsabilidades
DesarrolladorCrear software de calidad con el menor número de defectos respetando las restricciones de tiempo y coste
Tester, probadorDiseñar pruebas eficaces y eficientes. Experto en técnicas y estrategias de prueba. Aporta información para la mejora.
No es el guardián de la calidad
Responsables, gestores, direcciónDotar de medios para la realización del software de forma eficaz y eficiente cumpliendo los requisitos de calidad
Pero, asumiendo que crear software perfecto es ¡imposible!
7
HerramientasSubtítulo de la slide
8
HerramientasTipos de herramientas de calidad software (ISTQB)
9
1.- Herramientas de soporte a la gestión y ejecución de las pruebasA) Herramientas de gestión de pruebasB) Herramientas de gestión de requisitosC) Herramientas de gestión de incidenciasD) Herramientas de gestión de configuración
2.- Herramientas de soporte a las pruebas estáticasA) Herramientas de revisiónB) Herramientas para el análisis estático (D)C) Herramientas de modelado (D)
3.- Herramientas de soporte a la especificación de pruebasA) Herramientas para el diseño de las pruebas B) Herramientas de preparación de datos de prueba
4.- Herramientas de soporte a la ejecución y el registro de resultadosA) Herramientas para la ejecución de pruebas (Robots de pruebas, Depuradores (D) y
controladores de prueba).B) Herramientas que proporcionan marcos de pruebas unitarias (frameworks) o armazones
de prueba (D).C) Comparadores de prueba.D) Herramientas de medida de cobertura (D).E) Herramientas de prueba de seguridad.
5.- Herramientas de soporte al rendimiento y monitorizaciónA) Herramientas de análisis dinámico (D).B) Herramientas de pruebas de rendimiento, carga y estrés.C) Herramientas de monitorización
6.- Herramientas de soporte para áreas de aplicación específicas
(D) Herramienta usada principalmente por el desarrollador
HerramientasCompilador
Herramienta por excelencia del desarrollador que nos avisa de nuestra primeras carencias en calidad
• Deficiencias en el uso de las variables, objetos y recursos del lenguaje, que son el origen de los fallos “inexplicables e irreproducibles” en producción a pesar de haber superado todas las pruebas
• Malos hábitos
• Desactivar los “warnings” o no analizarlos
• Relajar las exigencias del compilador, sin analizar las consecuencias
• No profundizar en el conocimiento del compilador
10
HerramientasDebugger o depurador
Compañero de largas y laboriosas sesiones de búsqueda del defecto.
Su volumen de uso es inversamente proporcional a la calidad de nuestro software
11
HerramientasIDE• Entorno de trabajo del desarrollador.
• Esta herramienta aporta un gran número de utilidades que automatizan tareas de desarrollo que previenen la inyección de defectos
• Malos hábitos
• Cada miembro del equipo tiene su “entorno” propio
• No definir al inicio las parametrizaciones del entorno
• No habilitar las herramientas de comprobación (estilo de codificación, métricas, arquitectura, dependencias)
• No habilitar las integraciones con otras herramientas (Gestión de configuración, bugtracker, requisitos, integración)
• No automatizar todas las actividades “rutinarias”
• Desconocimiento del potencial del IDE y de sus plugins
• No usar el potencial de pruebas y comprobación
12
HerramientasAnálisis estático de código• Debería ser el gran aliado del desarrollador, pero pocos
la conocen y utilizan
• Los médicos realizan analíticas, los mecánicos analizan el vehículo con un ordenador, los arquitectos toman muestras. ¿Y los desarrolladores? ¿analizan su código?
• Permite prevenir defectos mientras se codifica sin esperar a las pruebas de terceros
• Malos hábitos
• Desconocimiento del significado de las métricas del software
• Desconocimiento de los estándares de codificación
• No usarla para refactorizar
• No usarla para comprobar la arquitectura• No usarla para prevenir problemas relacionados con
requisitos no funcionales
13
HerramientasRevisiones, 4 ojos ven más que 2
• Revisiones, inspecciones, walkthrough
• Peer review, revisión entre iguales
• Pair Programming, programación en parejas
• Mob programming, programación en grupo
En cualquier caso, ¿alguien revisa tu código?
• Existen herramientas de revisión o apoyo a la revisión:
• Requisitos en lenguaje natural
• Modelos con UML
• Diseños de código o arquitectura software
14
HerramientasModelado y arquitectura
• Una herramienta de modelado, nos permite representar de una manera conceptual y lógica nuestro software:
• Antes de construirlo (medir 2 veces y cortar 1)
• Después de construirlo (gestión conocimiento)
• Una servilleta o una pizarra pueden ser herramientas de modelado, lo importante es visualizarlo. Hace años (muchos) fueron los DFD, hace 20 años UML ¿hoy?
• Algunos IDE y herramientas permiten integrar (con limitaciones) modelos de arquitectura y código.
• La ingeniería inversa desde el código, muestra la arquitectura de nuestro código
• Hay que probar la arquitectura ¿cómo? PoC
15
HerramientasModelado y arquitectura
• Malos hábitos
• No definir una arquitectura
• No visualizar la arquitectura actual
• Mantener la arquitectura a toda costa
• No aplicar patrones (ser inventores de ruedas)
• No codificar visualizando nuestro código integrado en el sistema
16
HerramientasFrameworks de pruebas unitarias. Bancos de pruebas
• Existen frameworks (muchos sin coste de licencia) que permiten simplificar y automatizar las pruebas
• Aunque su foco son las pruebas unitarias (componentes, clases, funciones) pueden usarse para pruebas de integración, de sistema o incluso de interfaz gráfica
• Permiten
• Facilitar la creación y mantenimiento de los casos de prueba automatizados
• Gestionar los resultados de las pruebas
• Usar estrategias de automatización como data driven y keyword driven, que permiten modificar la lógica de la automatización sin modificar el código (mínima regresión)
17
HerramientasAnalizadores de cobertura de código
• Los analizadores de cobertura de código son un gran aliado de las técnicas y frameworks de pruebas unitarias de caja blanca
• Son intrusivos ya que es necesario instrumentalizar el código
• Permiten:
• Visualizar el código fuente ejecutado y no ejecutado
• Número de pasadas por bloque
• Tiempos de ejecución por bloque
• Algunos permiten cobertura de ramas y caminos
18
HerramientasHerramientas de análisis dinámico. Monitores
• Son herramientas que permiten medir el comportamiento del software en ejecución
• Memoria
• Almacenamiento
• Conectividad
• Flujos de datos
• Suelen ser intrusivos (sondas)
• Permiten alertar antes de que el software colapse por degradación.
• Muy usado por el personal de producción o explotación de sistemas.
19
HerramientasHerramientas de diseño y creación de casos de prueba
• Permiten diseñar, e incluso crear y ejecutar los casos de prueba.
• Parten de una especificación formal:
• Requisito (por ejemplo con Gherkin)
• Modelo (testing basado en modelos) por ejemplo para abordar la complejidad de una máquina de estados o la explosión combinatoria de casos de prueba
• Lenguaje propio (TTCN3)
• Actualmente están en desarrollo y evolución, aunque MTP empezó con TTCN3 hace más de 10 años
• Las herramientas hacen viable el testing
20
Técnicas de pruebaEficiencia frente a los defectos
21
Técnicas de pruebaClasificación
• Técnicas estáticas
El software no se ejecuta
• Técnicas dinámicas
El software se está ejecutando en la prueba
• Caja negra
Sólo nos interesa cómo se usa. No vemos las “tripas”
• Caja blanca
Sólo nos interesa como se ejecuta el código
• ¿Caja gris?
• Testing exploratorio o basado en la experiencia
22
Técnicas de pruebaTécnicas estáticas
• Revisiones de productos software (requisitos, diseños)
• ISTQB: Inspecciones, Walkthrough, Revisión técnica
• Peer review, revisión entre iguales
• Pair Programming, programación en parejas
• Mob programming, programación en grupo
• Análisis estático de código (herramienta)
• Análisis de flujo de control
• Análisis de flujo de datos
• Métricas
Valor añadido: al revisar se mejora la comprensión del
producto a construir
23
Técnicas de pruebaCaja negra.
• Mecanismo sencillo para que el desarrollador sea consciente de :
• la explosión combinatoria generada por su solución técnica
• las pruebas son más caras cuanto peor es el desarrollo
• probar no es fácil• muchas de las mejores prácticas de programación
tienen su origen en el objetivo que el software sea “testable”
24
Técnicas de pruebaCaja blanca.
• Mecanismo sencillo para que el desarrollador sea consciente de :
• que probarlo todo es imposible• que la solución técnica elegida no es adecuada• que quizás exista una implementación más simple• que quizás haya que refactorizar el código
25
MétricasComplejidad ciclomática
• Una métrica que nos ofrece un orden de magnitud de cuantas ejecuciones posible tiene el código. Depende del número de bifurcaciones del código y su estructura
• Número de bifurcaciones + 1
• Casos de prueba posibles 2n
• En algunos casos, exponencial
26
pneGv +−=)(
1
1
2
43
5 6 8
11
12
13
109
7
1
2 3
45 6
7
121311
1516
8 9
1410
1718
19
1
1
2
43
5 6 8
11
12
13
109
7
1
2 3
45 6
7
121311
1516
8 9
1410
1718
19
14
Todos los escenarios de ejecución deberían ser probados!
Estrategia y gestión de pruebas¿Queda más?
• La gestión de las pruebas y los equipos de testers (labor del test manager). Pero esto da para varias sesiones. Ver niveles Expert de ISTQB
• Las estrategias de prueba
• Probar el software puede costar mas que lo cuesta construirlo la primera vez.
• No probarlo adecuadamente probablemente haga inviable el software
• Resultado:
DESARROLLO CONDICIONADO POR EL TESTING
27
Las pruebas integradas en el desarrolloIntegración de las pruebas en el ciclo de desarrollo
• Las pruebas se integran (deben integrarse) con el ciclo de vida del desarrollo software, sea cual sea su modelo, procedimiento y metodología.
• Existen técnicas que aplican incluso antes de que el software pueda ejecutarse parcialmente.
• Dentro de la gestión del proyecto de desarrollo debeexistir la gestión del proyecto de pruebas.
• Las pruebas nacen cuando nace el proyecto software y mueren cuando el software se retira.
28
Las pruebas integradas en el desarrolloEnfoque sobre un modelo de desarrollo tradicional
29
Especificación de requisitos
Diseño funcional
Diseño técnico
Especificación de componentes
Codificación
Pruebas de aceptación
Pruebas del sistema
Pruebas de integración
Pruebas de componentes
Desarrollo
e integración
Verificación
Validación
Especificación de requisitos
Diseño funcional
Diseño técnico
Especificación de componentes
Codificación
Ejecución pruebas de aceptación
Ejecución pruebas del sistema
Ejecución pruebas de integración
Planificación actividades test
Planificación pruebas de sistema
Planificación pruebas de integración
Planificación pruebas de componentes
Debugging y corrección de errores
Debugging y corrección de errores
Debugging y corrección de errores
Debugging y corrección de errores
Ejecución pruebas de componentes
Las pruebas integradas en el desarrolloPirámide de las pruebas
30
Las pruebas integradas en el desarrolloCuadrante de las pruebas
31
Las pruebas integradas en el desarrolloPruebas de software en mantenimiento
Pruebas después de la aceptación
o pruebas de mantenimiento• Prueba del evolutivo
• Repetición de la prueba (correctivo)
• ¡¡¡ Regresión !!!• Sin una arquitectura software adecuada:
• un pequeño cambio puede provocar repetir muchas pruebas.
• ¡¡¡tocas un módulo y se estropea otro !!!
32
La responsabilidad del TesterUn enfoque diferente
33
La responsabilidad del TesterEl valor del tester
• La independencia de las pruebas. ¿somos objetivos al evaluar nuestra creación?
• Un tester profesional nos aporta:
• Objetividad
• Orientación a la calidad del producto
• Información para la mejora del producto
• Información para la mejora del proceso
• Nuevos puntos de vista del uso del software
• Técnicas y estrategias
• Orientación a ROI. Pruebas rentables
• Visión del coste del fallo
34
FuturoExistirá más software y más complejo
35
Futuro ¿Futuro?De que se habla
• El tema de máxima actualidad es la automatización de las pruebas
• Cómo integrar a los testers y el testing en el desarrollo
• Para el desarrollo tradicional, se encuentran soluciones
• Para el desarrollo ágil el escenario es muy difícil. Los desarrolladores no suelen tener una visión completa del testing. Los tester no siempre saben desarrollar
• ¿perfiles mixtos?
• Pruebas no funcionales (vulnerabilidad, fiabilidad, usabilidad)
• TDD o Desarrollo dirigido por las pruebas
• Integración continua y DevOps
36
Futuro¿Que veremos?
• Frameworks que permiten:
• Hacer viables económicamente las pruebas
• Simplificar el paso del requisito al binario en producción
• Crear software que se prueba solo.
• Derivación de los casos de pruebas desde requisitos, diseños y modelos
• Automatización del desarrollo. DevOps o pasar del requisito a producción con un software de calidad en 4 horas
• ¡¡ Desarrolladores con una gran cultura y conciencia de las pruebas !!
37
Conclusiones.
• Las prácticas de testing y la calidad del software aplicadas por el propio desarrollador le ayudan en el objetivo de crear buen software
• Una adecuada estrategia de pruebas realizadas por el desarrollador aumenta su productividad
• Muchas de las mejores prácticas del desarrollo software vienen motivadas por las pruebas
• Los resultados de las pruebas y la BBDD de defectos deben utilizarse para mejorar la actividad de desarrollo
38
Siguientes pasos para el desarrollador.
• Desaprender su forma de construir software. Cambiar los hábitos
• Integrar en su trabajo las técnicas y herramientas de pruebas
• Crear software “testable”
• Tomar conciencia de su responsabilidad en la calidad del software principalmente antes de y durante la construcción
• Acercarse a la propuesta de ISTQB
39
www.mtp.es
El viaje seguro a la
transformación digitalAseguramiento del negocio a
través de un uso eficiente de
las tecnologías de la
información.