Name: TestJS Summit 2021
Start: 2021-11-18T15:00:00.000Z
End: 2021-11-19T20:30:00.000Z

Vlad Dumitrica

Lera

Nikolay Advolodkin

Ricardo Machado

David Pugh

Robert

Oscar Pagani

Myron Davis

Norm Crandall

Simon Flack

Hannah Vivian Shaw

Aman Beg

Ian Sutherland

Rahul Rana

Christian Guy

Serge Bedzhyk

Efstathios Katomeris

Max Medina

Rishi Narang

Renata

mickael

Vitor Barbosa

Martyna Skup

Douglas Biazioli

Gerard Brull

Sachini Dissanayaka

Zain Fathoni

Jennifer Proust

Kateryna Pohrebniak

Rashini Sathsarani Gamalath

Erikson 

Michal Štrajt

Oleksandr Turevskiy

Greg Ziółkowski

Ya sea que estés probando tu UI o API, Cypress te proporciona todas las herramientas necesarias para trabajar y gestionar solicitudes de red. Esta tarea de nivel intermedio demuestra cómo usar los comandos cy.request y cy.intercept para ejecutar, espiar y simular solicitudes de red mientras pruebas tu aplicación en el navegador. Aprende cómo funcionan los comandos, así como los casos de uso para cada uno, incluyendo las mejores prácticas para probar y simular tus solicitudes de red.

Solicitudes de Red con Cypress

Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.

Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.

Network Requests with Cypress

Cecelia Martinez

The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Testing Pyramid Makes Little Sense, What We Can Use Instead

Gleb Bahmutov

Roman Sandler

Los desarrolladores quieren dormir tranquilos sabiendo que no rompieron la producción. Las empresas quieren ser eficientes para satisfacer las necesidades de sus clientes más rápido y obtener una ventaja competitiva antes. TODOS queremos ser coste efectivos... o debería decir... ¡PRUEBA EFECTIVA!<ul><li>¿Pero cómo hacemos eso?</li><li>¿Nos sirve bien la terminología de "unidad" e "integración"?</li><li>¿O es hora de un cambio? ¿Cuándo deberíamos usar cada estrategia para maximizar nuestra "efectividad de prueba"?</li></ul>¡En esta charla te mostraré una nueva forma de pensar sobre las pruebas coste efectivas con nuevas estrategias y nuevos términos de prueba!¡Es hora de ir MÁS PROFUNDO! <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Desarrollo Efectivo de Pruebas

This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.

Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!<ul><li>But how do we do that?</li><li>Are the "unit" and "integration" terminology serves us right?</li><li>Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?</li></ul>In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER! <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Test Effective Development

Shai Reznik

Playwright Test Runner

The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.

Andrey Lushnikov

Experiencia en pruebas de rendimiento que se ha desarrollado durante mucho tiempo. Para medir el rendimiento de su servidor, necesita una herramienta que pueda simular eficientemente muchas habilidades y proporcionarle buenas mediciones según sus criterios de análisis.La biblioteca NPM de Autocannon me dio exactamente eso: esa biblioteca es muy fácil de instalar y tiene una API muy simple con la que trabajar. En un corto período de tiempo, puede comenzar a realizar pruebas de rendimiento en su aplicación y obtener buenas mediciones en el entorno de desarrollo y en sus laboratorios de rendimiento, y generar escenarios de prueba complicados.En esta charla presentaré Autocannon, explicaré cómo analizar eficientemente el rendimiento de su servidor con él y mostraré cómo me ayudó a entender problemas de rendimiento complicados en mis servidores Node.js. Al final de esta conferencia, los desarrolladores tendrán la capacidad de integrar una herramienta rápida y fácil para medir el rendimiento de su servidor.

Pruebas de rendimiento efectivas para su servidor con Autocannon

Tamar is an experienced code writer and architect with expertise in Node.js. Performance testing can be confusing, but understanding terms like throughput and the 99th percentile is crucial. The 99th percentile is important for making commitments and ensuring customer satisfaction. AutoCanon is a powerful tool for simulating requests and analyzing server performance. It can be installed globally or used as a library in Node.js. Autocannon is preferred over Gatling for performance testing and can be integrated with end-to-end tests in Cypress.

Performance testing expertise that is developed for a long time. In order to measure your server performance you need a tool that can efficiently simulate a lot of abilities and give you good measurements according your analysing criteria.Autocannon NPM library gave me exactly that - that library is super easy to install and has a very simple API to work with. Within a really short amount of time you can start do performance testing to your application and get good measurements in development environment and in your performance labs, and generate complicated testing scenarios.In this talk I will introduce Autocannon, explain how to efficiently analyse your server performance with it, and show how it helped me to understand complicated performance issues in my Node.js servers. At the end of this lecture, developers will be able to have the ability to integrate a fast and easy tool in order to measure your server performance.

Effective Performance Testing to your Server with Autocannon

Tamar Twena-Stern

Axe-core es un motor de pruebas de accesibilidad popular que es utilizado por Google, Microsoft y cientos de otras empresas para asegurar que sus sitios web sean accesibles. Axe-core incluso puede integrarse en muchos marcos de pruebas populares, herramientas e IDEs. En esta sesión avanzada, aprenderemos cómo configurar axe y sus integraciones para afinar cómo se ejecutan y revisan tus páginas y código en busca de violaciones de accesibilidad. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Configurando las Pruebas de Accesibilidad de Axe

AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.

Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Configuring Axe Accessibility Tests

Steven Lambert

Las pruebas de Regresión Visual se realizan a través de la coincidencia de capturas de pantalla. Mostraré cómo hacerlo en tres diferentes bibliotecas/marcos de trabajo. Además, utilizaré Storybook para extraer los componentes de tu elección de SPA.

