Encuentro GeneXus 2017 -
DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad.
https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus
Alba y Consuelo - Desarrollo y Diseño un solo mundo9punto5
Consuelo y Alba son de disciplinas diferentes pero han aprendido que para ser un equipo realmente es necesario saber trabajar en conjunto. Esta charla mostró sus experiencias, lo que han aprendido, como han superado las dificultades en menor tiempo y que es necesario para hacer comunicar las diferentes disciplinas dentro de un proyecto.
Mapa conceptual sobre Gerencia de Proyectos y Ciclo de Vida de un Proyecto.Luz Mary Pinzon Martinez
En el mapa conceptual se da a conocer las principales características que debe tener los profesionales que estén liderando proyecto, y las diferentes fases que se llevan a cabo en la ejecución de los mismos.
Alba y Consuelo - Desarrollo y Diseño un solo mundo9punto5
Consuelo y Alba son de disciplinas diferentes pero han aprendido que para ser un equipo realmente es necesario saber trabajar en conjunto. Esta charla mostró sus experiencias, lo que han aprendido, como han superado las dificultades en menor tiempo y que es necesario para hacer comunicar las diferentes disciplinas dentro de un proyecto.
Mapa conceptual sobre Gerencia de Proyectos y Ciclo de Vida de un Proyecto.Luz Mary Pinzon Martinez
En el mapa conceptual se da a conocer las principales características que debe tener los profesionales que estén liderando proyecto, y las diferentes fases que se llevan a cabo en la ejecución de los mismos.
1. Agile 101: La Germinación: Introducción a la Agilidad
2. Agenda
3. Love is in the air: El proyecto ideal con metodología Waterfall
4. Waterfall
5. Love is in the air: El cliente. El mismo está contento porque se ha podido comunicar sus ideas y sus expectativas se han cumplido. No se han generado delays ni ha perdido dinero. Se fortalece la confianza con el equipo y conjuntamente enfrentan cualquier desafío de forma alineada.
6. Love is in the air: El Equipo. Los mismos tienen buena comunicación, se encuentran motivados, la documentación no representa un blocker y el equipo tiene todo el material y las skills necesarias para desarrollar el producto solicitado.
7. Love is in the air: El producto: el producto es exactamente lo que el cliente quería y había visualizado.
8. Cortemos con la Dulzura.
9. Cortemos con la Dulzura - El cliente.
10. Cortemos con la Dulzura - La comunicación.
11. Cortemos con la Dulzura - El equipo.
12. Cortemos con la Dulzura - El equipo: Vacaciones por favor!
13. Cortemos con la Dulzura - El producto.
14. Do things right vs. Do the right thing
15. Mafalda.
16. Waterfall
17. Lo que nadie dice de Waterfall.
18. Waterfall Sum Up
19. ¿Porque nadie me lo dijo antes?
20. ¿Porque repetimos la historia?
21. Problemas que nos llevan a repetir la historia.
22. Germinando.. la filosofía Agile
23. El factor humano.. Toyota el gran referente.
24. El factor Humano - La motivación
25. Trípode y balance: Productividad - Calidad - Felicidad
26. Gestión y Visión de la Complejidad
27. ¿ Que es Agile ?
28. El Manifiesto Agile
29. La Esencia Ágil
30. Entrada en calor: Requerimiento Ágil
31. Los Principios Ágiles
32. Métodologías Ágiles
33. Eres Ágil? https://www.versionone.com/agile-101/agile-development-quiz/
34. https://www.versionone.com/agile-101/agile-development-quiz/
35. Gracias.
[DEISER Day Conferences] "DevOps en DEISER" - David García & Carlos Fernández Deiser
"DevOps en DEISER: En producción 10 veces más rápido con Atlassian"
Dos miembros del DEISER Team presentaron en detalle cómo hemos simplificado los tiempos de producción del equipo de desarrollo gracias al uso correcto de las herramientas Atlassian y algunas automatizaciones personalizadas.
Asiste al DEISER Enterprise Madrid 2018, el próximo 14 y 15 de noviembre; suscríbete al newsletter oficial para obtener toda la información que buscas - https://deiser-enterprise-day.deiser.com/
-------------------------------------------------------------------------------------
Twitter.com/deiser
Facebook.com/deiserteam
LinkedIn.com/company/deiserteam
Instagram.com/deiserteam
blog.deiser.com
www.deiser.com
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
En esta charla, nos sumergiremos en los desafíos emergentes que la inteligencia artificial (IA) y los Large Language Models (LLMs) traen al mundo de la calidad del software y el testing. Exploraremos cómo la integración, uso o diseño de modelos de IA plantean nuevos retos, incluyendo la calidad de datos y detección de sesgos, sumando la complejidad de probar algo no determinístico. Revisaremos algunas propuestas que se están llevando adelante para ajustar nuestras tareas de testing al desarrollo de este tipo de sistemas, incluyendo enfoques de pruebas automatizadas y observabilidad.
Pasado, presente y futuro del testing en LatinoaméricaFederico Toledo
En esta charla titulada "Pasado, presente y futuro del testing en Latinoamérica", exploraremos los hitos más relevantes que han moldeado nuestra comunidad de testing y calidad de software hasta el día de hoy. Nos detendremos a reflexionar sobre nuestros logros y puntos fuertes, reconociendo el valor y la importancia de lo que hemos construido juntos.
Sin embargo, comprender que nuestro pasado no determina nuestro futuro, nos invita a plantear nuevos desafíos. “Lo que nos trajo hasta aquí no nos llevará al siguiente nivel”. En esta charla, compartiré mi visión sobre en qué aspectos deberíamos enfocarnos actualmente para impulsar nuestro crecimiento tanto a nivel de comunidades como de manera individual en el campo de la calidad de software.
Analizaremos las oportunidades emergentes, las tendencias y las mejores prácticas que podrían llevarnos al próximo nivel y ampliar nuestros horizontes profesionales. Además, exploraremos cómo cada persona y comunidad puede potenciar su desarrollo y contribuir al progreso colectivo.
Acompáñame en esta charla para reflexionar sobre nuestro pasado, evaluar nuestro presente y establecer una visión clara para el futuro del testing en Latam. Juntos, podemos avanzar hacia nuevas metas y alcanzar un crecimiento sostenible en el ámbito de la calidad de software.
En esta charla, exploraremos las distintas estrategias y métodos para probar aplicaciones basadas en LLMs como GPT, el modelo de lenguaje desarrollado por OpenAI. A medida que la inteligencia artificial se integra cada vez más en nuestras vidas, es crucial garantizar la calidad, eficiencia y confiabilidad de las aplicaciones que utilizan tecnologías de AI como ChatGPT.
La charla ayudará a comprender mejor los desafíos de probar este tipo de sistemas, así como aportará algunas de las técnicas de testing aplicables, y sus limitaciones, herramientas existentes y otras que hacen falta. Esto tanto para testing funcional, automatizado y testing no funcional (performance, seguridad, accesibilidad, etc). Es importante desde ya reflexionar sobre cómo enfrentarse a estos nuevos desafíos, considerando que por más que hoy no estén probando ya este tipo de aplicaciones, no faltará mucho tiempo para que eso suceda.
1. Agile 101: La Germinación: Introducción a la Agilidad
2. Agenda
3. Love is in the air: El proyecto ideal con metodología Waterfall
4. Waterfall
5. Love is in the air: El cliente. El mismo está contento porque se ha podido comunicar sus ideas y sus expectativas se han cumplido. No se han generado delays ni ha perdido dinero. Se fortalece la confianza con el equipo y conjuntamente enfrentan cualquier desafío de forma alineada.
6. Love is in the air: El Equipo. Los mismos tienen buena comunicación, se encuentran motivados, la documentación no representa un blocker y el equipo tiene todo el material y las skills necesarias para desarrollar el producto solicitado.
7. Love is in the air: El producto: el producto es exactamente lo que el cliente quería y había visualizado.
8. Cortemos con la Dulzura.
9. Cortemos con la Dulzura - El cliente.
10. Cortemos con la Dulzura - La comunicación.
11. Cortemos con la Dulzura - El equipo.
12. Cortemos con la Dulzura - El equipo: Vacaciones por favor!
13. Cortemos con la Dulzura - El producto.
14. Do things right vs. Do the right thing
15. Mafalda.
16. Waterfall
17. Lo que nadie dice de Waterfall.
18. Waterfall Sum Up
19. ¿Porque nadie me lo dijo antes?
20. ¿Porque repetimos la historia?
21. Problemas que nos llevan a repetir la historia.
22. Germinando.. la filosofía Agile
23. El factor humano.. Toyota el gran referente.
24. El factor Humano - La motivación
25. Trípode y balance: Productividad - Calidad - Felicidad
26. Gestión y Visión de la Complejidad
27. ¿ Que es Agile ?
28. El Manifiesto Agile
29. La Esencia Ágil
30. Entrada en calor: Requerimiento Ágil
31. Los Principios Ágiles
32. Métodologías Ágiles
33. Eres Ágil? https://www.versionone.com/agile-101/agile-development-quiz/
34. https://www.versionone.com/agile-101/agile-development-quiz/
35. Gracias.
[DEISER Day Conferences] "DevOps en DEISER" - David García & Carlos Fernández Deiser
"DevOps en DEISER: En producción 10 veces más rápido con Atlassian"
Dos miembros del DEISER Team presentaron en detalle cómo hemos simplificado los tiempos de producción del equipo de desarrollo gracias al uso correcto de las herramientas Atlassian y algunas automatizaciones personalizadas.
Asiste al DEISER Enterprise Madrid 2018, el próximo 14 y 15 de noviembre; suscríbete al newsletter oficial para obtener toda la información que buscas - https://deiser-enterprise-day.deiser.com/
-------------------------------------------------------------------------------------
Twitter.com/deiser
Facebook.com/deiserteam
LinkedIn.com/company/deiserteam
Instagram.com/deiserteam
blog.deiser.com
www.deiser.com
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
En esta charla, nos sumergiremos en los desafíos emergentes que la inteligencia artificial (IA) y los Large Language Models (LLMs) traen al mundo de la calidad del software y el testing. Exploraremos cómo la integración, uso o diseño de modelos de IA plantean nuevos retos, incluyendo la calidad de datos y detección de sesgos, sumando la complejidad de probar algo no determinístico. Revisaremos algunas propuestas que se están llevando adelante para ajustar nuestras tareas de testing al desarrollo de este tipo de sistemas, incluyendo enfoques de pruebas automatizadas y observabilidad.
Pasado, presente y futuro del testing en LatinoaméricaFederico Toledo
En esta charla titulada "Pasado, presente y futuro del testing en Latinoamérica", exploraremos los hitos más relevantes que han moldeado nuestra comunidad de testing y calidad de software hasta el día de hoy. Nos detendremos a reflexionar sobre nuestros logros y puntos fuertes, reconociendo el valor y la importancia de lo que hemos construido juntos.
Sin embargo, comprender que nuestro pasado no determina nuestro futuro, nos invita a plantear nuevos desafíos. “Lo que nos trajo hasta aquí no nos llevará al siguiente nivel”. En esta charla, compartiré mi visión sobre en qué aspectos deberíamos enfocarnos actualmente para impulsar nuestro crecimiento tanto a nivel de comunidades como de manera individual en el campo de la calidad de software.
Analizaremos las oportunidades emergentes, las tendencias y las mejores prácticas que podrían llevarnos al próximo nivel y ampliar nuestros horizontes profesionales. Además, exploraremos cómo cada persona y comunidad puede potenciar su desarrollo y contribuir al progreso colectivo.
Acompáñame en esta charla para reflexionar sobre nuestro pasado, evaluar nuestro presente y establecer una visión clara para el futuro del testing en Latam. Juntos, podemos avanzar hacia nuevas metas y alcanzar un crecimiento sostenible en el ámbito de la calidad de software.
En esta charla, exploraremos las distintas estrategias y métodos para probar aplicaciones basadas en LLMs como GPT, el modelo de lenguaje desarrollado por OpenAI. A medida que la inteligencia artificial se integra cada vez más en nuestras vidas, es crucial garantizar la calidad, eficiencia y confiabilidad de las aplicaciones que utilizan tecnologías de AI como ChatGPT.
La charla ayudará a comprender mejor los desafíos de probar este tipo de sistemas, así como aportará algunas de las técnicas de testing aplicables, y sus limitaciones, herramientas existentes y otras que hacen falta. Esto tanto para testing funcional, automatizado y testing no funcional (performance, seguridad, accesibilidad, etc). Es importante desde ya reflexionar sobre cómo enfrentarse a estos nuevos desafíos, considerando que por más que hoy no estén probando ya este tipo de aplicaciones, no faltará mucho tiempo para que eso suceda.
QA or the Highway - Extra-functional testing, improve how you observe the sys...Federico Toledo
We typically distinguish between functional and non-functional testing, which might mislead to under prioritize some important aspects of the quality of the application we are testing. In many cases when the system is not secure, performant or accessible, its functionality is affected or it’s not functional at all. In this talk, I will show techniques and tools that we use that will help you improve your ability to observe the system while you are performing functional testing in order to provide feedback about the so-called “non-functional” properties. I will also discuss how to properly prioritize the different characteristics of the system in order to focus your efforts on what is more important to your business at each moment.
Pruebas extra-funcionales, más observabilidad durante tus pruebas funcionalesFederico Toledo
Normalmente distinguimos entre pruebas funcionales y no funcionales, lo que puede llevar a subestimar algunos aspectos importantes de la calidad de la aplicación que estamos probando. En muchos casos, cuando el sistema no es seguro, eficiente o accesible, su funcionalidad se ve afectada o simplemente no es funcional en absoluto. En esta charla, mostraré técnicas y herramientas que podemos utilizar para mejorar nuestra capacidad de observar el sistema al realizar pruebas funcionales para también dar feedback sobre las mal llamadas "características no funcionales".
Anyone can do testing, but only good and motivated testers can do great testing. The mindset of a tester is different from that of anyone else in a software development team, and so are their motivating factors. There are special difficulties to confront in our undervalued field that we must be aware of if we want to keep the motivation of our testers high. In order to help testers grow, we must take proper care. I started out as a tester, led a team of testers, and now, I am leading test leaders. I want to share my experiences and the lessons my fellow team leaders and I have learned during these years. You will get some food for thought and ideas about how you lead and take care of your testers. This knowledge enhances your goal of helping your testers grow and be happy, motivated, realized, and do better testing.
Low code for test automation, state of the artFederico Toledo
Abstract:
It’s kind of difficult to distinguish if this is another marketing-created buzzword in the software development world, and even worse because it appears in many flavors: “low code”, “no code”, “codeless”, “scriptless”, and probably I’m missing some. If you try to find some objective opinion it’s hard to find any article or talk that is not provided by a vendor.
In this talk I want to give my perspective and experience, analyzing when it makes sense, in which contexts, and most importantly, which considerations we should have to take into account to avoid the “automating chaos brings faster chaos”. Also, how does this ML and AI really help to your testing goals?
I’ve been researching about the different low code solutions for test automation. My team has been using some of them in different contexts. We’ve seen that, if correctly used, is an interesting approach, especially now that it’s being harder to find people with coding skills to work on test automation.
If you join me in this conversation you will learn about:
- some bad practices that can lead to useless results, so you want to avoid, related to how these tools work with selectors, modularization, etc.
- some practices that’s been useful for us, to get the results we expected and even faster, like how to structure the team and distribute responsibilities, how to integrate them in your ci-pipelines, etc.
- and also how we’ve been using some of these tools to help our team members to grow, defining a new career path for test engineers, that in other ways wouldn’t have been possible or would have taken much longer.
¿Qué hacer ante la falta de personal calificado en IT?Federico Toledo
No hay suficientes personas con experiencia para la demanda actual en el rubro del software. La pandemia aceleró los procesos de digitalización en muchas áreas. Se calcula que faltan llenar 40M de posiciones en la industria tech en todo el mundo. En Uruguay en el 2021 quedaron más de 5000 puestos sin cubrir. Según un estudio de Manpower Group casi el 70% de las empresas ya tienen problemas para conseguir el personal que necesitan. ¿Qué podemos hacer? Las empresas siguen distintos enfoques, desde buscar cómo ser más competitivos a nivel salarial y de beneficios, abrir oficinas o contratar remoto en otros países, o formar el talento que les falta. En esta charla queremos compartir nuestra experiencia en Abstracta siguiendo la línea de formar personas sin experiencia, ya que esto es una forma de resolver otro problema, que es que más de 900 personas egresadas de Jóvenes a Programar (más otras de otras propuestas de formación) están buscando trabajo sin encontrar. Armamos una propuesta que luego de varias iteraciones, ahora la estamos llevando a hacerla crecer a escala. Queremos compartir nuestros aprendizajes, pero también generar un espacio donde todos podamos compartir los desafíos y los enfoques con los que cada uno está intentando encarar el problema, para así salir todos más fortalecidos y con ideas para poner en práctica.
TSQA - Improving test automation code and strategyFederico Toledo
Talk in TSQA 2022 - Matías Fornara and Federico Toledo
Automation has gone from optional to mandatory in the past few years when it comes to developing software at speed. It has led teams and especially testers to adapt and evolve together with new technologies for coping with the automation needs.
No matter the original motivation, you might have somehow ended up crafting a strategy for doing test automation.
Now the question is, how did it mature? When was the last time you actually took a moment to do a little retrospective regarding your automation strategy? More so, when was the last time that someone reviewed the scripts themselves?
We will share our experience reviewing the test strategy of multiple projects and teams, paying special attention to the quality of our automation efforts. By doing this we will try to show you how every detail counts, since asking the right questions at the right time, validating the way we are picking our selectors, making sure there is proper communication between the automators and the rest of the team, to taking a step back when it is necessary, to assess the current situation and how could be improved if it could be or changed towards a different direction.
Qué difícil es reportar, comunicar en forma escrita, documentar, dejar grabado en piedra (o en bits) lo que pienso. ¿Cómo evitar la ambigüedad? ¿Cómo no ser duro? ¿Quién no ha tenido problemas por algo que escribió de una forma que la persona que lo leyó lo interpretó de forma distinta a lo que queríamos? En esta charla quiero dar ejemplos de problemas típicos y de algunas posibles soluciones, algunas ideas que a mí me han funcionado. Lo que más me interesa es generar discusión e intercambio de ideas para que entre todos nos ayudemos a mejorar este aspecto que es tan clave en la vida de todo y toda tester
Testing Day Bolivia - Formar testers desde ceroFederico Toledo
En esta charla compartimos nuestros aprendizajes formando testers desde cero. Hace años que venimos contratando personas sin experiencia, pero en 2021 experimentamos con un programa de pasantías que contratamos a 10 personas y las formamos de cero en testing y testing automatizado. La experiencia salió muy bien y queremos compartir lo aprendido para que más personas puedan ponerlo en práctica.
Low Code Test Automation - Jornadas de Ingeniería de Software 2021Federico Toledo
En esta charla que dimos con Danny Gutiérrez conversamos sobre un enfoque relacionado a la automatización de pruebas, que está ganando más relevancia últimamente en la industria, en particular porque han aparecido muchas herramientas siguiendo este enfoque, y cada vez con más adopción: low code para test automation (también conocido como scriptless o codeless)
La charla que les traigo hoy la titulé “los errores del 2020” pero a esta altura ya tendría que llamarse “2020 y 2021”, ya que la idea era poner foco a los desafíos que tenemos trabajando en este contexto que nos trajo la pandemia. De un día a otro todos nos tuvimos que ir a trabajar desde nuestras casas. Somos privilegiados de poder hacerlo. Pero algo que noté es que hay equipos a los que les fue más fácil adaptarse que a otros. Hablo de nuestros equipos trabajando para distintos clientes en Uruguay y Estados Unidos y otros, pero también viendo empresas amigas, clientes, etc.
Además de compartirles mi análisis, quisiera que puedan llevarse de esta charla algunas ideas para seguir adaptándonos a esta realidad que tenemos de cara a futuro, para que como testers podamos seguir cumpliendo nuestros objetivos, aportando nuestro valor a la calidad de software, y disfrutando de nuestro trabajo.
¿Cómo mejorar la calidad de tu automatización?Federico Toledo
Charla dada en Mendoza Testing Days 2021, por Matías Fornara y Federico Toledo, de Abstracta (www.abstracta.us)
Abstract: La automatización pasó de ser algo opcional a algo obligatorio en los últimos años si queremos liberar versiones a la velocidad que lo requiere el mercado. Ha llevado a los equipos, y en especial a los testers, a adaptarse y evolucionar junto a las tecnologías para estar a la altura de las necesidades de automatización.
En muchos equipos se comienza con algo, a veces por falta de manos suficientes para testing o por iniciativa de unos pocos, pero de alguna manera quizá sin pensarlo demasiado, se llega a crear un framework y se sigue más o menos una estrategia para automatizar.
Las preguntas que tocan hacer al tiempo son: ¿cómo eso se convirtió en el monstruito que es ahora? ¿Fue evolucionando de manera adecuada junto a las necesidades del proyecto? ¿Aún colabora con la velocidad de entrega y optimización del proceso de desarrollo?
En esta charla vamos a compartir nuestra experiencia “asegurando la calidad” de la automatización en los diferentes proyectos y equipos en los que trabajamos al mismo tiempo. Al hacer esto mostraremos cómo cada pequeño detalle cuenta, desde qué preguntas hacer, cómo validar desde la arquitectura hasta los selectores que usamos, revisando la comunicación entre los automatizadores y el resto del equipo tanto para la definición de qué automatizar como hasta el reporte de resultados. Por último y no menos importante, veremos cómo levantar la mirada y analizar la estrategia general para buscar cómo mejorarla o incluso cambiarla de dirección.
Shift left and shift right performance testingFederico Toledo
“Es mejor que empieces el testing desde el comienzo”. Esta frase se ha repetido tantas veces últimamente gracias al auge y relevancia de las metodologías ágiles, que (por suerte) remarcan la importancia que tienen las pruebas en el proceso de desarrollo. ¿Cuál es la mejor forma de enfocar el esfuerzo en testing cuando hablamos de pruebas de performance? ¿Deberíamos comenzar desde el comienzo del desarrollo, acompañándolo, de acuerdo a lo planteado por las metodologías ágiles, o deberíamos seguir con un enfoque del tipo waterfall? ¿Después de liberar el sistema a producción ahí ya dejamos de preocuparnos por las pruebas, ya perdimos nuestra última chance? Si alguien de la audiencia está pensando sobre pruebas de performance y tiene que decidir cómo enfocar sus esfuerzos, en esta presentación compartiremos las estrategias conocidas como shift left testing y shift right testing aplicadas a las pruebas de performance, cómo son ambos enfoques basándonos en proyectos reales, pudiendo así entender mejor cada uno.
Sesión de preguntas y respuestas que estuve cubriendo en el webinar hecho con Reconvertite.
https://www.youtube.com/watch?v=kyV4Pc1FZHc&feature=youtu.be
Webinar organizado por Angular Montevideo.
Abstract: En épocas de crisis uno busca optimizar costos, hacer lo mismo a menor costo o sacarle más provecho a lo que ya está invirtiendo. Es así como quizá muchos están revisando las licencias que están pagando en herramientas de software, buscando como alternativa a que herramienta open source migrar. En esta charla les quiero compartir mi experiencia trabajando con herramientas open source de testing, tanto para pruebas funcionales, automatizadas y de performance. Para esto veremos desde qué alternativas hay en el mundo open source, cómo elegir las herramientas más apropiadas para nuestro contexto y cómo migrar lo que ya tenemos.
Webinar: Estrategias para optimizar los costos de testingFederico Toledo
Webinar en colaboración de QAminds y Abstracta Tech Talks.
Abstract: En estos días de lockdown y recesión económica muchas empresas están buscando formas de recortar costos por acá y por allá, y por supuesto, el testing es de las cosas que se suele recortar primero. El problema de recortar presupuesto y recursos para testing queda reflejado en el viejo dicho "pan para hoy hambre para mañana". En esta charla quiero compartir algunas estrategias con las que puedes optimizar costos de testing sin comprometer la calidad del sistema o producto que estás desarrollando.
Cómo revisar tu estrategia de pruebas? Meetup de QA & Testing en ChileFederico Toledo
https://www.meetup.com/QA-Testing-Chile/events/268432334/
Al trabajar asesorando diferentes organizaciones es posible ver que las estrategias de testing no siempre están completas, no son las más adecuadas o quizá funcionaban bien al momento en que se establecieron, pero como no se revisaron y no se ajustaron entonces están obsoletas.
En esta charla Federico Toledo, COO Abstracta, comentará con los asistentes acerca de dos grandes aspectos para resolver los problemas mencionados:
1. Cómo revisar la estrategia de pruebas de forma sistemática y cubriendo las distintas áreas de calidad que son de interés para cada contexto.
2. Cómo los testers pueden capacitarse en estas metodologías, pudiendo tener un background general sobre diversas áreas de calidad para así poder identificar riesgos y disparar acciones cuando haga falta.
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
8. EL CAMBIO GRANDE, ES EMPEZAR A
PENSAR EN TODO EL PROCESO DE VIDA
DE UNA APLICACIÓN, EN VEZ DE
OPTIMIZAR POR PARTES.
SE MEJORA EN PRODUCTIVIDAD Y
CALIDAD.
ENRIQUE ALMEIDA
NO SE TRATA DE IR MÁS RÁPIDO, SINO QUE
SE TRATA DE HACER OTRAS PREGUNTAS.
KAREN JOHNSON
25. LINKS INTERESANTES
• Engines de Integración Continua:
• Jenkins https://jenkins.io/
• Cruise Control .Net http://www.cruisecontrolnet.org/
• GeneXus Server
• http://gxserver.com/
• MSbuild tasks para GeneXus
• https://wiki.genexus.com/commwiki/servlet/wiki?3908,MSBuild+Tasks,
• GXunit
• https://www.federico-toledo.com/gxunit-renace-nuevamente/
• http://ealmeida.blogspot.com.uy/2017/09/renovado-interes-en-gxunit.html
• Metodología:
• https://www.federico-toledo.com/continuous-delivery-en-genexus/
• Grupo BuildAndDeploy
https://wiki.genexus.com/commwiki/servlet/wiki?24343,Category%3ABuildAndDeploy,
Notas del editor
https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus
Abstract:
DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad.
Descripción:
La productividad no solo se trata de cuán rápido “codificamos”. Cada vez hay más herramientas y metodologías que nos hacen más productivos (produciendo con calidad y velocidad). Tenemos contenedores, pipelines, herramientas para realizar chequeos de calidad a distintos niveles, monitorización de punta a punta, etc. Por eso, para seguir manteniendo la ventaja competitiva que tenemos gracias a usar GeneXus, es necesario ver y entender qué se puede tomar del resto de herramientas y metodologías, ya sean ágiles, DevOps, para Continuous Delivery, etc. En esta charla haremos un resumen de las prácticas actuales de CI/CD y DevOps de la industria, y que cosas se pueden ir haciendo en GeneXus desde ya para empezar a transicionar hacia este nuevo enfoque y obtener lo mejor de ambos mundos.
DevOps es la nueva moda. Seguro que escucharon hablar de esto y por eso están acá.
Si uno se pone a leer de qué se trata, a primera vista parece otro sabor de todo esto de las metodologias agiles, lean y afines?
Yo creo que es una metodología alineada con todo esto, con agile, etc., pero en algunos aspectos es poco más amplio, DevOps mira al software como un todo… y en particular trata de unir dos cosas que estan historicamente separadas … la construccion del software (el desarrollo) y la operacion del mismo (y de ahí viene el nombre, ya que DEVOPS se forma con la conjunción de dos palabras, devs y ops, developers and operations, dos mundos entre los cuales se sabe que agregan valor, que los necesitamos, pero que entre ellos se dice que hay mucha rivalidad, mucha fricción.
Esto es porque hay un “conflicto de intereses”. Los desarrolladores por un lado quieren poner en producción todas las semanas, con todo esto de Scrum, iterativo incremental, quiero poner las features en producción y validar con el cliente. Y por el otro lado los de operaciones están con la filosofía que si funciona no lo toques. Mientras más veces ponés en producción más laburo me das, y más riesgo, porque si hay problemas los usuarios se van a quejar primero que nada conmigo, por más que el problema sea del software.
Y en realidad en toda esta historia de la construcción del software la fricción se da en más puntos….
Y en este sentido me gusta lo que plantea Katrina Clokie en su libro.
Ella dice que fue genial que en las metodologías ágiles se comienza a hablar de formar un único equipo, más horizontal, todos compartiendo responsabilidad, sin necesidad de distinguir roles. Desarrolladores, managers, diseñadores, testers, todos somos parte del equipo, compartimos resonsabilidad, estamos al mismo nivel.
El tema es que acá el desarrollo termina cuando se pasa el paquete a la gente de operaciones, pasamos la tarjeta a DONE, y vamos con la que sigue, el problema es de otro.
Katrina plantea que DevOps es una evolución de Agile, en el sentido que se plantea involucrar a otros equipos. Lo más importante es generar conversaciones, repartir responsabilidades, involucrar a la gente, que se reparta el conocimiento, que se generen preguntas, retroalimentación. Loops de feedback por todas partes. Mucha comunicación.
Punto b: La cultura DevOps implica tener las conversaciones adecuadas en los momentos oportunos. Para esto tenemos aspectos metodológicos y de herramientas que nos pueden ayudar en este sentido.
En esta charla queremos hablar de herramientas y metodologías para propiciar una cultura DevOps, y analizar qué tan bien o mal estamos los que trabajamos con GeneXus. O sea, es algo inalcanzable? O es algo que tenemos relativamente a la mano?
Claves en DevOps
Ciclos Cortos para aprender rapido… que son soportados por:
Metodologia
Herramientas
Conversaciones / Interaccion.
En este ciclo hay que automatizar todo lo automatizable porque temenos que liberar tiempo para estas interacciones.. Para analizar la informacion que recibimos de feedback e implementar los cambios necearios…
Y es por eso que me gusta esta imagen, es la que se usa para representar el concepto de devops típicamente.
Se ve como lo más importante es obtener feedback continuo. Todo rodeado de comunicación en tiempo real. También aparece el concepto de CONTINUOUS INTEGRATION, que seguramente habrán escuchado hablar. Continuous integration, continuous delivery, continuous deployment. Si bien en un par de horas, acá mismo, con Fabián daremos una charla de continuous delivery en GeneXus, en esta charla para hablar de DevOps es necesario hablar un poco de continuous delivery, ya que es muy complicado de tener una cultura DevOps sin tener una base sólida en metodologías y herramientas que apoyen el enfoque.
En el mismo artículo de donde saqué esta imagen cuentan que los equipos que aplican DevOps despliegan más frecuente, pero además, con mayor calidad. Y quizá más importante, cuando hay un error se recuperan mucho más rápido. Esto es gracias a tener todo aceitado y a tener ciclos de feedback, levanter información de todo el proceso de desarrollo.
Y un concepto importante en todo esto es el de PIPELINE
Pipeline en inglés es tubería. Es una metáfora que ya se usa en Linux para refierse a una cadena de tareas organizadas de forma tal que la salida de uno sea la entrada del siguiente.
En Continuous Delivery usamos esta metáfora para visualizar la creacion y entrega de software como un flujo constante. Una vez que algo entra en el pipeline va ‘hacia adelante’ y si hay algún problema en el camino, este es reportado hacia el origen y Vuelve a comenzar. Pero de todos modos el flujo es siempre en un sentido… si entra algo que rompe un build, se corta el flujo y luego entra otra cosa que lo arregla.
Lo que se intenta es proteger la salida del pipeline. Puede haber problemas a lo largo del recorrido pero la idea es atajarlos antes d eque lleguen a la salida :)
Toda esta idea del pipeline es para generar conversaciones adecuadas en momentos oportunos, ciclos de feedback, etc., pero solo tiene sentido, solo es implementable y sostenible si la armamos sobre una base de herramientas y automatismos que permitan aceitar el proceso, sistematizarlo, mecanizarlo.
VEO MUY DIFÍCIL HACER DEVOPS SIN CONTINUOUS DELIVERY
Relacionado a esto quiero hacer dos citas. Una es esta frase de Enrique, que hace unos días me comentó algo así en un mail que intercambiamos y para mí dice mucho sobre lo que es la cultura Devops. Hay que pensar en optimizer todo el proceso, y no solo las pequeñas partes.
Por otro lado, hace poco escuché a Karen Johnson decir en un podcast que no se trata de ir más rápido, o de entregar más seguido… se trata de hacer otras preguntas. Y es impresionante las preguntas que se generan alrededor del pipeline. Porque el pipeline es algo que pertenece a todos, y todos somos responsables por optimizarlo.
En este sentido algo que me ha pasado mucho en el útlimo tiempo trabajando para equipos en Estados Unidos, pero también con muchos acá en Uruguay, es que yo, en mi rol de tester, participo en decisiones relacionadas al proceso de desarrollo, a la forma en la que se hacen los branches, al armado de ambientes, en un montón de cosas que no son puramente de pruebas.
Esto es lo que a uno lo hace sentir parte de un mismo equipo. No somos el enemigo, no estamos en un equipo aparte que tiene una mission completamente opuesta o incluso contradictoria. No!!
Entonces, entre todos temenos que pensar cuál es la major forma de trabajar, optimizer el proceso como una misma cosa, y no solo optimizer el desarrollo, optimizer el testing.
Esta imagen la tomé de un artículo. El mayordomo que está en el medio es clave. Pero ojo, es el logo de Jenkins, pero no es la única opción. Generalmente se necesita una herramienta que permita definer los pipelines de los que hablábamos. Estas se las conoce como herramientas de integración continua, o continuous integration engines. Jenkins es un ejemplo, temenos Bamboo, TeamCity, Travis, GoCD, etc.
Miren el millón de herramientas que hay por ahí`, todas nos dan beneficios de productividad
Las están aprovechando? No? eso no les hace pesnar algo?
Acá se puede observar uno de los Fuertes de la cultura devops, integrar herramientas, integrar chequeos, buscar feedback con herramientas que hay por ahí. Jenkins y este tipo de herramientas permiten integrar esto y orquestarlo.
Pero esto no termina acá. NOOO.
Porque hasta acá fue el pipeline de continuous integration y continuous delivery. Si queremos pensar en devops, no Podemos terminar cuando pusimos el product en producción, sino que temenos que integrar en nuestro proceso a la operación del product. Entonces temenos que pensar en otras herramientas como las que nos permiten hacer un seguimiento de la aplicación cuando está en producción, como las herramientas para analytics, para monitorización, para analizar logs.
Y lo mismo antes del proceso, temenos que pensar en todas las herramientas que hay para la parte del diseño, para gestionar y compartir el análisis de los requerimientos, para gestionar el Proyecto y así ir seleccionando qué funcionalidades le vamos a dar en qué orden al usuario.
Es parte de todo lo que entra en ese proceso que temenos que optimizer. No solo optimizer el desarrollo, optimizer el todo. Y esto es muy importante, porque tal vez desde desarrollo temenos que hacer algo extra para que en producción sea todo mucho más fácil de controlar y monitorizar, entonces tal vez a costo de desarrollo aumentamos la productividad de todo el ciclo de vida. O con ciertos ajustes Podemos hacer que las pruebas sean más fáciles, o con ciertos ambientes facilitamos la ejecución de otras cosas…
Optimizar las partes, pero también optimizer el todo. Claramente esto se logra si el diseño del pipeline lo hacemos involucrando a todas las áreas.
Yo aca decidi arrancar con una slide en blanco porque en la anterior habia mucha cosa
Lo que me quedo claro es que hay un mundo de herramientas y de gente trabajando en mejorar la forma en que hacemos software y nosotros Tambien Podemos hacerlo.
Ya sea poque nos parece que esta bueno
Ya sea que uno se acerque a esto de devops por mantener una ventaja competitive – desarrollamos mas rapido, temenos que lograr al menos en el resto ser igual – o ya sea que uno se acerque porque le parece que es una Buena forma de trabajar
Si queremos armar un pipeline de ese estilo hoy por hoy, podemos. De hecho esto es un ejemplo de uno que armo la gente de Abstracta – y si les interesa concer de esa experiencia los invitamos a la charla que van a dar al respect.
Y dado que se puede trabajar de este modo, nos parecio interesante conversar de que nos exige y que nos aporta a nosotros desarrolladores trabajar en un marco de devops
Para trabajar en un mundo de devops, lo primero que necesitamos es tener integracion continua.
Eso implica el GXServer y un motor de integracion continua – el de la foto es Jenkins pero puede ser Cruise Control o cualquier otro.
Esto es automatizar el proceso desde un commit hasta la actualizacion de la KB del Consolidado.
Que nos cambia esto a nosotros? Mas alla de que automatizarlo igual libera el tiempo de alguno?
Bueno, que tener visualizacion del estado del build nos ahorra muchos dolores de Cabeza.
Cuantas veces les Habra pasado que se actualizan el del server y resulta que ahora no especifica o no compila por un cambio que subio algun otro? Y despues quiza cada uno lo intent arreglar y subio su cambio y se genera mucho ma conflict.
Con un motor de CI Podemos ver antes de actualizar si el build esta ok o si esta roto, y evitar actualizarnos si esta mal.
Y tambien en vez de hacer un commit y me voy a casa, ahora igual espero un poquito mas para ver como quedo el build y quiza dejar el problema arreglado antes de irme.
En un mundo devops al desarrollar una funcionalidad tambien desarrollamos la forma e validarla..
Es uno de los elementos criticos de feedback del pipeline. Necesitamos saber a medida que integramos nuestro codigo si el miso funciona como esperamos y Tambien si no rompe ninguno de las pruebas que habia.. Y si lo hace necesitamos saberlo temprano… es decir, para poder tener esos caminos de feedback las pruebas tienen que poder corer cada vez que integramos y para eso tiene que haber pruebas automaticas.
Eso no quiere decir que salgamos a automatizar todo, de hecho de tener al tester mas cerca es que nos puede ayudar a pensar que automatizar y que no, e incluso a disenhar estas pruebas, siempre teniendo en cuenta esto de la piramide de retorno que nos dice que la mayoria de la automatizacion deberia ser a nivel unitario.
Una personal es que cuando hacemos tests unitarios, programamos mejor. Si queremos hacer test unitario vamos a tener que identificar y aislar mas esa unidades… por poner un ejemplo burdo si yo tengo que programar algo como un login, yo podría tener un webapanel donde leo las variables de pantalla y en el evento ‘enter’ tengo un for each a la tabla de usuarios … eso seguro funciona pero es caro de testear, solo puedo hacerlo en la pantalla. Si quiero hacer una prueba unitaria necesito separar esta funcionalidad en 2 objetos, una pantalla donde solo se leen las variables y luego se llama a un procedimiento que hace la validacion. Esto es mejor porque separo la lógica de la interfaz y tengo algo que potencialmente puedo reusar manhana si necesito hacer un login como webservice o que se yo. En definitiva al hacer el código mas testeable termine con una solución técnicamente mejor.
Que tenemos para poder automatizar nuestas pruebas unitarias? GxUnit… Ahora mismo es un proyecto opensource y este anho se trabajo en hacerlo mas fácil de adoptar, Se mejoro la visualización de los resultados de las pruebas en el IDE de GeneXus,
Y también se genero salida que puede ser integraa en Jenkins o Cruise-Control para poder ejecutar las pruebas en el pipeline.
Un tema no menor a la hora de armar pruebas unitarias es el tema de los datos – no solo por el tema de preparar los datos , sino porque las pruebas que van a la base de datos son a veces lentas, y entonces no es posible ejecutar toda la batería de pruebas que tenemos en cada integración… La buena noticia al respecto de eto es que la gente de Abstracta va a estar trabajando con GeneXus para definir una forma de poder realizar ‘mockeo’ de datos lo cual va a hacer más corto el ciclo de tests
De todas formas no hay porque esperar a esto, ya se puede usar y sacarle jugo a GxUnit
Pero no alcanza con solo pruebas unitarias y por eso esta GxTest. Otra buena notica es que va a existir un GxTest para el desarrollador, y que podamos programar las pruebas desde GeneXus.
Esto no esta disponible aun… y pueden saber mas hablando con algún Abstractero.
Esto y el tema de la simulación de los datos nos va a dar una gran potencia para armar nuestros tests a la hora de desarrollar, incluso programar tests de interfaz es igual de sencillo que programar pruebas unitarias… la pirámide se mantiene poque son mas caras de ejecutar pero van a ser igual de barato de programar.
Lo primero es trabajar en nuestrs soft-skills porque ahora hay que tener capacidad de integrar diferentes visions a la hora de de construir la solucion.
No solo pensar en resolver un requerimiento de un usuario sino hacerlo de forma mas usable, mas testeable, mas facil de monitorear, etc.
Pero no solo en las soft skills sino Tambien las practicas tecnicas
Hay mucho mas para hablar, muchas herramientas que existen y se pueden adaptar para conectadas al pipeline y muchas herramientas que Podemos incoporar asi como estan – validadores tipo el kbdoctor o el security scanner, genexus esta trabajando por integrar docker… en fin hay mucha cosa que existe y mucha cosa sucediendo…. Lo Bueno de esto es que se puede construer de forma incremental.
Capaz que otras tecnologias si quieren manhana armar un pipeline lo tienen un poco mas facil, mas documentado y con mas herramientas integradas en su proceso de desarrollo… pero nosotros temenos suficientes para arrancar y nos gustaría invitarlos a experimentar con las herramientas que hay, quizá incoporar alguna nueva, compartir esas experiencias y en definitiva a a que colaboremos mejorar juntos nuestros procesos y herramientas.
O siguiendo el slogan del evento: Involucrate, Dale Forma a nuestro Futuro
https://www5.genexus.com/meeting2017/gx27.speakers.aspx#es/DevOps-y-GeneXus
Abstract:
DevOps y Continuos Integration/Continuos Delivery plantean muchos desafíos y muchas cosas para aprender, pero a su vez un montón de oportunidades que ya podemos comenzar a aprovechar con GeneXus. Veremos en esta charla métodos y herramientas que aumentan la productividad en todo el ciclo de vida de un producto, pudiendo así acercarse a una cultura de DevOps donde se entrega valor al usuario de manera frecuente y con calidad.
Descripción:
La productividad no solo se trata de cuán rápido “codificamos”. Cada vez hay más herramientas y metodologías que nos hacen más productivos (produciendo con calidad y velocidad). Tenemos contenedores, pipelines, herramientas para realizar chequeos de calidad a distintos niveles, monitorización de punta a punta, etc. Por eso, para seguir manteniendo la ventaja competitiva que tenemos gracias a usar GeneXus, es necesario ver y entender qué se puede tomar del resto de herramientas y metodologías, ya sean ágiles, DevOps, para Continuous Delivery, etc. En esta charla haremos un resumen de las prácticas actuales de CI/CD y DevOps de la industria, y que cosas se pueden ir haciendo en GeneXus desde ya para empezar a transicionar hacia este nuevo enfoque y obtener lo mejor de ambos mundos.