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

aurelio.gandarillas@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.