NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR

Transcripción

1 NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR i id nachobayugar@gmail.com

2 NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE El desarrollo ágil El nuevo rol de QA La nueva perspectiva respecto a la calidad

3 LA CALIDAD DEL SOFTWARE ANTES Modelo de desarrollo en cascada

4 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado;

5 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado; Equipo de QA poco escalable;

6 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado; Equipo de QA poco escalable; Planificaciones rígidas, fechas de release inamovibles;

7 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado; Equipo de QA poco escalable; Planificaciones rígidas, fechas de release inamovibles; Contraposición de objetivos entre miembros del equipo;

8 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado; Equipo de QA poco escalable; Planificaciones rígidas, fechas de release inamovibles; Contraposición de objetivos entre miembros del equipo; Calidad relegada para el final del proceso, poco tiempo para dedicarle;

9 LA CALIDAD DEL SOFTWARE ANTES Equipo muy segmentado; Equipo de QA poco escalable; Planificaciones rígidas, fechas de release inamovibles; Contraposición de objetivos entre miembros del equipo; Calidad relegada para el final del proceso, poco tiempo para dedicarle; Poca eficiencia, sinergia y rentabilidad

10 CAMBIO DE ENFOQUE METODOLOGÍAS ÁGILES Dos objetivos preponderantes: Mejorar los tiempos de finalización de los productos, sin merma en la calidad; Definición dinámica de los atributos del producto (adaptabilidad a requisitos cambiantes).

11 CAMBIO DE ENFOQUE METODOLOGÍAS ÁGILES Metodologías ágiles como medio para cumplir esos fines.

12 CAMBIO DE ENFOQUE METODOLOGÍAS ÁGILES Metodologías ágiles como medio para cumplir esos fines. Cambio de perspectiva en relación al rol del QA dentro del proceso de desarrollo, y de la calidad en general

13 CAMBIO DE ENFOQUE METODOLOGÍAS ÁGILES Metodologías ágiles como medio para cumplir esos fines. Cambio de perspectiva en relación al rol del QA dentro del proceso de desarrollo, y de la calidad en general: Todos participan y aportan a cada fase del desarrollo; Una fase del proceso no debe esperar a que termine la anterior; Puntos en común en análisis, diseño, desarrollo, calidad.

14 METODOLOGÍAS ÁGILES EL ROL DE QA VERIFICAR QUE EL PRODUCTO FUNCIONA DE ACUERDO A LOS REQUISITOS DEFINIDOS

15 METODOLOGÍAS ÁGILES EL ROL DE QA VERIFICAR QUE EL PRODUCTO FUNCIONA DE ACUERDO A LOS REQUISITOS DEFINIDOS

16 METODOLOGÍAS ÁGILES EL ROL DE QA VERIFICAR QUE EL PRODUCTO FUNCIONA DE ACUERDO A LOS REQUISITOS DEFINIDOS Asegurar que el proceso de desarrollo permita una velocidad cada vez mayor, mejor calidad en los productos, y mejor experiencia de uso.

17 METODOLOGÍAS ÁGILES EL ROL DE QA Automatización de los tests

18 METODOLOGÍAS ÁGILES EL ROL DE QA Automatización de los tests No solo se testea la funcionalidad (Cross Browsing, Carga, Penetration Testing);

19 METODOLOGÍAS ÁGILES EL ROL DE QA Automatización de los tests No solo se testea la funcionalidad (Cross Browsing, Carga, Penetration Testing); Build Contínuo;

20 METODOLOGÍAS ÁGILES EL ROL DE QA Automatización de los tests No solo se testea la funcionalidad (Cross Browsing, Carga, Penetration Testing); Build Contínuo; Entendimiento del riesgo e impacto de los builds;

21 METODOLOGÍAS ÁGILES EL ROL DE QA Automatización de los tests No solo se testea la funcionalidad (Cross Browsing, Carga, Penetration Testing); Build Contínuo; Entendimiento del riesgo e impacto de los builds; Monitoreo y analítica web.

22 TESTS AUTOMÁTICOS BENEFICIOS Ahorro de tiempo (ejecución más rápida, menor feedback necesario, traspaso de conocimientos cuando los equipos cambian, reporte de bugs, etc); Tests sensibles que detectan hasta el más mínimo defecto (no es necesario depender de la evaluación "humana", detección de bugs difíciles de reproducir);

23 TESTS UNITARIOS Verifican solo una unidad de código. Permiten concentrarse en una pequeña parte del código, y verificar su funcionamiento

24 TESTS UNITARIOS EJEMPLO

28 TESTS UNITARIOS COBERTURA

