Webinars

Alan Page and Brent Jensen have designed a set of principles that to help guide teams with testing initiatives. This session will dive into those principles and what they mean for and how they can be applied as teams switch gears to incorporate a continuous integration and delivery pipeline.

Have you said to yourself “I’m not technical enough to join that discussion”, or perhaps said to someone else “This will be too technical for you – don’t worry about joining.”

It is these types of biases that make team members miss important nuances that can lead to a better implementation of a story or feature. Meetings to talk about system architecture, code design, data structure design, the technical implementation of a new feature, or other topics that are seen as “technical”, may exclude “non-technical” team members. That means leaving out people with diverse perspectives who may have ideas and ask questions nobody else would think of. Janet shares tips on how to make this type of conversation happen and include all the right people – including the ones that some perceive to not be “technical enough”. In this talk you’ll have the opportunity to try some of these techniques to help you contribute to a technical discussion or enable “non-technical” team members to contribute effectively.

Learning Objectives:

•  Identify good ways to transfer skills across roles
• Become familiar with the tools and terminology used by other roles so you can collaborate comfortably
• Promote the whole-team approach to building a quality culture

The exponential growth of digital technology has resulted in products and services that far surpass our human cognitive capabilities. Industry has historically attempted to bridge this gap by forcing people to adapt to the needs of the technology. Modern UX addresses this issue by hiding complexity behind simple, easy-to-use interfaces. While our approach has improved usability and usefulness, it has had the unintended consequence of making it more difficult for people to understand their technology. I argue that this needs to be the defining issue of our profession right now. It’s time for UX to take a broader view of our responsibilities and move beyond simply helping people use their technology. It’s time to start helping them understand it.

This will be an open session with Michael Bolton.
Attendees can submit their questions before the beginning of the session using the comments feature of the meetup.
It will be possible to submit new questions during the session.

We already made some questions to Michael related to the following topics:

1. Artificial Intelligence and Testing
– Which are the main differences when testing this type of algorithm?
– How will AI impact software testing? Will it help us? Is it a threat?

2. Testing in the current context (COVID-19)
– How do you release critical applications very fast?
– Which is the best approach in this context? What are the risks? How to succeed?

Finding bugs requires detective work. You look for evidence, you interrogate witnesses – and some of those might not be telling the truth! You need lateral thinking to find your perpetrator.

As testers, we often hear that the capability to think outside the box is an essential skill to have. In fact, this skill is great to have even if you’re not a tester. Thinking outside the box permits you to generate new and innovative ideas, to find bugs that nobody could think about, it can also help you find completely new ways to solve problems.

We all have unconscious biases that can limit our observational skills and creativity. In this session, we’ll discuss lateral vs. vertical thinking, and explain how our brain’s “wiring” can make thinking outside the box be difficult.

Lisa will talk about several common cognitive biases that can work against us and get in the way of effective testing. She may challenge you to try some games that promote lateral thinking, as best we can in a virtual conference! You’ll get some guidance on how to keep building up your lateral thinking “muscles”.

Ya está bien documentado en la literatura, y se ha experimentado en la práctica, que los testers tienen éxito en su trabajo cuando encuentran defectos en el software con sus casos de testing. De lo contrario, entienden que el testing puede haber sido solo una pérdida de tiempo … Estas son características que pueden parecer un poco raras para los profesionales en otras áreas, pero son completamente comprensibles en el contexto del testing.

Es por eso que, en 1979, en el libro “The Art of Software Testing”, Glenford Myers definió el testing como “el proceso de ejecutar un programa con la intención de encontrar defectos”.

Lisa Crispin y Janet Gregory, en “Agile Testing” (2009), presentan principios adicionales considerando el testing ágil, como el feedback continuo, la entrega de valor al cliente, el coraje, la simplificación y el enfoque en las personas.

Actualmente, el tema más discutido, uno de los más investigados y uno de los más controvertidos es la COVID-19, una enfermedad infecciosa y contagiosa causada por el coronavirus SARS-CoV-2, identificada inicialmente en Wuhan, China, en diciembre de 2019 y caracterizada como una pandemia por la Organización Mundial de Salud el 11 de marzo de 2020.

