La estrategia FULL container


Sabías que los desarrolladores en Tesla pueden hacer un deploy al firmware de sus autos (juro que deben estar de oferta o algo en Nueva Zelanda porque de repente TODOS tienen uno!) en cuestión de SEGUNDOS?

Pila de containers
La importancia de los containers en testing!

Y ojo, no te estoy diciendo que hacen Push a Producción directamente. Estamos hablando de que pasan por pipelines automatizados chequeando y validando que todo esté bien, que nada se haya roto con el cambio y que lo nuevo funciona como se espera. Pero...cómo hacen? Por qué no estamos todos haciendo lo mismo? Qué va a necesitar el futuro Test Engineer o SDET para conseguir un laburo? Bueno... de eso les vengo a hablar.


Automatizando la automatización.


El uso de containers en el ciclo de testing del software acelera la entrega de funcionalidades y mejoras al usuario. Pero ojo, no es solo que el uso de containers ayuda a testing, lo hace también al desarrollo! Y están íntimamente ligados, como se imaginarán.


La containerización (una de las palabras bastardeadas al Spanglish más difíciles de escribir) es una práctica por la cual se busca aislar y encapsular una aplicación con su propio ambiente y todo lo necesario para funcionar, de manera que funcione mucho más rápido y LIGERO sobre todo que una clásica máquina virtual.


Ya hemos hablado de qué es un container y explicado la diferencia con máquinas virtuales. Les dejo el post acá. Ahora...lo genial de todo esto es que esta práctica trabaja MUY bien en conjunto con métodos de testing como Selenium, Cypress, Playwright, dándonos ventajas que van a elevar el trabajo de testing a niveles insospechados.


Por un lado, los containers habilitan a los devs a empaquetar en un...CHAN CHAN CHAN CHAN: container, la aplicación y todas sus dependencias en un ambiente operativo que es completamente independiente de cualquier máquina local y sus configuraciones que puedan interferir con el funcionamiento.

Developer frente a su pantalla
Cómo decís? En mi local funciona!

Podríamos decir que el chiste de "funciona en mi local" ya no va más con este approach. En todo caso, sería "funciona en mi container", pero no debería ser así!


Si el developer labura en Linux o Windows, no importa, ya que los containers abstraen y automatizan al nivel del Sistema Operativo, por lo que la aplicación puede correr en Windows, Linux o un Super Nintendo.

Así que, hablando mal y pronto, ahorran muchos recursos a nivel máquina para levantar estos ambientes en containers. Es la auténtica virtualización al nivel de sistemas operativos, con todo lo que ello implica.


La palabra clave es: Estandarización. Lo que logran estos containers, perfectamente empaquetados y prolijos, es que tengamos una misma base de la que partir para los ambientes de prueba. Ahh... huelen eso? Son ambientes de prueba perfectamente horneados y listos para ser destrozados a pruebas, sin tener que preocuparnos porque se olvidaron de correr tal proceso, incluir tal dependencia o si tal cosa no fue configurada bien ese día porque a Roberto se le pasó.


Si trabajan en testing o en desarrollo seteando ambientes de prueba, sabrán que un gran porcentaje de errores de los que encontramos se suelen deber a problemas de configuración de ambientes y, también, lo problemático en general que es todo esto. Ahora...cuando hablamos de Containers hablamos de hacer clones prácticamente, que se levantan sin un uso intensivo de recursos! Parecido a la famosa imagen que se usaba en su momento (a veces todavía se usa?) de un sistema operativo para su instalación. Qué tal?


Entonces tenés una práctica que remueve mucha de esa fricción a la hora de proveer ambientes de prueba confiables, lo que aumenta la velocidad de tenerlos operativos, la consistencia que se espera de ellos que se traduce en menos defectos inválidos y pérdidas de tiempo en general, para todos.


Pero pará... qué hace exactamente Testing con los containers?


Bueno, de muchas maneras! Pensemos por ejemplo en el seteo de un framework Java con Cucumber y Selenium WebDriver. Todo lo que es dependencias, el ChromeDriver y su versión, Java, Gradle o Maven...todo eso lo podemos tener estandarizado en un container. No más tener que andar configurando todo de cero, que problemas con el JDK y la máquina de Francisco, que el Gradle HOME no está seteado en la de Juan Carlos... en fin, se imaginan el ahorro de tiempo.


Por supuesto, y siguiendo las mejores prácticas de Docker, un container debería tener una sola responsabilidad. No deberíamos tener un container con la app, el ambiente de pruebas y las pruebas todo en uno. Por qué? Bueno, les dejo la tarea de decirme por qué en los comentarios!

Una bonita lupa
Usando herramientas para potenciar testing

Entonces, para hacer las cosas bien, imaginemos que tenemos nuestro container con la app bajo prueba. Por otro lado otro container con nuestras pruebas completamente configuradas y listas para ser ejecutadas... cómo hacemos para que un container hable con el otro? Bueno, acá es donde entran herramientas como Docker Compose. De esta manera estamos levantando ambientes de prueba, con sus aplicaciones y por otro lado sus pruebas automatizadas, consistentemente configuradas de forma correcta y sin ruido que nos tenga corriendo como pollos sin cabeza en búsqueda de errores!


En conclusión.


Las empresas pueden pasar containers por sus pipelines de CI/CD, haciendo del deploy de ambientes de prueba, build de servidores y publicación de artefactos de testing tales como pruebas automatizadas y sus reportes, todo facilitado por los workflows containerizados de tests y sistemas bajo prueba.


Los SDET y Test Engineers hoy en día tenemos un lindo desafío por delante en términos de para dónde van nuestros skills y rol en general. Demasiado tiempo pasamos con la gallina de los huevos de oro de Selenium y Cucumber.

Un Test Engineer en Tesla tiene que saber programar en Java, JS o Python, conocimientos de arquitectura de software, poder debuggear sistemas distribuidos...tal cual los desarrolladores e ingenieros de software, ADEMAS de saber automatizar pruebas y procesos con cosas como Selenium, Cypress, Appium, Rest Assured, Jenkins y más.


Qué se suma a todo esto y para dónde va? Amigarse con los containers y su orquestación/integración. Docker llegó para quedarse, las pruebas automatizadas y otros procesos de testing automatizados se ven muy beneficiados de usar esta herramienta. Una manera de distinguirse es aprender estos procesos y herramientas! Cómo? Bueno, en este artículo lo hablamos, no?


Qué pensás? Te interesaría implementar containers a tu trabajo como tester? Lo hacés actualmente? Qué estás esperando?


79 visualizaciones0 comentarios

Entradas Recientes

Ver todo