31 TESTS DE INTEGRACIÓN Verifican la correcta interacción entre las diferentes unidades o módulos;

32 TESTS DE INTEGRACIÓN Verifican la correcta interacción entre las diferentes unidades o módulos; Además, hay cosas que un test unitario no puede probar, como acceso a base de datos para búsquedas, inserciones, etc.

33 TESTS DE INTEGRACIÓN

34 TESTS FUNCIONALES Ver la aplicación completa como una caja negra, situándose en el punto de vista del usuario final. Además, en en general con tests de integración + unitarios, no se pueden probar vistas, configuraciones del servidor, etc. Adicionalmente, en muchos frameworks, los tests de integración simulan un uso de la base, pero de todos los registros que se generan, se hace un rollback al final del tests (nunca se comittean). Entonces, un tests no puede ver o usar lo que generó el anterior. En los tests funcionales, se usa la base y no se hace rollback, por lo que los registros de un test pueden usarse en el siguiente, posibilitando la creación de suites o tests de flujos complejos.

35 TESTS FUNCIONALES

36 TESTS AUTOMÁTICOS CONCLUSIONES

37 Unitarios TESTS AUTOMÁTICOS CONCLUSIONES

38 TESTS AUTOMÁTICOS CONCLUSIONES Unitarios Fomentan el cambio: son una guía para el programador que va a modificar la aplicación. Si la batería de tests unitarios es completa, ante cualquier modificación del código se va a saber si se generó un error o no, o si la aplicación se sigue comportando de la misma manera. Esto da más seguridad al programador a la hora de modificar o mantener código de otro, hacer refactors, fixes, etc.

39 TESTS AUTOMÁTICOS CONCLUSIONES Unitarios Fomentan el cambio: son una guía para el programador que va a modificar la aplicación. Si la batería de tests unitarios es completa, ante cualquier modificación del código se va a saber si se generó un error o no, o si la aplicación se sigue comportando de la misma manera. Esto da más seguridad al programador a la hora de modificar o mantener código de otro, hacer refactors, fixes, etc. Simplifican la integración: Permiten llegar a la fase de integración con un alto grado de seguridad de que el código está funcionando correctamente, lo que permite que dicha fase se concentre en encontrar problemas de integración, y que así el testing sea más efectivo.

40 TESTS AUTOMÁTICOS CONCLUSIONES Unitarios Fomentan el cambio: son una guía para el programador que va a modificar la aplicación. Si la batería de tests unitarios es completa, ante cualquier modificación del código se va a saber si se generó un error o no, o si la aplicación se sigue comportando de la misma manera. Esto da más seguridad al programador a la hora de modificar o mantener código de otro, hacer refactors, fixes, etc. Simplifican la integración: Permiten llegar a la fase de integración con un alto grado de seguridad de que el código está funcionando correctamente, lo que permite que dicha fase se concentre en encontrar problemas de integración, y que así el testing sea más efectivo. Documentan el código: las propias pruebas son documentación del código, porque ahí se puede ver como utilizarlo;

41 TESTS AUTOMÁTICOS CONCLUSIONES Unitarios Fomentan el cambio: son una guía para el programador que va a modificar la aplicación. Si la batería de tests unitarios es completa, ante cualquier modificación del código se va a saber si se generó un error o no, o si la aplicación se sigue comportando de la misma manera. Esto da más seguridad al programador a la hora de modificar o mantener código de otro, hacer refactors, fixes, etc. Simplifican la integración: Permiten llegar a la fase de integración con un alto grado de seguridad de que el código está funcionando correctamente, lo que permite que dicha fase se concentre en encontrar problemas de integración, y que así el testing sea más efectivo. Documentan el código: las propias pruebas son documentación del código, porque ahí se puede ver como utilizarlo; Errores más fáciles de localizar: dado que hay pruebas unitarias que pueden desenmascararlos.

42 TESTS AUTOMÁTICOS CONCLUSIONES Integración y funcionales: Testean que la aplicación cumpla con el propósito para el que se desarrolló: el test de integración se hace pensando en los usos de la aplicación;

43 TESTS AUTOMÁTICOS CONCLUSIONES Integración y funcionales: Testean que la aplicación cumpla con el propósito para el que se desarrolló: el test de integración se hace pensando en los usos de la aplicación; Permiten descubrir errores funcionales y de diseño: pueden evidenciar errores que no tengan que ver con métodos que no hacen lo que tienen que hacer, sino con una aplicación mal diseñada, en la que no todas sus partes encajan de manera adecuada en todos los casos. Además, una aplicación puede tener errores a pesar de tener 100% de cobertura en líneas.