Con más de 7 millones de casos en todo el mundo y 400,000 muertes (situación al 8 de junio), sin vacuna o remedios específicos para su cura, la COVID-19 ha sido combatida en todo el mundo a través de campañas de salud básica y difusión de información. Difundir información hoy es relativamente fácil. Pero saber identificar, comprender y analizar la confiabilidad y veracidad de esta información está lejos de ser simple. Principalmente para el público en general, muchas veces incluido digitalmente, pero sin el conocimiento necesario para una verdadera inclusión. La situación es agravada por la difusión de información falsa, con parcialidad e incompleta.

En este seminario web, hablaremos sobre cómo se pueden usar los principios y valores de las pruebas de software para desarrollar criterios que pueden ayudar en la interpretación y el análisis de la información sobre COVID-19. También hablaremos sobre formas de difundir estos criterios para el desarrollo de estas habilidades de “tester de software” al público en general, con el objetivo de contribuir a una comprensión más general de la situación y a una inclusión digital amplia y basada en el conocimiento.

Organizations have adopted Agile, Scrum, DevOps, CI/CD practices widely in order to increase their adaptivity. While doing so, they learn that it is impossible to speed up the IT deliverance without a trust in quality. Lean and SAFe have Built in Quality as a core principle, but what does that mean for teams and organizations? In this presentation Derk-Jan will share the challenges he encounters at various organizations. How do teams work and collaborate in order to release valuable increments, and what are approaches to increase the quality awareness? We will discuss the role of tester on team level but also investigate how quality is organized scaled settings where teams need to collaborate on a single increment. How can you organize quality on release level, what types of releases can we distinguish and who is responsible? What do we see in practice and how should it work? In order to have quality build-in, we need more than just good tests. But a strategy also. Implementing this on various levels is challenging and has impact on the way we develop our software.

Take aways:
– Understand Built in quality is a multi-level challenge that is gaining importance.
– Get a feeling what roles are needed in order to organize testing in scaled agile organizations.
– How to define quality feedback loops and the impact for the development and business

In the past Olympics, we watched as Michael Phelps did something that no other Olympian had ever managed to accomplish. He won more gold medals than ever before. We spent weeks watching as he won gold medals time after time.

It’s easy for someone to imagine that athletes such as Phelps are born winners. It’s easy to think that it’s in their DNA to experience such greatness. What many fail to realize is that while Phelps showed us his master skills in swimming for a few weeks, he prepared for these events for many months and years. He spent day after day practicing, refining his techniques, modifying his strategies, and improving his results.

Being an expert tester is no different. While the art and craft of testing and being a thinking tester is something that is built within you, simply going to work every day and being a tester is not always enough. Each of us have the opportunity to become “gold medal testers” by practicing, studying, refining our skills, and building our craft.

In this presentation, we will evaluate extracurricular activities and practices that will enable you to grow from a good tester to a great tester.

Dentro de cualquier proyecto o equipo trabajo el mayor aporte valor de un tester se da cuando participa en la definición de las historias de usuario, define pruebas de aceptación previas al desarrollo, aporta ejemplos de casos de uso, realiza pruebas exploratorias, empatiza con los usuarios y propone ideas que mejoran el producto final. Todo ello requiere un proceso de aprendizaje, asimilación, comprensión y evaluación de posibilidades que finalmente se traducirá en unas pruebas a realizar sobre el sistema.

Todas las etapas enumeradas anteriormente suponen un proceso mental complejo donde intervienen tanto capacidades análiticas, memorísticas como emocionales. Es por esto, que, como seres humanos, no podemos suponer que dichas capacidades no se ven afectadas por nuestra propia percepción del mundo, experiencias pasadas, entorno, educación recibida, edad, sexo, color de piel, etc.

Es decir, como contraposición al scripting testing más puro y al checking automático es precisamente el factor humano el que aporta más valor a las pruebas, pero a su vez, los sesgos que todas las personas “arrastramos” y que forman una parte de nosotros puede que las pruebas se vean afectadas negativamente.

Existen documentados multitud de sesgos cognitivos, en la charla veremos cómo pueden afectar algunos de ellos a las pruebas y cómo mitigar sus efectos.

Las transformaciones ágiles pueden ser difíciles, caras y confusas. Los equipos son reestructurados, las personas tienen distintos roles y se espera que los “mindsets” cambien rápido.

Quizás la agilidad llegó para entregar productos más rápido para los Product Owners – ¿pero esta forma “ágil” de trabajar es de verdad así?

