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.

1. Como evolucionó el modelo de calidad y el rol de
QA en Mercado Libre
The Evolving Role of QA

2. ¿ Qué magnitud tiene Mercado
libre hoy ?

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. 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. 1) Etapas de la evolución

6. 2) Arquitectura Monolítica + QA Manual

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. # 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. # 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. 3) El cambio, nacimiento de Business Assurance(BA)
y su primer enfoque

11. ● Microservicios
● Libertad tecnológica
● Se disolvió el equipo de QC
● Nacimiento del team de BA

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. 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. 4) Transición y búsqueda del nuevo rol

15. 4) Transición y búsqueda del nuevo rol

20. 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 :(

21. 5) A que llegamos, que hacemos ahora

22. 5) A que llegamos, que hacemos ahora

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

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

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

26. 7) Lo que sigue

27. 7) Lo que sigue

28. Automatización del proceso completo: desde el
desarrollo hasta producción.

29. Automatización del proceso completo: desde el
desarrollo hasta producción.
Automatización de la generación de
tests y datos de tests

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

31. 8. Top 5 Prácticas a
Mejorar

32. 5.

33. Consenso entre Managers, qué esperamos de la
calidad de nuestro sitio?

34. 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?)

35. 4.

36. “Aprender de las caídas y gestionar el plan de
acción (Post-Mortem culture)”

37. ● 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)”

38. 3.

39. “Tomemos compromisos internos, SLA entre
microservicios no son burocracia, si un pacto de
caballeros”

40. ● 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”

41. 2.

42. “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”

43. “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

44. 1.

45. Gestionar la deuda técnica.

46. ● 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.

47. 8. Top 5 Prácticas que nos
dieron resultados

48. 5.

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

50. 4.

51. ● 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

52. 3.

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

54. 2.

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

56. 1.

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

59. Muchas Gracias!!!
matias.kusznir@mercadolibre.com
ignacio.bayugar@mercadolibre.com