44 TESTS AUTOMÁTICOS CONCLUSIONES Integración y funcionales: Testean que la aplicación cumpla con el propósito para el que se desarrolló: el test de integración se hace pensando en los usos de la aplicación; Permiten descubrir errores funcionales y de diseño: pueden evidenciar errores que no tengan que ver con métodos que no hacen lo que tienen que hacer, sino con una aplicación mal diseñada, en la que no todas sus partes encajan de manera adecuada en todos los casos. Además, una aplicación puede tener errores a pesar de tener 100% de cobertura en líneas. Documentan casos de uso: pueden mapearse uno a uno con un caso de uso de la aplicación, y por tanto la batería de tests de integración y funcionales, documentan todos los casos de uso posibles de la aplicación.

45 TESTS AUTOMÁTICOS CONCLUSIONES Integración y funcionales: Testean que la aplicación cumpla con el propósito para el que se desarrolló: el test de integración se hace pensando en los usos de la aplicación; Permiten descubrir errores funcionales y de diseño: pueden evidenciar errores que no tengan que ver con métodos que no hacen lo que tienen que hacer, sino con una aplicación mal diseñada, en la que no todas sus partes encajan de manera adecuada en todos los casos. Además, una aplicación puede tener errores a pesar de tener 100% de cobertura en líneas. Documentan casos de uso: pueden mapearse uno a uno con un caso de uso de la aplicación, y por tanto la batería de tests de integración y funcionales, documentan todos los casos de uso posibles de la aplicación. Más fáciles de mantener que los unitarios: es más dificil que cambie un caso de uso de una aplicación, a que cambie un método interno.

46 Buenas prácticas: TESTS AUTOMÁTICOS CONCLUSIONES

47 TESTS AUTOMÁTICOS CONCLUSIONES Buenas prácticas: Correr los tests unitarios rápidamente y frecuentemente.

48 TESTS AUTOMÁTICOS CONCLUSIONES Buenas prácticas: Correr los tests unitarios rápidamente y frecuentemente. Hacer tests mantenibles y fáciles de leer, y que sirvan para identificar fácilmente los errores.

49 TESTS AUTOMÁTICOS CONCLUSIONES Buenas prácticas: Correr los tests unitarios rápidamente y frecuentemente. Hacer tests mantenibles y fáciles de leer, y que sirvan para identificar fácilmente los errores. Mantener la cobertura

50 TESTS AUTOMÁTICOS CONCLUSIONES Buenas prácticas: Correr los tests unitarios rápidamente y frecuentemente. Hacer tests mantenibles y fáciles de leer, y que sirvan para identificar fácilmente los errores. Mantener la cobertura Testear en todos los niveles

51 TESTS AUTOMÁTICOS CONCLUSIONES Buenas prácticas: Correr los tests unitarios rápidamente y frecuentemente. Hacer tests mantenibles y fáciles de leer, y que sirvan para identificar fácilmente los errores. Mantener la cobertura Testear en todos los niveles Usar integración contínua

52 INTEGRACIÓN CONTÍNUA Incorporar todo el tiempo pequeñas piezas de funcionalidad al producto. Realizar pruebas de forma automática lo más tempranamente posible en la fase de desarrollo, con el fin de detectar fallos cuanto antes; La calidad no se deja para el final del proceso, sino que se incorpora en todas sus etapas; La calidad pasa a ser responsabilidad de todo el equipo (los tests son corridos por los desarrolladores ante cada cambio, por lo que pueden detectar y solucionar problemas en forma contínua sin esperar que QA sea quién identifique el problema)

53 TESTS AUTOMÁTICOS MÁS TESTS CrossBrowsing Pérdida de funcionalidad en diferentes browsers Correcta visualización Carga Respuesta ante picos inusuales de tráfico Correcto funcionamiento ante segmentos sostenidos de alto tráfico

54 Seguridad TESTS AUTOMÁTICOS MÁS TESTS

60 REVISIÓN DE CÓDIGO Responsabilidad Compartida Difusión y aprendizaje de buenas prácticas Código más estandarizado Código más confiable, con menos bugs Todos en el equipo conocen el código Costos: Desenfoca otro recurso La revisión implica tiempo Debe ser sincrónica

61 RIESGO E IMPACTO DE CADA BUILD Dado que se hacen cambios contínuos y se agrega funcionalidad a una aplicación que está funcionando y siendo usada por el usuario, el efecto de cada cambio puede ser muy grande. Debe haber un rápido análisis del riesgo y del impacto No solo QA, sino también desarrollo debe ser capaz de dimensionar el riesgo y el impacto