Quizás el equipo sigue trabajando con pequeñas cascadas, y tú como tester terminas haciendo el testing como una fase y no como una actividad. Como tester, ¿te has sentido solo o sola en un equipo? ¿Alguna vez has sentido que eres el único o única a quien le importa practicar la agilidad, o tener un “Agile Testing”? ¿Has escuchado a tu equipo decir que no hay tiempo para cambiar y mejorar? ¿Has sentido que no eres escuchado?

Acompáñame mientras cuento mi experiencia en cómo me convertí en una Agile Tester, que no sabía nada y tenía poco impacto, a ser escuchada y valorada en mi equipo y compañía. Hacer que la Agilidad funcione, especialmente hacer que Agile Testing funcione como un enfoque de equipo completo, puede ser difícil pero no imposible. Es posible ser escuchado, valorado y respetado en un equipo ágil. Aprende a asumir un papel impactante e influyente para que puedan convertirse juntos en un equipo ágil y fuerte.

¿Qué cambios hay en el proyecto de Selenium? ¿Cómo está evolucionando Selenium para seguir siendo la herramienta preferida por todos?

En esta charla Diego mostrará las cosas nuevas en el proyecto y en Selenium 4, por qué es una buena idea migrar a la nueva versión y cuáles son sus beneficios. También se discutirán temas como la nueva sintaxis W3C WebDriver, por qué existe un nuevo estándar y cómo migrar un test de JWP a W3C WebDriver.

Si bien en los tiempos que corren muchas empresas, sino ¿todas? … tienen en su día a día incorporadas las actividades de testing de software, hay sectores que desde siempre lo han tenido en cuenta y forma parte de sus procesos. Este sector agrupa un gran número de sistemas (HW/SW) y son conocidos como SCS (Safety-Critical Systems), sistemas que si fallan ponen en riesgo la vida humana, el medio ambiente o infraestructuras. Están presentes en nuestro día a día: automoción, medicina, aeroespacial, energía, transporte terrestre y marítimo entre otros.

Como testers no siempre se nos da la oportunidad de abordar proyectos en estos sectores. En esta sesión les contaré mi experiencia personal en un proyecto de tren de alta velocidad (actividades de verificación y validación) y más recientemente en el sector médico: certificación de software sanitario para uso en Europa (marcado CE de producto sanitario). Veremos normativas vigentes, el enfoque tradicional de testing y cómo están irrumpiendo los métodos ágiles en el sector.

Si te interesa conocer el testing en este tipo de proyectos, lo que hemos hecho y los desafíos que nos esperan, ¡no te pierdas esta sesión!

The Test Maturity Model integration (TMMi) has a rapidly growing uptake, and is now the de-facto world-wide standard for test process improvement. The TMMi provides detailed guidelines for assessing and improving testing capabilities of teams and organizations. It aims to support organizations around the world to improve their software and system testing practices, and to achieve higher and more sustainable levels of quality for the products that they are developing and maintaining. An overview is provided of the TMMi model and the way TMMi supports business-driven test process improvement. In addition, the latest developments around the TMMi will be discussed, e.g., TMMi & Agile and the establishment of TMMi Local Chapters. Finally the Test Improvement Manifesto that defines guidelines on how to do test improvement successfully is presented.

En este webinar Leandro nos presentará los pasos a seguir al momento de crear automatizaciones orientadas a pruebas de carga, permitiendo así evitar problemas que ocurren comúnmente debido a que muchos automatizadores desconocen los pasos necesarios para garantizar que los fallos comunes no ocurran. La audiencia entenderá cómo funcionan estas automatizaciones y la razón de tener cuidado con cada uno de estos pasos.

Blocked because the API you depend on doesn’t exist yet or isn’t completely ready? Facing trouble to test various scenarios due to lack of control over third-party APIs? Struggling to test failure cases like receiving an invalid response , 5XX errors and so on? Having flaky tests due to slow API responses?

These are some very common problems we encounter. We cannot rely on slow APIs, which provide a very narrow range of responses. So how can we test effectively in such situations? Is there any feasible solution available? Fortunately, there is: mocking of APIs.

In this session, I will explain how to stub APIs using Wiremock. With a real life example application, we’ll explore how to handle complicated scenarios and form testing strategies. Join this session to gain insights on how, when, and most importantly why we should stub APIs. Let’s find together how development and testing can benefit from mocks.

Key takeaways:
– How to test systems in isolation
– How to setup mock servers
– Why and how to stub APIs