¿Cuál era tu testing en el 2013? ¿Querés saber qué hacía LinkedIn por aquella época? Son preguntas que tal vez te hayas hecho en alguna oportunidad mientras estabas recorriendo páginas, publicaciones o grupos de discusión dentro de la red LinkedIn.
Si bien hace algunos años que estoy en esta red, desde hace 3 años estoy interactuando verdaderamente mucho, todos los días y de diferentes maneras, con dos perfiles: el personal y el de empresa, publicando novedades y artículos, presentaciones, siguiendo las novedades de los distintos grupos de discusión a los que pertenezco además de administrar los creados por mi, y obviamente respondiendo los comentarios que las personas que me siguen van dejando en mis publicaciones.
Solo aquellos que logran este tipo de interacción con ésta red han podido darse cuenta de las últimas novedades y cambios que se han implementado para mejorar la “experiencia de usuario”, o sea, nosotros.
Cambios como el nuevo look&feel de los “grupos de discusión” además de sus nuevas funciones, es uno de los que se aplicaron el año pasado, entre otros.
También la posibilidad de monitorear el impacto de nuestras publicaciones desde el espacio de una página es otra de las mejoras que fueron implementadas durante el 2018.
Años atrás cuando leía de las oportunidades de negocios que ofrecía está red, me parecía que estaban fuera de mi alcance, sin embargo a medida que iban creciendo mis acciones aquí, me iba dando cuenta que no era así ya que comenzaba a recibir contactos y propuestas para organizar reuniones de trabajo y/o de proyectos.
El siguiente contenido corresponde a un artículo publicado en el 2013 por Sony Mohapatra, donde relataba acerca de la metodología de control de calidad que aplicaba LinkedIn. Recuerdo que por aquel año había leído el artículo pero no hice más que eso, sólo escribí un breve comentario al respecto, pero ahora, parado en el 2019 y con algunos proyectos y experiencias vividas, me cabe reflexionar sobre las distintas técnicas y metodologías con la que por aquella época contaba LinkedIn, realmente increíble para muchos de nosotros en aquella época, ¿verdad? Digo increíble porque me hizo pensar qué estábamos haciendo nosotros -desde Argentina- para el mundo. Cuán lejos estábamos de ellos en cuanto a lo tecnológico, y me cabe otra reflexión: ¿en qué estadío estarán ahora no? ¿Cuántos años tecnológicos nos estarán llevando? ¿Cómo estará compuesto su laboratorio de aseguramiento y control de la calidad? ¿Cuáles serán sus herramientas preferidas? ¿Estarán testeando versiones que se estarán en producción dentro de 3 o 5 años?
En fin, te adelanto los títulos que aborda la autora
Estrategia y proceso de prueba
Pruebas de integración
Pruebas de rendimiento
Pruebas funcionales
Cross-Browser Testing
Automatización
Ejecución del plan de pruebas en el Test Manager
Pruebas L10N
Despliegue
Comentario:
He dejado el contenido tal y como fué escrito por la autora, es decir en primera persona. En algunos casos conservé el término en inglés porque es más común de leerlo así y además, en algunas partes incluí breves comentarios personales a modo de reflexión.
——–
Control de calidad – Metodología de prueba de LinkedIn – Sony Mohapatra 18 de junio de 2013
El equipo
Un equipo de pruebas típico en LinkedIn incluye gerentes de productos, ingenieros de desarrollo, ingenieros de software en pruebas e ingenieros de calidad. Tenemos un equipo dedicado de ingenieros que rotan semanalmente y cuyo único trabajo de esa semana es corregir y cerrar errores.
Estrategia y proceso de prueba
Estrategia de prueba
Un ciclo de vida de prueba puede durar varias semanas y comienza con la primera semana de preparación para el inicio oficial. Los ingenieros de calidad hacen una revisión de las especificaciones del producto y crean un plan de prueba junto con una estimación de la fecha de lanzamiento. Las próximas semanas se dedican a escribir casos de prueba detallados en una herramienta interna llamada Test Manager. Las sesiones de capacitación se llevan a cabo en paralelo para educar a los ingenieros de desarrollo de productos sobre el ciclo de vida de las pruebas. Una vez que se completan los casos de prueba y la capacitación, comienzan las pruebas.
Reflexión personal: Se refiere a “Test Manager” de Microsoft.
Las tareas se asignan diariamente. Un panel de tareas realiza un seguimiento del progreso y supervisa los tickets recién presentados, mientras que las situaciones diarias se utilizan para discutir problemas. Este enfoque agresivo de seguimiento de estado nos ayuda a mantenernos actualizados y planear continuamente hacia el lanzamiento.
Reflexión personal: No te resulta familiar esta metodología? Acaso no lo estás aplicando desde hace muy poco tiempo? Hace cuánto venís usando esta forma de trabajo con este tipo de herramientas, 5 años?
Pruebas de integración
Las pruebas de integración y las pruebas funcionales se ejecutan en paralelo. Los SETs (Software Engineers in Test) realizan pruebas en API para condiciones positivas, negativas y de contorno. Las pruebas de integración se escriben en TestNG, un marco de prueba de Java. Estas pruebas se ejecutan cada noche y en cada registro de código. (Los detalles sobre las pruebas de integración seguirán en las publicaciones posteriores.)
Reflexión personal:TestNG es un framework para pruebas y testing que trabaja con Java y está basado en JUnit y NUnit, pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar, tales como: Anotaciones JDK 5. Configuración flexible de pruebas. Soporte para pruebas para data-driven testing.
Pruebas de rendimiento
Las pruebas de rendimiento son una parte importante de nuestro ciclo de lanzamiento. Los SETs comienzan con las pruebas de carga de back-end: ejecutamos pruebas de carga y obtenemos métricas de rendimiento, como valores de QPS pico y tiempos de respuesta. Luego utilizamos Apache JMeter y otras herramientas internas para garantizar que nuestro sistema pueda manejar la carga de producción según los criterios comerciales. En este punto, los ingenieros comienzan las pruebas de rendimiento frontend y producen métricas como carga de página, tiempo de ejecución de JavaScript, tamaño de página y tiempo de carga de componente de página. Los errores se archivan y se corrigen, y volvemos a ejecutar las pruebas hasta que alcanzamos nuestros objetivos de rendimiento.
Pruebas funcionales
El equipo de prueba, en su mayoría ingenieros de calidad y unos pocos ingenieros de desarrollo, se dedica a ejecutar los casos de prueba manualmente como parte de la prueba funcional. Las características se distribuyen entre los evaluadores, teniendo especial cuidado de que el mismo ingeniero no desarrolle ni pruebe una característica. Los errores se archivan y se tratan de manera agresiva para asegurar un ciclo de vida más corto.
En LinkedIn desarrollamos LiX, una plataforma de experimentación en línea y gestionamos el ciclo de vida de todas las pruebas y experimentos. Todas las características del producto están detrás de una prueba de LiX y las pruebas funcionales se realizan con LiX encendido y apagado. El equipo de pruebas participa en las pruebas de seguimiento de claves de página, códigos de seguimiento en el consumidor Kafka, pruebas de dispositivos en iPad y iPhone, y en la detección de gaps en métricas vinculadas con testing.
Cross-Browser Testing
Una vez completadas las pruebas funcionales, el equipo pasa a las pruebas de navegador, que se realizan en diferentes versiones de IE, Firefox, Safari y Chrome. Es importante encontrar y solucionar estos problemas del navegador de manera temprana y la colaboración con el equipo de webdev es particularmente importante aquí.
Automatización
La automatización comienza a continuación con cada tester escribiendo guiones para su función asignada, utilizando Ruby y Selenium como herramientas de automatización. Los scripts son compatibles con i18n (internacionalización) y se pasan a los equipos de i18n para comenzar su ciclo de prueba. Los casos de prueba se marcan como automatizados y se rastrean en Test Manager.
El gerente de producto y los recursos offshore están involucrados en la verificación de errores. Supervisamos la actividad de los errores utilizando el panel de control, rastreando la cantidad de defectos capturados y corregidos diariamente. Esto nos ayuda a revisar cualquier error reabierto y asegurar que no haya bloqueadores cerca de la fecha de release.
Ejecución del plan de pruebas en el Test Manager
Una vez que todos los scripts de automatización están listos, las pruebas de regresión se ejecutan todos los días en todos los navegadores compatibles a través de Test Manager contra nuevos builds, para capturar los errores a medida que aparecen. Se organiza una campaña de fallos para obtener retroalimentación de diferentes equipos, y la automatización activada por errores se realiza como parte de la verificación de errores.
Pruebas L10N
Una vez que se completa la automatización, los scripts de prueba se pasan al equipo de L10N (localización) para que se ejecuten en diferentes idiomas. El equipo agrega código para tomar capturas de pantalla en cada idioma, que los traductores utilizan para asegurarse de que los elementos de la interfaz de usuario tengan sentido contextualmente. Todos los errores archivados son solucionados inmediatamente por los desarrolladores de errores. Solo después de que el equipo de L10N se apaga en la interfaz de usuario, implementamos el producto en varios idiomas.
Despliegue
Cuando el código pasa a producción, el equipo de pruebas ejecuta comprobaciones de sanidad de producción para garantizar que la funcionalidad no se rompa. LiX aumenta lentamente al 100%, y monitoreamos y registramos constantemente la producción para detectar cualquier anomalía.