62 RIESGO E IMPACTO MODELO ACC Definir Atributos (características del producto) Componentes (las piezas, al nivel de especificación deseado: apis, clases, base de datos, nombre de un módulo); Capacidades (describen el comportamiento del producto; son las cosas testeables).

63 RIESGO E IMPACTO MODELO ACC

64 RIESGO E IMPACTO MODELO ACC

65 ALGUNOS LINKS Tests unitarios: Java: junit.org Grails: Spock: Javascript: Cobertura de código: Java: Grails:

66 ALGUNOS LINKS Tests Funcionales: Selenium Firefox IDE: WebDriver Java: Load Testing: Penetration Testing: Integración contínua: Evaluación de impacto y riesgo:

67 MONITOREO Y FEEDBACK

68 MONITOREO Y FEEDBACK Saber como se comporta y cómo es usada la aplicación, y a partir de eso generar información que permita tomar decisiones. Performance, errores, uptime Real User Monitoring Métricas funcionales Alarmas Métricas de negocio

69 MONITOREO TIEMPOS Y ERRORES Cuánto tarda la aplicación en procesar datos? Cuánto tardan las querys a la base de datos? Qué porcentaje de errores hay, en relación a la cantidad de requests recibidos / procesos / threads inciados? Hay picos de errores? Hay picos de tiempos altos? La aplicación es estable? Reacciona bien a los picos de tráfico? La disponibilidad de la aplicación es buena (uptime)? Los tiempos de frontend son aceptables? Los tiempos se mantienen en todos los browsers?

70 MONITOREO TIEMPOS Y ERRORES (

71 MONITOREO ALARMAS Pensar en la alarma antes de generar la nueva versión de la aplicación.

72 MONITOREO TIEMPOS Y ERRORES (

73 MONITOREO MÉTRICAS DE NEGOCIO Cómo se usa la aplicación? Qué partes de la aplicación son las más valoradas por el usuario? Análisis de dropout de flujos AB Testing (cuál versión es mejor)? Los nuevos features fueron beneficiosos para el negocio?

74 MONITOREO MÉTRICAS FUNCIONALES Buscar indicadores que manifiesten si la aplicación está funcionando bien, más allá de errores o tiempos Ejemplos: datos procesados correctamente, consistencia de datos entre distintas unidades de negocios, datos encolados para ser procesados, volumen datos procesados, volumen de datos en diferentes estados, etc.

75 MONITOREO LINKS Performance: Métricas de negocio:

76 CONCLUSIONES Asegurar que el proceso de desarrollo fomente

77 CONCLUSIONES Asegurar que el proceso de desarrollo fomente: Mejora contínua en la calidad

78 CONCLUSIONES Asegurar que el proceso de desarrollo fomente: Mejora contínua en la calidad Mejora contínua en la velocidad para poner en producción

79 CONCLUSIONES Asegurar que el proceso de desarrollo fomente: Mejora contínua en la calidad Mejora contínua en la velocidad para poner en producción Requisitos cambiantes

80 CONCLUSIONES Asegurar que el proceso de desarrollo fomente: Mejora contínua en la calidad Mejora contínua en la velocidad para poner en producción Requisitos cambiantes La calidad es una responsabilidad de todos

81 CONCLUSIONES QA NO ejecuta tests;

82 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar.

83 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar. QA conoce en detalle el funcionamiento de la aplicación y asegura el testing no solo el código, sino también de los posibles usos de la aplicación.

84 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar. QA conoce en detalle el funcionamiento de la aplicación y asegura el testing no solo el código, sino también de los posibles usos de la aplicación. Participa de revisiones de código;

85 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar. QA conoce en detalle el funcionamiento de la aplicación y asegura el testing no solo el código, sino también de los posibles usos de la aplicación. Participa de revisiones de código; QA entiende el riesgo e impacto de cada cambio, y fomenta que desarrollo lo entienda;

86 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar. QA conoce en detalle el funcionamiento de la aplicación y asegura el testing no solo el código, sino también de los posibles usos de la aplicación. Participa de revisiones de código; QA entiende el riesgo e impacto de cada cambio, y fomenta que desarrollo lo entienda; QA entiende y analiza la performance del producto

87 CONCLUSIONES QA NO ejecuta tests; Asegura la automatización de los tests, asesorando que tipo de test conviene (unitario, integración o funcional), y qué casos de uso se deberían probar. QA conoce en detalle el funcionamiento de la aplicación y asegura el testing no solo el código, sino también de los posibles usos de la aplicación. Participa de revisiones de código; QA entiende el riesgo e impacto de cada cambio, y fomenta que desarrollo lo entienda; QA entiende y analiza la performance del producto QA entiende y analiza la manera en que los usarios interactúan con el producto