Regresión Visual con Puppeteer, Playwright y Cypress

Hello, I'm Rainer Haneckamp, a trainer and consultant at Angular Architects. In this talk, we'll explore visual regression testing using tools like Puppeteer, Playwright, and Cypress. We'll learn how to use Storybook and Puppeteer with Jest for visual regression testing. We'll also see how Jest and Playwright can be used together for visual regression testing. Finally, we'll discover how to use Cypress for visual regression testing. Thank you for watching!

Visual Regression tests components via screenshot matching. I'll show how you do that in three different libraries/frameworks. Additionally, I will use Storybook to extract the components from your SPA choice.

Visual Regression with Puppeteer, Playwright and Cypress

Rainer Hahnekamp

¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Pruebas automatizadas de accesibilidad con jest-axe y Lighthouse CI

This workshop covers automated accessibility testing, including linting, Just Axe, and Cypress Audit. Manual testing is essential for ensuring accessibility. The workshop explores the limitations of linting and introduces Just Axe to check for accessibility issues. Cypress Audit is used to detect contrast issues that code-based tests can't find. Lighthouse thresholds are set for accessibility, and a Lighthouse report is created to identify and fix issues. The workshop also addresses troubleshooting and setting background and foreground colors for maximum contrast.

Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Automated accessibility testing with jest-axe and Lighthouse CI

Bonnie Schulkin

Esta charla cubrirá cómo podemos aplicar el aprendizaje automático a las pruebas de software, incluido en JavaScript, para ayudar a reducir la cantidad de pruebas que deben ejecutarse.Podemos utilizar un modelo predictivo de aprendizaje automático para tomar una decisión informada y descartar pruebas que es extremadamente improbable que descubran un problema. Esto abre una nueva forma más eficiente de seleccionar pruebas. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Pruebas predictivas en JavaScript con Machine Learning

This Talk explores the benefits of introducing machine learning to software testing, including automating test case generation and achieving close to 100% code coverage. AI is being used to automate test generation, improve regression testing, and make predictions in automation testing. Machine learning enables predictive testing by selecting tests that are more likely to uncover issues in code changes. AI-based tools are being used to generate automated tests, improve code coverage, and intelligently select tests. Companies are relying on dedicated testers and using historical code changes and test cases to generate specific test cases for relevant code changes.

This talk will cover how we can apply machine learning to software testing including in Javascript, to help reduce the number of tests that need to be run.We can use predictive machine learning model to make an informed decision to rule out tests that are extremely unlikely to uncover an issue. This opens up a new, more efficient way of selecting tests. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Predictive Testing in JavaScript with Machine Learning

Shivay Lamba

