Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Argentesting 2017 - The evolving role of QA

922 views

Published on

Charla

Expositores
Matías Kusznir
Ignacio Bayugar

Como evolucionó el modelo de calidad y el rol de QA en Mercado Libre.
Descripción etapas evolución. Modelo inicial. Aplicación monolítica y testeo manual.
Segunda etapa. Arquitectura microservicios y nacimiento de BA.
Tercera etapa. Transición y búsqueda del nuevo rol.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Argentesting 2017 - The evolving role of QA

  1. 1. Como evolucionó el modelo de calidad y el rol de QA en Mercado Libre The Evolving Role of QA
  2. 2. ¿ Qué magnitud tiene Mercado libre hoy ?
  3. 3. ➢ Sobre + de 30.000 vms ➢ + de 1.000 Desarrolladores ➢ Forman + de 65 equipos Diferentes ➢ Ejecutan 400 deploys diarios ➢ Mantienen + de 1.000 Aplicaciones ➢ Con un promedio de 25 millones de RPM ¿ Se imaginan este contexto sin un área de testing ?
  4. 4. Agenda 1. Descripción etapas evolución 2. Modelo inIcial. Aplicación Monolítica y Testeo Manual 3. Segunda etapa. Arquitectura microservicios y nacimiento de BA 4. Tercera Etapa. Transición y búsqueda del nuevo rol 5. Cuarta etapa. A que llegamos, que hacen hoy los expertos de BA 6. Ejemplos de herramientas desarrolladas por el team. 7. Próximos desafíos 8. Top 5 de prácticas a mejorar y algunas que nos salieron bien para ayudar a maximizar resultados en calidad.
  5. 5. 1) Etapas de la evolución
  6. 6. 2) Arquitectura Monolítica + QA Manual
  7. 7. # 1. ARQUITECTURA MONOLÍTICA ● Afectación total no parcial ● Muchos años de código sin test, dificil hacerlo testeable ● Errores de pocos afectan a todos ● Infraestructura cuello de botella (bases de datos, storage, etc)
  8. 8. # 2. Calidad al final del proceso, con QA Manual ● El proceso se alargaba por baja calidad ● El proceso se alargaba por competencia de recursos de QC ● Solo se revisaba el software funcionalmente, no peformance, estabilidad, etc. ● Era difícil escalar en cantidad de gente
  9. 9. # 1 Calidad al final del proceso con QA Manual Efecto bola de nieve, la única manera de ir logrando calidad era ir aumentando las reglas y el proceso Foto de la Situación.
  10. 10. 3) El cambio, nacimiento de Business Assurance(BA) y su primer enfoque
  11. 11. ● Microservicios ● Libertad tecnológica ● Se disolvió el equipo de QC ● Nacimiento del team de BA
  12. 12. Split Mercado Libre en “Celdas Independientes” ● Cada celda se hace responsable del Testing, con foco en automation. ● Libertad en elección tecnológica y de proceso
  13. 13. Primer enfoque del Team de BA ● No cometer errores de la arquitectura anterior ● Chequear otros aspectos de la calidad más que funcionalidad, ejemplo performance, estabilidad, mediciones, etc
  14. 14. 4) Transición y búsqueda del nuevo rol
  15. 15. 4) Transición y búsqueda del nuevo rol
  16. 16. Definimos en qué aportar y cómo… pero todo entraba en un solo perfil. a. Poco foco y expertise en cada tarea b. Poco seguimiento de principio a fin c. Rol muy amplio, tareas muy cambiantes, poca perspectiva de crecimiento individual (en que me conviene ganar expertise?) d. Actuabamos en base a pedidos de otras áreas, y no definiendo nosotros lo que ibamos a hacer. e. Empezamos a ver la necesidad de crear nuestras propias herramientas. Pero no teníamos claro quién las iba a mantener :(
  17. 17. 5) A que llegamos, que hacemos ahora
  18. 18. 5) A que llegamos, que hacemos ahora
  19. 19. 1. Más foco en las tareas de cada vertical, más expertise en los temas, cada vertical hace y busca sus propias herramientas. 2. Camino de crecimiento más claro para cada uno, impacto positivo en la motivación. 3. Mejor aporte de cada persona del área, y del área en general en el rol de aportar sin ser cuello de botella. 4. Planteamos nuestras tareas, indicando nosotros donde queremos aportar y armando nuestros propios backlogs y objetivos para eso, priorizando desde el negocio en general hacia los proyectos en los que queremos modificar cosas, y nos desde los proyectos que nos buscan y piden. 5. Queremos mover métricas, para sustentar con resultados lo que hacemos, pero lo pensamos tarde... todavía las estamos buscando.
  20. 20. 6) Ejemplos de herramientas desarrolladas por el equipo: Deploy Checker (SRE) Control automático de variables de calidad luego del deploy Consistency (SRE) Verifica integridad de datos entre diferentes APIs, sistema de alarmas Zeus (SRE) Trackeo de Logs históricos de APIS para análisis de bugs. UPTIME.COM (SRE) Registra las caídas en el sitio, mide el uptime Carga de PostMortem Gestión Deuda técnica
  21. 21. 6) Ejemplos de herramientas desarrolladas por el equipo: Test User (Testing) Crea usuarios y productos, pagos, envíos de testeo en producción con diferentes condiciones Gorgory API (tESTING) Chequea si se cumplen las condiciones para que una aplicación suba a producción o no (Continuos Delivery) Canejo (Analítica Digital) Mediciones de Usuarios con Crash en Mobile
  22. 22. 7) Lo que sigue
  23. 23. 7) Lo que sigue
  24. 24. Automatización del proceso completo: desde el desarrollo hasta producción.
  25. 25. Automatización del proceso completo: desde el desarrollo hasta producción. Automatización de la generación de tests y datos de tests
  26. 26. Machine Learning para automatizar tareas de análisis, testing y troubleshooting Automatización del proceso completo: desde el desarrollo hasta producción. Automatización de la generación de tests y datos de tests
  27. 27. 8. Top 5 Prácticas a Mejorar
  28. 28. 5.
  29. 29. Consenso entre Managers, qué esperamos de la calidad de nuestro sitio?
  30. 30. Consenso entre Managers, ¿qué esperamos de la calidad de nuestro sitio? ● Cuánto uptime? ● Cobertura? ● Error Rate? ● Tiempo de respuesta, APDEX, etc? ● En cuánto tiempo queremos enterarnos de un problema? (5-10 min? , 1 hora?)
  31. 31. 4.
  32. 32. “Aprender de las caídas y gestionar el plan de acción (Post-Mortem culture)”
  33. 33. ● Reuniones de revisión de causas de las caídas ● Foco en enriquecer el plan de acción para prevenir el evento y/o minimizar su duración ● Gestionar todo ese plan de acción es fundamental, revisar la criticidad de las tareas y que se terminen a tiempo desde los diferentes equipos. “Aprender de las caídas y gestionar el plan de acción (Post-Mortem culture)”
  34. 34. 3.
  35. 35. “Tomemos compromisos internos, SLA entre microservicios no son burocracia, si un pacto de caballeros”
  36. 36. ● Sin SLAs es difícil negociar y setear una expectativa clara de que se espera de la calidad entre servicios. ● Gran problema de clima interno cuando alguno/s servicios funcionan mal y el resto genera alarmas y problemas productivos por este comportamiento. ● Termina generando una subida masiva de thresholds de alarmas que interfieren en detectar pronto problemas reales “Tomemos compromisos internos, SLA entre microservicios no son burocracia, si un pacto de caballeros”
  37. 37. 2.
  38. 38. “El testing sigue siendo la mejor manera de prevenir bugs, no alcanza con pasar de manual a automático, tiene que ser, además, inteligente”
  39. 39. “El testing sigue siendo la mejor manera de prevenir bugs, no alcanza con pasar de manual a automático, tiene que ser, además, inteligente” ● No automatizar sin pensar la mejor estrategia ● Mucho foco en los test más baratos (Unitarios) ● Los test lentos tienden a deprecarse ● Los test flaky también ● Los test de UI son lentos y tendientes a ser Flaky, además cuesta más detectar el origen del problema. ● Hagamos benchmarks de las mejores tools para cada tecnología y tipo de test ● Mocks son claves para aumentar cobertura y generar estabilidad en los test
  40. 40. 1.
  41. 41. Gestionar la deuda técnica.
  42. 42. ● Existe, que no exista es utópico .. ● Es implacable, si no la minimizas vuelve en forma de problemas productivos ● Es preferible priorizarla, categorizarla y darle una porción de tiempo en el plan, que parar todo por múltiples problemas productivos. ● Hay que invertir tiempo en descubrirla. Gestionar la deuda técnica.
  43. 43. 8. Top 5 Prácticas que nos dieron resultados
  44. 44. 5.
  45. 45. La calidad como responsabilidad de todos Claves para mantener la agilidad de una startup sin vivir en caos ● Responsabilizar a los equipos de desarrollo de la creación, ejecución y mantenimiento de los tests ● Dejar de ser cuello de botella ● Agilidad de deploys y mucho foco en el monitoreo y troubleshooting
  46. 46. 4.
  47. 47. ● Identificamos los puntos en que nuestro software necesitaba mejorar, pero no podían ser atacados desde desarrollo. ● Investigamos, alcanzamos expertise, y empezamos a cumplir un rol de consultores. ● Resolvimos problemas complejos, incluso implementando las soluciones. Nos volvimos fuente de consultas Pasamos de auditores a expertos
  48. 48. 3.
  49. 49. Evidenciar las oportunidades de calidad según su impacto en el negocio ● Evidenciar cómo los problemas de performance impactan en el cliente y en el negocio: ○ Monetizando errores y midiendo el impacto de cada segundo de load time en la conversión ○ Generando alertas cuando por problemas de performance, se afecta la tasa de aprobación de los pagos. ● Reproducir escenarios para hacer palpables errores detectados al revisar las aplicaciones; por ejemplo, reproducir con un stress test lo que pasaría en un hot sale para hacer visibles esos problemas ● Medir y reportar el tiempo de downtime en el negocio
  50. 50. 2.
  51. 51. Mucho foco en el monitoreo Tenemos que generar nuestro propio backlog. Para eso, necesitamos conocer a la perfección cómo funciona cada aplicación, para saber qué oportunidades de performance, estabilidad, escalabilidad, conversión y mejoras de funcionalidad tiene. Generar métricas, procesarlas e interpretarlas, es fundamental para evidenciar esas oportunidades
  52. 52. 1.
  53. 53. Hacer nuestros propios desarrollos ● Cuando hacemos una herramienta, estamos logrando que una o un par de personas, hagan el trabajo de miles ● Fundamental detectar problemas comunes, tareas rutinarias ● Todos tienen que tener el skill de developer. Lo que nos diferencia de desarrollo NO es ese skill, sino el foco en calidad
  54. 54. Muchas Gracias!!! matias.kusznir@mercadolibre.com ignacio.bayugar@mercadolibre.com

×