Es una trampa` - una llamada o sensación con la que todos podríamos estar familiarizados, no solo cuando se trata de Star Wars. Señala un momento repentino de darse cuenta de un peligro inminente. Esta situación es una excelente alegoría para una desagradable realización en las pruebas. ¿Imagina tener las mejores intenciones cuando se trata de las pruebas pero aún así terminar con pruebas que no le brindan ningún valor en absoluto? ¿Pruebas que se sienten como un dolor para lidiar con ellas? Cuando se escriben pruebas de frontend, hay muchas trampas en el camino. En resumen, pueden llevar a una mala mantenibilidad, un tiempo de ejecución lento y, en el peor de los casos, pruebas en las que no se puede confiar. Pero no tiene que ser así. En esta sesión, hablaré sobre los errores comunes de los desarrolladores (incluyendo los míos), al menos desde mi experiencia. Y, por supuesto, sobre cómo evitarlos. Después de todo, las pruebas no tienen por qué ser dolorosas. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¡Es una trampa! - Trampas comunes en las pruebas y cómo solucionarlas

This Talk explores the pain points and best practices in software testing, emphasizing the importance of simplicity and comprehensibility in test design. It discusses techniques such as the three-part rule for test titles, the triple-A pattern for test structure, and the use of clear and descriptive names in tests. The Talk also highlights the traps of testing implementation details and using fixed waiting times. The speaker encourages teamwork and learning from experience to improve testing practices.

It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with? When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them

Ramona Schwering

Tener una cobertura de pruebas adecuada significa mucho para una buena API. Pero lo que puede hacer que toda la vida sea patética es el interminable simulacro de datos y funciones para las pruebas de integración. Cada vez que cambias el código, necesitas arreglar la simulación. Después de varias iteraciones, el pensamiento correcto es: ¿qué salió mal? Un enfoque alternativo son las pruebas de extremo a extremo para la API. Que requieren solo simulaciones mínimas y preparación de datos. El resto es código puro de tu API. Cambia el código, las pruebas de extremo a extremo siguen siendo las mismas.Esta charla trata sobre mi experiencia de cambiar de las pruebas de integración a las pruebas de extremo a extremo para la API, pros y contras, y cómo empecé a sentirme feliz con las pruebas. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Pruebas de extremo a extremo para API: Ahorrando Nervios y Horas

This Talk discusses the use of end-to-end tests for API development, specifically using the Nest.js framework. The process of initializing the Nest API for testing is explained, along with customization options such as overriding authentication guards. The benefits of end-to-end tests are highlighted, including ease of modification and serving as additional documentation for the API. The challenges of writing the initial version of the test and a trick for mocking the date in tests are also mentioned.

Having adequate test coverage means a lot for the good API. But what can make the whole life pathetic is endless mocking of data and functions for integration tests. Every time you've changed the code you need to fix the mock. After several iterations the correct thought is - what's went wrong? Alternative approach is e2e tests for the API. Which require only minimal mocks and data preparation. The rest - pure code of your API. Change the code - e2e test remains the same.This talk is about my experience of switching from integration tests to e2e tests for the API, proc and cons and how I started to feel happy about tests. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

E2E Tests for API – Saving Nerves and Hours

Valentin Kononov

¿Te gustaría perseguir tus pasiones y tener más control sobre tu carrera? ¿Te gustaría tener flexibilidad de horario y ubicación y variedad de proyectos? ¿Te gustaría tener la estabilidad de trabajar a tiempo completo y recibir un pago constante? Miles de empresas han adoptado el trabajo remoto y se dan cuenta de que tienen acceso a un grupo de talento global. Esto es ventajoso para cualquier persona que haya considerado o esté considerando trabajar como freelance. El trabajo freelance ya no es una elección de carrera inestable. Este masterclass te ayudará a diseñar una carrera freelance sostenible y rentable a tiempo completo (o parcial). Te proporcionaremos herramientas, consejos, mejores prácticas y te ayudaremos a evitar errores comunes. &gt;&gt; <a href="https://bit.ly/gn-portal-toptal-form2">Envía tu interés</a> en convertirte en un ingeniero freelance con Toptal y obtén una llamada con un especialista en adquisición de talento &lt;&lt; Tabla de contenidos: Módulo 1: Desmintiendo mitos comunes sobre el trabajo freelance Módulo 2: ¿Cómo se ve el trabajo freelance en 2021 y más allá? Módulo 3: Elecciones freelance y qué buscar (y qué evitar) Módulo 4: Beneficios del trabajo freelance desde la perspectiva de un freelancer + estudio de caso DESCANSO - DESAFÍO DE CODIFICACIÓN RÁPIDA Módulo 6: Cómo comenzar a trabajar como freelance (experiencia, currículum, preparación) Módulo 7: Rutas comunes hacia el trabajo freelance a tiempo completo Módulo 8: Aspectos esenciales: establecer tu tarifa y conseguir trabajo Módulo 9: Siguientes pasos: networking con colegas, mejora de habilidades, cambiar el mundo Módulo 10: Preguntas y respuestas con freelancers GANADOR DEL DESAFÍO DE CODIFICACIÓN RÁPIDA ANUNCIADO <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Diseñando una Carrera Freelance Sostenible

This workshop covers the essentials of building a sustainable freelance career, including transitioning from a full-time job, the challenges and benefits of freelancing, payment processes for non-US freelancers, insurance considerations, and the importance of building a personal brand. It also emphasizes the flexibility and freedom that freelancing offers, the importance of being part of a supportive network, and the opportunity to choose meaningful projects and clients. Additionally, it highlights the need for continuous upskilling and market research to stay competitive in the industry.

Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work. Freelancing is no longer an unstable career choice. This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls. &gt;&gt; <a href="https://bit.ly/gn-portal-toptal-form2">Submit your interest</a> on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist &lt;&lt; Table of contents: Module 1: Dispelling common myths about freelancing Module 2: What does freelancing look like in 2021 and beyond Module 3: Freelancing choices and what to look for (and what to avoid) Module 4: Benefits of freelancing from a freelancer + case study BREAK - SPEED CODING CHALLENGE Module 6: How to get started freelancing (experience, resume, preparation) Module 7: Common paths to full-time freelancing Module 8: Essentials: setting your rate and getting work Module 9: Next steps: networking with peers, upskilling, changing the world Module 10: Freelancer AMA SPEED CODING WINNER ANNOUNCED <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Designing A Sustainable Freelance Career

Alexander Weekes

Rodrigo Donini

Imagina escribir una función compleja sin pruebas unitarias. Tendrías que verificar cada escenario manualmente, una y otra vez. Engorroso, pero así es como la mayoría de los equipos construyen interfaces de usuario. Imagina si pudieras construir interfaces de usuario y probar interfaces de usuario en el mismo lugar. Si tus componentes incluyeran expectativas de cómo se suponía que debían comportarse, sabrías al instante cuando se rompieran.Storybook proporciona un enfoque organizado para construir interfaces de usuario. Documentas los casos de uso de un componente como historias, que luego se representan de forma aislada. Las historias son como pruebas, pero para la interfaz de usuario. Las pruebas de interacción de Storybook te permiten escribir secuencias de interacción y verificar expectativas en la propia historia. Esto te permite ejecutar y depurar pruebas de interfaz de usuario en el mismo entorno en el que se desarrollan los componentes de interfaz de usuario: tu navegador. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Prueba tu interfaz de usuario en el navegador REAL

Storybook is a powerful tool for building UI components and testing them. It allows for easy reuse and compatibility with other tools. Storybook 6.4 introduces interactive stories and live coding, making it easier to create and debug complex components. It also integrates with popular testing libraries like Jest and Testing Library. Storybook aims to bridge the gap between end-to-end testing and unit testing, providing automated testing options for UI components.

Imagine writing a complex function without unit tests. You would have to verify every scenario manually, over and over again. Cumbersome, but that's how most teams build user interfaces. Imagine if you could build UIs and test UIs in the same place. If your components included expectations for how they were supposed to behave, you'd know the instant they broke.Storybook provides an organized approach to building UIs. You document a component's use-cases as stories, which are then rendered in isolation. Stories are like tests, but for UI. Storybook interaction testing allows you to script interactions and check expectations in the story itself. That allows you to run and debug UI tests in the same environment UI components are developed for: your browser. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Test your UI in the REAL Browser

Gert Hengeveld

Entrar al mundo del software con una mentalidad de pruebas exploratorias es como llegar a un lienzo de múltiples capas con mucha información y una tarea abierta: ¡encontrar lo que podríamos haber pasado por alto! Esta es la tarea para todos nosotros en los equipos de software en nuestra búsqueda de calidad. Enmarcar la búsqueda de cómo nuestro sistema no cumple con las expectativas es más fácil cuando podemos ver el software desde la perspectiva del usuario. Sin embargo, las pruebas útiles no son una colección de pruebas de extremo a extremo que automatizamos, sino pruebas excelentes que dejamos atrás y que descomponen el problema de las pruebas de manera diferente. En esta charla, aprenderemos a utilizar la arquitectura como un filtro para descomponer las pruebas y veremos un ejemplo de cómo tomar el control de las respuestas de la API para probar un frontend de React. Los usuarios no saben ni les importa si el problema está en el frontend y los servicios que su equipo proporcionó si no cumple con sus expectativas, pero a usted le importa. La granularidad de los comentarios es importante. Reconocer los mismos problemas en un alcance incompleto, como características a medio hacer o solo en el frontend o las API, es una habilidad que la industria del software debe desarrollar. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¡Ve a buscar lo que podríamos haber pasado por alto!

Maaret Pyhäjärvi, a principal test engineer at Vaisala, emphasizes the importance of balancing different types of testing to build better teams. Testing the application with different locations reveals potential issues with its behavior. The speaker highlights the significance of testing integrations and dependencies, including libraries and operating systems. They prefer code-oriented tools like Requests and Python for API testing. Exploratory testing is the only type of testing they perform, and they encourage others to participate in it as well.

Coming into software with an exploratory testing mindset is like coming to a multi-layer canvas with lots of information and an open ended task: find what we may have missed! This is the assignment for us all in software teams in our quest for quality. Framing the search of how our system falls short of expectations is easier when we are able to see software from its user’s perspective. However, useful tests aren’t a collection of end-to-end tests we automate, but great tests to leave behind will decompose the testing problem differently. In this talk, we learn about using architecture as a filter in decomposing tests and look at an example of taking control over the API responses to test a React frontend. Users don’t know or care if the problem is in the frontend and services your team provided if it fails to meet their expectations but you care. Granularity of feedback matters. Recognizing the same problems in incomplete scope - half-done features or only in frontend or APIs - is a skillset the software industry needs to be building. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Go Find What We May Have Missed!

Maaret Pyhäjärvi

Esta charla trata sobre los errores comunes que cometen las personas al escribir pruebas. Mezclar múltiples aspectos dentro de las pruebas es tentador porque puede parecer que se está pintando todo el panorama. Sin embargo, esto oculta la causa raíz cuando una prueba falla. Los métodos de configuración son geniales, pero cuando los desarrolladores se centran demasiado en mantener sus pruebas DRY, pueden llevar fácilmente a la interdependencia de las pruebas. Por lo tanto, algunos principios que hemos aprendido para construir nuestro software debemos desaprenderlos cuando se trata de las pruebas. La charla destaca otros aspectos como las pruebas infladas que dificultan comprender de qué se tratan y el uso adecuado de las afirmaciones para obtener mejores mensajes de error.Especialmente si no trabajas con TDD, puede ser fácil crear una prueba que parezca buena pero que te obstaculice cuando falla. La charla analizará los cuatro escenarios que mencioné anteriormente, explicará por qué tiene sentido pensar en ellos y ofrecerá sugerencias prácticas sobre cómo mejorar las pruebas. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Pruebas que te ayudan a encontrar defectos más rápido

This talk covers tests that help find defects faster, focusing on test case assertions, improving test failure context, test code structure, and the dangers of extracting code in tests. It emphasizes the importance of small tests, test isolation, and using TDD. The benefits of TDD and testable automation are discussed, along with setting up an engineering workflow and the use of mocking. Overall, the talk provides valuable insights into writing effective tests and ensuring code quality.

This talk is about common mistakes people make when writing tests. Mixing multiple concerns inside tests is tempting because it can feel like painting the whole picture. However, it obfuscates the root cause when a test fails. Setup methods are great but when developers are too focussed on keeping their tests DRY they can easily lead to test interdependence. Therefore, some principles we have learned to build our software we need to unlearn when it comes to testing. The talk highlights more aspects like bloated tests which make it hard to figure out what they are about and proper usage of assertions to get better error messages.Especially if you don't work with TDD it can be easy to come up with a test that looks good but stands in your way when it fails. The talk will have a look at the four scenarios I outlined above, explain why it makes sense to think about them and actionable suggestions how to improve tests. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Tests That Help you Find Defects Faster

Philipp Giese

Una demostración del mundo real y un espacio de juego para el servicio de aplicaciones web estáticas de Azure.<a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Demo de aplicaciones web estáticas: CI/CD, implementación y canalización de pruebas en Azure

This workshop provides insights into engineering at Microsoft, highlighting the company's culture of curiosity, learning, and customer focus. It discusses the use of hackathons to generate ideas and overcome challenges in building large-scale products. The workshop also covers technical resources and tutorials on Azure Static Web Apps and Playwright testing framework. It emphasizes the flexibility and powerful features of Playwright for testing and code reuse. The session concludes with information about open positions at Microsoft.

A real-world demo and a playground for Azure Static Web Apps service. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Static Web Apps demo – CI/CD, Deployment and Test Pipeline on Azure

Juarez Barbosa Junior

Los sistemas de software contemporáneos suelen construirse sobre un patrón de arquitectura de microservicios. En este patrón, en lugar de construir una gran base de código para una sola aplicación, los sistemas se separan en múltiples bases de código más pequeñas. Estas implementan servicios que proporcionan una función específica, como autenticación o monitoreo, y esos servicios pueden tener problemas de rendimiento, problemas de red o errores en su código, cualquiera de los cuales puede provocar pruebas fallidas. Si desea resolver tales problemas, debe ir un paso más allá de simplemente registrar sus errores: lo mejor es monitorear sus pruebas con seguimiento distribuido. Esta charla le mostrará por qué un sistema de seguimiento lo rescatará de la complejidad de entender por qué una prueba de extremo a extremo ha fallado en una arquitectura distribuida. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¿Por qué el seguimiento es un salvavidas para las pruebas de extremo a extremo de los sistemas distribuidos?

Tandra is a company that builds modern tools for developers and QA engineers. Their flagship product, Foresight, helps monitor and debug CI-CD workflows and tests. The Talk discusses the reasons for end-to-end test failures, how to debug them, and the benefits of tracing. End-to-end tests can fail due to time-waiting issues, dependencies between tests, and inter-service communications. Debugging through logs and artifacts is possible, but tracing is more effective in uncovering root causes, especially in microservices.

Contemporary software systems are often built on a microservices architecture pattern. In this pattern, rather than build one huge code-base for a single application, systems are separated into multiple smaller code-bases. These implement services that provide a specific feature, like authentication or monitoring, and those services can have performance problems, network issues, or bugs in their code – any of which can lead to failing tests. If you want to solve such problems, you have to go a step further than just logging your errors – it is best for you to monitor your tests with distributed tracing. This talk will show you why a tracing system will rescue you from the complexity of understanding why an E2E test has failed in a distributed architecture. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Why Tracing is a Lifesaver for E2E Tests of Distributed Systems?

Burak Kantarci

Este masterclass es para usuarios de Cypress que desean mejorar su juego contra la inestabilidad en sus suites de pruebas. Aprovechando la aplicación Cypress Real World, cubriremos las causas más comunes de la inestabilidad, revisaremos algunos ejemplos de cómo hacer que las pruebas sean más resistentes a la inestabilidad y repasaremos las mejores prácticas para detectar y mitigar la inestabilidad para aumentar la confianza y la fiabilidad. Tabla de contenidos: - Descripción general de la aplicación Cypress Real World - ¿Qué es la inestabilidad? - Causas de la inestabilidad - Gestión de la inestabilidad relacionada con la red (Actividad) - Gestión de la inestabilidad relacionada con el DOM (Actividad) - Mejores prácticas para la detección y mitigación de la inestabilidad - Preguntas y respuestas <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Gestión de Pruebas Inestables con Cypress

This workshop focuses on flaky test management with Cypress. Participants will work with the Cypress Real World App to learn about different types of flake and how to address them. The workshop covers topics such as managing network requests, handling flaky tests, and reducing flakiness through test data management. The use of Cypress Dashboard for flake detection and analysis is also discussed. Overall, the workshop provides practical strategies and best practices for managing flaky tests in software development.

This workshop is for Cypress users who want to step up their game against flake in their test suites. Leveraging the Cypress Real World App, we’ll cover the most common causes of flake, code through some examples of how to make tests more flake resistant, and review best practices for detecting and mitigating flake to increase confidence and reliability. Table of contents: - Cypress Real World App Overview - What is Flake? - Causes of Flake - Managing Network-related Flake (Activity) - Managing Dom-relate Flake (Activity) - Flake Detection and Mitigation Best Practices - Q&amp;A <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Flaky Test Management with Cypress

Selenium 4 está aquí y a partir de ahora Selenium Webdriver estará completamente estandarizado por W3C. Navegadores como Chrome, Safari, Firefox, IE y Edge siguen la estandarización de W3C, lo que brinda más uniformidad y estabilidad en los comandos de Selenium que funcionan de manera uniforme en diferentes navegadores reales. Únete a David Burns, Colaborador Principal de Selenium, mientras habla sobre cómo esto afectará tus pruebas y las brillantes características nuevas que puedes comenzar a usar de inmediato. David mostrará cómo puedes acceder a un sitio protegido con autenticación básica, identificar una mutación del DOM, obtener errores de JS o mensajes de consola a medida que ocurren, utilizar nuevas APIs de Impresión y Ventana para ayudar con tus pruebas y más. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Selenium 4: ¡Novedades y cómo puedes usarlo!

Selenium 4.0 introduces exciting features such as relative locators, new window APIs, event-driven code, and network interception. It aims to make automation easier with improvements in scalability, observability, and handling of windows and tabs. The focus is on improving the quality of the web and incorporating user feedback. Selenium 4.0 also offers better support for mobile testing and cloud services, with ongoing documentation improvements.

Selenium 4 is out and going forward Selenium Webdriver will be completely W3C standardized. Browsers such as Chrome, Safari, Firefox, IE and Edge follow W3C standardization, bringing more standard and stability around selenium commands working uniformly across different real browsers. Join David Burns, Core Contributor to Selenium as he talks about how this would impact your tests and about the brilliant new features that you can start using straight away. David will show how you can access a site protected basic authentication, identify a DOM mutation, get JS errors or console messages as they happen, use new Print and Window APIs to help with your testing and more. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Selenium 4 – What's New and How you Can Use it!

David Burns

Como industria, entendemos que la automatización de pruebas efectiva es un habilitador clave - o un inhibidor - para realizar el potencial de DevOps. Si bien la automatización es fundamental para innovar con velocidad y calidad, muy pocos de nosotros estamos satisfechos con los resultados. Esta charla cubrirá cómo las soluciones de automatización de pruebas de bajo código - como mabl - permiten a los equipos incrustar pruebas automatizadas directamente en el pipeline de desarrollo, estrategias para superar los desafíos tradicionales de la automatización de pruebas y cómo construir una base para una estrategia de pruebas eficiente y efectiva. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Cómo Low-Code permite pruebas continuas en DevOps

Today's Talk discusses how Low Code enables continuous testing and DevOps, emphasizing the importance of test automation and the drawbacks of siloed approaches. The next era of quality engineering aims to overcome automation challenges by incorporating machine learning and intelligent automation. The development process involves local testing, pull requests, and comprehensive testing to ensure quality before merging. Low-code tools like Mable help democratize testing and achieve higher test coverage. Mable's coverage report includes performance metrics and test results, making testing easy and accessible for any team member.

As an industry, we understand that effective test automation is a key enabler - or inhibitor to - realizing the potential of DevOps. While automation is critical to innovating with speed and quality, very few of us are happy with the results. This talk will cover how low-code test automation solutions - like mabl - enable teams to embed automated tests directly into the development pipeline, strategies to overcome traditional challenges with test automation, and how to build a foundation for an efficient and effective test strategy. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How Low-Code Enables Continuous Testing in DevOps

Juliette MacPhail

Para los desarrolladores, es mejor detectar cualquier defecto de accesibilidad durante las pruebas unitarias y E2E. Esta charla mostrará cómo automatizar las pruebas de accesibilidad utilizando jest y cypress. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Cómo detectar defectos de accesibilidad durante las pruebas unitarias y E2E

This Talk provides ways to catch accessibility defects during testing, including adding accessibility testing to a website for Studio Ghibli using React, NX, Jazz, JazzX, Cypress, and CypressX. The importance of unitizing components and conducting end-to-end testing with Cypress and CypressX is emphasized to ensure accessibility. The process of setting up CypressX testing is explained, highlighting the use of typings and the CypressX support file. These tools make it easier for developers to avoid accessibility bugs during development.

For developers, it is better to catch any a11y defects during unit and e2e testings. This talk is going to show how to automate a11y testing using jest and cypress. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

How to Catch a11y Defects During Unit and E2E Testing

Emily Xiong

<div>El escáner de seguridad amigable para desarrolladores de NeuraLegion permite a los equipos de desarrollo ejecutar pruebas de seguridad precisas en cada compilación como parte de su pipeline. Las alertas falsas y los resultados periódicos de escaneo infrecuentes resultan en deuda técnica y de seguridad, así como en productos inseguros. Pero, ¿qué es DAST primero para desarrolladores, cuándo y cómo debes integrarlo en tus pipelines y qué debes buscar al mejorar tu automatización de pruebas de seguridad? Únete a esta charla para estar al día.</div> <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

JS Hazlo..... Automatización precisa de pruebas de seguridad para desarrolladores

Neuralegions is a dynamic application security testing scanner designed for developers. It allows you to build the scan surface from the first unit tests, seamlessly integrating into your pipelines. With no false positives, you can trust the output to quickly detect and fix security vulnerabilities. Eurolegion provides comprehensive coverage, supporting web apps, internal apps, and APIs. It can handle client-side dynamic content and integrates with existing functional scripts. Scans are fast and can test for business logic vulnerabilities. Authenticated scans are fully supported. The biggest issue with security scanners is accuracy. Developers want to know real issues, not hyperbole. Neuralegion focuses on removing false positives automatically. It validates every finding with a full proof of concept, eliminating the need for manual validation. Full visibility of recurring and new issues is provided, along with developer-friendly remediation guidelines. Neuralegion seamlessly integrates into your pipeline, allowing developers to shift left and scan every commit or pull request.

<div>NeuraLegion's developer friendly security scanner enables development teams to run dead accurate security tests on every build as part of their pipeline. False alerts and periodic infrequent scanning results in technical and security debt, as well as insecure product. But what is developer first DAST, when and how should you be integrating it into your pipelines and what should you be looking for when enhancing your security testing automation? Join this talk to get up to date.</div> <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

JS Do It.....Accurate Security Testing Automation for Developers

Oliver Moradov

<div>¿Alguna vez te has preguntado: "¿quién está probando las pruebas"? Por supuesto, las pruebas solo son valiosas si detectan errores, pero ¿cómo se puede validar eso? ¡Bueno, déjame hablarte sobre la prueba de mutación! La prueba de mutación consiste en probar tus pruebas para verificar que detecten errores. Por supuesto, puedes hacer esto manualmente insertando errores y ejecutando las pruebas, ¡pero un marco de prueba de mutación puede hacerlo por ti! Únete a mí y aprende los conceptos básicos de la prueba de mutación y cómo usar StrykerJS, el marco de prueba de mutación para JavaScript o TypeScript.Al final de esta charla, serás tú quien esté probando tus pruebas, ¡y ni siquiera te costará mucho tiempo!</div> <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¿Quién está probando las pruebas?

Mutation testing is a method to improve test quality by inserting bugs into code to test if tests can detect them. Mutation-testing frameworks like Striker.js allow for various mutations to be performed. Mutation testing provides a mutation score that is a better tool than code coverage for measuring test quality. It can help identify missing tests or bugs in existing tests. Stryker is recommended for JavaScript and TypeScript mutation testing.

<div>Have you ever wondered: "who's testing the tests"? Of course, tests are only valuable if they catch bugs, but how would one validate that? Well, let me tell you about mutation testing! Mutation testing is the act of testing your test verifying that they catch bugs. Of course, you can do this manually inserting bugs and running the tests, but a mutation testing framework can do this for you! Join me and learn the basics of mutation testing and how to use StrykerJS, the mutation testing framework for JavaScript or TypeScript.At the end of this talk, you'll be the one that is testing your tests, and it won't even cost you much time!</div> <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Who is Testing the Tests?

Simon de Lang

Hoy en día, las pruebas se han vuelto la norma. Hay muchas herramientas disponibles para escribir diferentes tipos de pruebas. Si bien las pruebas mantienen la guardia sobre el código principal de la aplicación, ¿cómo puedes estar seguro de que no tienes errores ocultos en tu código de prueba? ¿Deberías escribir pruebas para las pruebas?En esta charla ilustrativa te mostraré un enfoque diferente sobre cómo puedes eliminar ciertos tipos de problemas de tus pruebas utilizando herramientas de análisis estático de código como SonarLint o SonarQube. Nos enfocaremos en problemas comunes encontrados en pruebas utilizando frameworks como Mocha y Chai.<a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¿Quién guarda a los guardianes? - Encontrando errores en tus pruebas

The Talk discusses common pitfalls of JavaScript unit testing, including issues with expectations, assertions, and missing assertions. It also highlights the importance of handling exceptions properly and introduces SonarLint as a tool for code analysis and issue fixing. Additionally, it mentions SonarCube and SonarCloud as options for integrating static analysis testing in a continuous integration pipeline.

Nowadays, testing has become the norm. There are many tools available to write different kinds of tests. While tests keep the guard on the main code of the application, how can you be sure that you don’t have bugs hiding in your test code? Should you write tests for the tests?In this lighting talk I will show you a different approach on how you can eliminate certain types of issues from your tests using static code analysis tools like SonarLint or SonarQube. We will focus on common issues found in tests using frameworks such as Mocha and Chai. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Who Guards the Guards? – Finding Bugs in Your Tests 

Tibor Blenessy

Como desarrollador, necesitas entregar rápido y simplemente no tienes tiempo para pensar constantemente en seguridad. Aún así, si algo sale mal, es tu trabajo arreglarlo, pero las pruebas de seguridad bloquean tu automatización, crean cuellos de botella y solo retrasan las versiones... pero no tiene por qué ser así... El escáner de seguridad de NeuraLegion, enfocado en los desarrolladores, Dynamic Application Security Testing (DAST), permite a los desarrolladores detectar, priorizar y remediar problemas de seguridad de manera TEMPRANA, en cada confirmación, sin falsos positivos/alertas, sin ralentizarte. ¡Únete a esta masterclass para aprender diferentes formas en que los desarrolladores pueden acceder a Nexploit y comenzar a escanear sin salir de la terminal! Recorreremos la configuración de principio a fin, mientras configuramos un pipeline, ejecutamos pruebas de seguridad y analizamos los resultados. Tabla de contenidos: - Qué es realmente DAST (Dynamic Application Security Testing) enfocado en los desarrolladores y cómo funciona - Ver dónde y cómo encaja un DAST moderno y preciso en el CI/CD - Integrar el escáner Nexploit de NeuraLegion con GitHub Actions - Comprender cómo se pueden probar las aplicaciones modernas, las API y los mecanismos de autenticación - Hacer un fork de un repositorio, configurar un pipeline, ejecutar pruebas de seguridad y analizar los resultados <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

JS Automatización de Pruebas de Seguridad para Desarrolladores en Cada Compilación

This workshop introduces developers to security testing automation using Neuralegion's Developer First DAST. It covers the challenges of application security testing, the limitations of static analysis tools, and the benefits of using DAST tools. The workshop includes hands-on exercises on forking a repo, running scans, analyzing results, and testing authentication mechanisms. Neuralegion's DAST features include API security testing, automatic validation of findings, seamless integration into pipelines, and optimization of scan speeds. The workshop also covers setting up CI workflows, running scans, and analyzing vulnerabilities. Participants can ask questions and receive continued support beyond the workshop.

As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases...but it doesn't have to... NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives/alerts, without slowing you down. Join this workshop to learn different ways developers can access Nexploit &amp; start scanning without leaving the terminal! We will be going through the set up end-to-end, whilst setting up a pipeline, running security tests and looking at the results. Table of contents: - What developer-first DAST (Dynamic Application Security Testing) actually is and how it works - See where and how a modern, accurate dev-first DAST fits in the CI/CD - Integrate NeuraLegion's Nexploit scanner with GitHub Actions - Understand how modern applications, APIs and authentication mechanisms can be tested - Fork a repo, set up a pipeline, run security tests and look at the results <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

JS Security Testing Automation for Developers on Every Build

Bar Hofesh

Con StackHawk, los equipos de ingeniería pueden realizar pruebas de seguridad en aplicaciones JS y las API subyacentes para encontrar y solucionar vulnerabilidades más rápido. Con pruebas automatizadas en cada PR, puedes tener la confianza de que tu aplicación es segura. Únete a Scott Gerlach, cofundador de StackHawk, para obtener una breve descripción de las pruebas de seguridad de aplicaciones JS con StackHawk. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Pruebas automatizadas de seguridad de aplicaciones

StackHawk is a dynamic application security testing tool that helps you find, understand, and fix security bugs in your running HTTP applications and API endpoints. It runs active security tests using OWASP top 10 best practices and can be integrated into CI/CD workflows. The scanner provides detailed scan results, including findings like SQL injection and cross-site scripting issues, and can be configured using YAML. StackHawk can be used to triage and prioritize security issues, and it can be seamlessly integrated into the development workflow.

With StackHawk, engineering teams can run security tests against JS applications and the backing APIs to find and fix vulnerabilities faster. With automated testing on every PR, you can be confident that your app is secure. Join StackHawk co-founder Scott Gerlach for a quick overview of JS application security testing with StackHawk. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Automated Application Security Testing

Scott Gerlach

La adopción de software de código abierto continúa creciendo y crea importantes preocupaciones de seguridad, desde ataques a la cadena de suministro de software en los registros del ecosistema de lenguajes hasta preocupaciones de seguridad de aplicaciones nativas en la nube. En esta sesión, exploraremos cómo los desarrolladores son objetivo como vehículo para la distribución de malware, cuánto dependemos de los mantenedores de código abierto para lanzar correcciones de seguridad oportunas y cómo la carrera hacia la nube crea nuevas preocupaciones de seguridad para que los desarrolladores las enfrenten, a medida que los recursos informáticos se convierten en infraestructura como código. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¿Estamos condenados para siempre a la seguridad de la cadena de suministro de software?

The Talk discusses the importance of software security and the risks associated with open-source software supply chains. It highlights real-world stories of developers' involvement in security incidents and emphasizes the need to trust the software we use. The Talk also addresses the vulnerabilities and targeted attacks that come with the growing dependency on open-source software. It explores the security risks in open-source dependencies, open-source ecosystems, and the future of open source software. Additionally, it provides insights into choosing the best vulnerability scanning software and promoting supply chain security practices.

The adoption of open-source software continues to grow and creates significant security concerns for everything from software supply chain attacks in language ecosystem registries to cloud-native application security concerns. In this session, we will explore how developers are targeted as a vehicle for malware distribution, how immensely we depend on open-source maintainers to release timely security fixes, and how the race to the cloud creates new security concerns for developers to cope with, as computing resources turn into infrastructure as code. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Are we Forever Doomed to Software Supply Chain Security?

Liran Tal

Para los equipos ágiles modernos, la velocidad de lanzamiento es muy crítica. Desafortunadamente, uno de los mayores cuellos de botella para una mayor velocidad de lanzamiento son los tiempos de prueba. Incluso después de que los equipos implementen la automatización de pruebas de extremo a extremo, los largos tiempos de prueba retrasan significativamente los pipelines. Este retraso significa que los desarrolladores reciben retroalimentación de sus esfuerzos muy tarde, lo que puede tener un efecto acumulativo y afectar la velocidad de envío. Por lo tanto, el tiempo de ejecución de las pruebas se convierte en uno de los KPI más críticos para cualquier negocio que desee lanzar características más rápido que las fechas límite que se acercan. LambdaTest ayuda a los equipos de desarrollo modernos a lanzar más rápido ejecutando pruebas más rápido en una nube de pruebas escalable y confiable. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

¡Ejecución de Tiempo de Prueba! ¿Por qué no se puede ignorar?

Lambda Test is a cloud-based continuous quality platform that addresses common challenges faced by modern QA and development teams. These challenges include the need to shorten release cycles, the increase in test execution time due to test infrastructure, and the impact of flaky tests on developer feedback and productivity. Lambda Test offers a wide range of features, including live testing for virtual machines and native app testing, automation cloud for running test suites, and integration with various tools. The platform is known for its reliability, scalability, and performance, and can be quickly onboarded and integrated with existing test suites and CI-CD tools.

For modern agile teams, release velocity is very critical. Unfortunately, one of the biggest bottlenecks for faster release velocity is testing times. Even after teams implement end-to-end test automation, long testing times significantly delay the pipelines. This delay means developers get feedback of their efforts very late, which can snowball, affecting the shipping velocity. Hence test execution time becomes one of the most critical KPIs for any business that wants to ship features faster than the approaching deadlines. LambdaTest helps modern dev teams release faster executing tests faster on a scalable, reliable test cloud. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Test Time Execution! Why it Can't be Ignored? 

Jay Singh

Este masterclass te guiará a través de la instalación y explotación de una serie de aplicaciones intencionalmente vulnerables. Las aplicaciones utilizarán paquetes del mundo real con vulnerabilidades conocidas, incluyendo: - Traversing de directorios - Denegación de servicio de expresiones regulares (ReDoS) - Scripting de sitios cruzados (XSS) - Ejecución remota de código (RCE) - Sobrescritura arbitraria de archivos (Zip Slip) - Estas vulnerabilidades existen en varias aplicaciones, la mayoría de las cuales deberás instalar localmente o en una instancia en la nube. Puedes realizar este masterclass de 2 formas diferentes: - Utilizando las imágenes Docker preparadas O - Instalando todo en tu máquina local. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Cómo Explotar Vulnerabilidades del Mundo Real

We'll discuss the benefits and vulnerabilities of open source software, including the importance of being aware of transitive dependencies. Open source supply chain security is a growing concern, and tools like Snyk can help identify and fix vulnerabilities. The workshop covers topics such as directory traversal, cross-site scripting, and catastrophic backtracking, demonstrating how these vulnerabilities can be exploited and fixed. The key takeaways include continuous scanning, checking vulnerabilities in new dependencies, and using tools like Snyk for secure software development.

This workshop will lead you through installing and exploiting a number of intentionally vulnerable applications. The applications will use real-world packages with know vulnerabilities, including: - Directory traversal - Regular expression denial of service (ReDoS) - Cross site scripting (XSS) - Remote code execution (RCE) - Arbitrary file overwrite (Zip Slip) - These exploits exist in a number of applications, most of which you will need to install either locally or on a cloud instance. You can do this workshop in 2 different flavours: - Using the prepared Docker images OR - Install everything on your local machine. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

TestJS Summit 2021

Test JavaScript. Test with JavaScript.