El rol del QA (Quality Assurance) es esencial en el ámbito de la Experiencia de Usuario (UX) por varias razones:


🔍 Pruebas de Usabilidad: Los QA pueden realizar pruebas de usabilidad para evaluar cómo los usuarios interactúan con el producto y si la experiencia es intuitiva y satisfactoria. Esto incluye observación directa, recopilación de comentarios y encuestas.



♿ Pruebas de Accesibilidad: Los QA pueden garantizar que el producto sea utilizable por personas con diversas habilidades y discapacidades, realizando pruebas de accesibilidad y verificando el cumplimiento de las pautas.



🎨 Validación de Diseño y Consistencia: Los QA pueden asegurar que el diseño del producto sea coherente y cumpla con los estándares de diseño centrados en el usuario, verificando la consistencia visual y la navegación.



🔍 Identificación de Problemas de UX: Los QA identifican y reportan problemas relacionados con la experiencia del usuario, incluyendo usabilidad, accesibilidad y diseño.



📈 Proporcionar Retroalimentación para Mejoras: Los QA ofrecen retroalimentación al equipo de desarrollo y diseño para mejorar la usabilidad, accesibilidad y diseño del producto.



¡El QA desempeña un papel clave en garantizar una experiencia de usuario excepcional! 💡



🎧 #audio plus para escuchar:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Si te gustó este post, Sígueme en LinkedIn: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta para ver muchos más.



¡Prepárate para llevar tu software al siguiente #nivel 🚀

"Pruebas de oído musical:" 🎶 En proyectos con interfaces de voz, ¡las pruebas de oído garantizan que el software sea un verdadero maestro de todos los acentos y entonaciones!🌍

"Localización extrema:" ¡Desde la Antártida hasta el espacio exterior! Algunas apps se someten a pruebas en lugares tan remotos que ni siquiera Google Maps podría llegar.🚀

Pruebas de "Monkey": 🙉 ¡Deja que los monos prueben tu app! 🐒 Las pruebas de "Monkey" exploran cómo se comporta tu software cuando las acciones son tan impredecibles como un mono en una máquina de escribir. 🍌

"Ingeniería inversa de pruebas:" 🔍 Algunos equipos desmantelan el código fuente como si fueran detectives, ¡buscando secretos ocultos y diseñando pruebas aún más efectivas!

"Pruebas de tolerancia al aburrimiento:" 😴 ¿Qué tan aburrido puede volverse tu software? ¡Simula la monotonía humana y descúbrelo! 🤖

"Pruebas de "Chaos Engineering":" ⚡️ Introduce caos intencionalmente. ¡Un enfoque audaz para ver cómo se comporta tu sistema en situaciones de pesadilla! 😱🤯

"Pruebas de legibilidad de código:" 📜 No solo funcionalidad, ¡también estilo! Algunos equipos aseguran que su código sea más fácil de entender que un cuento de hadas. 📚✨

"Pruebas de resiliencia ante eventos astronómicos:" 🌌 ¡Protege tu software de llamaradas solares masivas y eventos cósmicos! 💥

"Pruebas de respuesta a eventos paranormales:" 👻 ¡Fantasmas y software! 🧙�♂️ Crea escenarios de prueba que desafíen lo normal y lo paranormal. 🌈

"Pruebas de resistencia a memes:" 🤔 ¿Tu aplicación puede manejar el poder de los memes? ¡Asegúrate de que no se derrumbe bajo la presión viral! 🤯📈

Si te gustó este post, Sígueme en LinkedIn: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta para ver muchos más.

🚀 ¡Explorando el DOM: la columna vertebral del desarrollo web! 🚀

El Document Object Model (DOM) es como el sistema nervioso central de una página web, conectando el contenido y la funcionalidad para crear experiencias interactivas y dinámicas para los usuarios. 💻✨



✨ ¿Qué es el DOM?
El DOM es una representación en forma de árbol de la estructura de un documento HTML o XML, que proporciona una interfaz para acceder y manipular dinámicamente los elementos de una página web mediante scripts, como JavaScript. Cada elemento HTML se convierte en un objeto en el árbol del DOM, lo que permite a los desarrolladores interactuar con ellos y modificarlos según sea necesario.

✨ ¿Por qué es importante el DOM?
El DOM es fundamental para el desarrollo web moderno por difrentes razones:
Facilita la creación de páginas web interactivas y dinámicas.
Permite a los desarrolladores acceder y manipular los elementos de una página de manera dinámica.
Proporciona una estructura coherente y jerárquica para organizar el contenido de la página.
Permite la creación de aplicaciones web complejas mediante la interacción con eventos y actualizaciones en tiempo real.

✨ ¿Cómo se utiliza el DOM?
Los desarrolladores web utilizan el DOM principalmente a través de JavaScript para:
Acceder a elementos de la página y sus atributos.
Modificar el contenido, estilo y estructura de la página.
Responder a eventos del usuario, como clics y desplazamientos.
Crear y eliminar elementos dinámicamente según sea necesario.

Continuará-c- 😁

Si te gustó este post, Sígueme en LinkedIn: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta para ver muchos más.

Automatizar pruebas es esencial, pero hacerlo de manera hashtag#organizada y mantenible es aún más crucial. Aquí es donde entra en juego el "Page Object Model" (POM), un patrón de diseño que revoluciona nuestra aproximación a las pruebas automatizadas.

¿Por qué considerar el POM?

1️⃣ Separación de Responsabilidades: Divide la lógica de prueba y la interfaz de usuario, simplificando la gestión de pruebas y adaptándose fácilmente a cambios en la UI.

2️⃣ Reutilización del Código: Representa cada página como un objeto, permitiendo la reutilización eficiente de objetos en diferentes scripts de prueba.

3️⃣ Mantenibilidad: Actualiza solo las clases de Page Object afectadas por cambios en la interfaz, reduciendo el riesgo de errores y mejorando la mantenibilidad del código.

4️⃣ Colaboración Facilitada: Estructura el código de manera clara, fomentando la colaboración efectiva entre equipos de desarrollo y pruebas.

5️⃣ Escalabilidad: A medida que el proyecto crece, el POM proporciona una arquitectura escalable que permite la adición eficiente de nuevas páginas y funcionalidades.

6️⃣ Facilita la Depuración: La representación clara de la interfaz en Page Objects simplifica la identificación y corrección de problemas en las pruebas automatizadas.

Implementar el POM no solo mejora la calidad de las pruebas, sino que también acelera el desarrollo y la entrega de software de manera más confiable. 🚀✨

Si te gustó este post, Sígueme en LinkedIn: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

¡Prepárate para llevar tu software al siguiente nivel 🚀

🚀Hoy comparto el tema de Load Testing🚀

Cuando un proyecto de desarrollo de software está cerca de completarse, es probable que haya pasado por numerosas pruebas, especialmente en un entorno ágil donde desarrollo y prueba van de la mano. Sin embargo, independientemente de cuántas pruebas hayas realizado, solo hay una forma de saber si tu aplicación puede manejar las demandas reales de tus usuarios finales: la prueba de carga o Load testing. Utiliza herramientas como Load Testing Tool para este trabajo crucial. La prueba de carga simula la demanda en software, aplicaciones o sitios web, probando su comportamiento en diversas condiciones.

🤖 ¿Qué es Load Testing?
Es crear simulaciones de producción dentro de una aplicación que está casi lista para implementarse. La prueba de carga, con software especializado, responde preguntas como "¿Mi sistema hace lo esperado bajo estas condiciones?" y "¿Su rendimiento es suficientemente bueno?" Es medir tiempos de respuesta, tasas de rendimiento y niveles de utilización de recursos para identificar el punto de quiebre del sistema.

💡 ¿Por qué es Importante Load Testing?
Asegura que tu aplicación funcione como se espera en producción. Pasar una prueba funcional no garantiza el rendimiento bajo carga. La prueba de carga identifica dónde y cuándo falla tu aplicación, permitiéndote solucionar problemas antes del lanzamiento. Con aplicaciones digitales siendo críticas, es crucial validar que puedan resistir cargas realistas.

🌐 Load vs. Stress
La prueba de carga aplica estrés normal para verificar si un sistema puede funcionar en condiciones normales. En cambio, la prueba de estrés sobrecarga las cosas hasta que se rompen, explorando límites extremos. Ambas son cruciales, pero la prueba de carga es ideal para asegurar que tu software pueda manejar cargas esperadas.

🛠� Cómo Comenzar con la Load Testing
Hoy en día, comenzar con la prueba de carga es más accesible. Con herramientas como LoadNinja, puedes evitar la complejidad. Define requisitos críticos, mapea los recorridos del usuario, establece un punto de referencia y automatiza e integra las pruebas en tus procesos de desarrollo continuo.

Si te gustó este post, Sígueme en LinkedIn: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

📌En Inglés:
 SQL easy: Nivel básico.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 SQLZoo: Nivel básico.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 SQL Course: Nivel básico.
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Mode: Nivel básico, intermedio y avanzado.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 MGL: Nivel básico e intermedio,
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 W3Schools: Nivel básico-intermedio.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Canal FCC: Curso de 4 horas.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Weld: Nivel Básico-intermedio. Contiene teoría y tips.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Brain Station: Nivel básico-intermedio.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 MidLuster: Nivel básico, intermedio, avanzado.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 LSQLO: Nivel básico-intermedio con ejercicios.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 CFGG: Varios tutoriales.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 SQL Bolt: Ejercicios interactivos.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 GFG: Ejercicios para poner en práctica durante 1 mes.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Pragimtech: Nivel básico-avanzado. Puedes aprender mediante lectura, presentaciones o vídeos.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 SQL Server: Nivel básico-intermedio.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Tutorials Point: Nivel básico, intermedio, avanzado.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Libro con teoría:
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 DFT: Nivel básico, intermedio, avanzado. Con ejemplos.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 
📌En Español:
 Data Ademia:
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Delete SQL: Nivel básico-avanzado. Contiene Banco de pruebas.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta (Español)
 ServerYa: Nivel básico con ejemplos resueltos.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 CodigosSQL: Nivel básico.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 BBD: Nivel básico-intermedio con ejercicios.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Canal Fernando Herrera: Nivel básico, intermedio, avanzado.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 Canal Soy Dalto: Curso de 7 hrs.
 🔗No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

¿Qué son las pruebas funcionales?

Las pruebas funcionales son un tipo de prueba de software que verifica la funcionalidad de un sistema o aplicación de software. Se centra en garantizar que el sistema se comporte de acuerdo con los requisitos funcionales especificados y satisfaga las necesidades comerciales previstas.

El objetivo de las pruebas funcionales es validar las características, capacidades e interacciones del sistema con diferentes componentes. Implica probar la entrada y salida del software, la manipulación de datos, las interacciones del usuario y la respuesta del sistema a diversos escenarios y condiciones. Las pruebas funcionales solo se ocupan de validar si un sistema funciona según lo previsto.

Tipos de pruebas funcionales

Pruebas unitarias : las realizan desarrolladores que escriben scripts que prueban si los componentes/unidades individuales de una aplicación cumplen con los requisitos. Por lo general, esto implica escribir pruebas que llamen a los métodos en cada unidad y los validen cuando devuelvan valores que coincidan con los requisitos.
En las pruebas unitarias, la cobertura del código es obligatoria. Asegúrese de que existan casos de prueba que cubran lo siguiente:

Cobertura de línea

Cobertura de ruta de código

Cobertura del método


Prueba de humo : esto se realiza después del lanzamiento de cada compilación para garantizar que la estabilidad del software esté intacta y no enfrente ninguna anomalía.

Sanity Test : generalmente realizadas después de una prueba de humo, se ejecuta para verificar que todas las funciones principales de una aplicación funcionan perfectamente, tanto por sí mismas como en combinación con otros elementos.

Pruebas de regresión : esta prueba garantiza que los cambios en el código base (código nuevo, estrategias de depuración, etc.) no interrumpan las funciones ya existentes ni provoquen cierta inestabilidad.

Pruebas de integración : si un sistema requiere múltiples módulos funcionales para funcionar de manera efectiva, se realizan pruebas de integración para garantizar que los módulos individuales funcionen como se espera cuando operan en combinación entre sí. Valida que el resultado de extremo a extremo del sistema cumpla con estos estándares necesarios.

Pruebas Beta/de usabilidad : en esta etapa, los clientes reales prueban el producto en un entorno de producción. Esta etapa es necesaria para evaluar qué tan cómodo se siente un cliente con la interfaz. Se toman sus comentarios para implementar mejoras adicionales en el código.

Pasos realizados en las pruebas funcionales

La descripción general de una prueba funcional incluye los siguientes pasos:

Crear valores de entrada

Ejecutar casos de prueba

Comparar la producción real y esperada

Generalmente, las pruebas funcionales en detalle siguen los pasos a continuación:

Determine qué funcionalidad del producto debe probarse. Esto puede variar desde probar funciones principales, mensajes, condiciones de error y/o usabilidad del producto.

Cree datos de entrada para las funcionalidades que se probarán de acuerdo con los requisitos especificados.

Determinar los parámetros de salida aceptables de acuerdo con los requisitos especificados.

Ejecutar casos de prueba.

Compare la salida real de la prueba con los valores de salida predeterminados. Esto revela si el sistema está funcionando como se esperaba.

Ejemplo de prueba funcional

Para comprender los diferentes tipos de pruebas funcionales, a continuación se presenta un escenario de prueba para diferentes tipos de técnicas de prueba funcionales.

Escenario de prueba :

Un portal online de HRMS en el que el usuario inicia sesión con su cuenta de usuario y contraseña. La página de inicio de sesión tiene dos campos de texto para nombre de usuario y contraseña. También tiene dos botones: Iniciar sesión y Cancelar.

Cuando tiene éxito, la página de inicio de sesión dirige al usuario a la página de inicio de HRMS. El botón cancelar cancela el inicio de sesión.

Especificaciones :

El campo de identificación de usuario requiere un mínimo de 6 caracteres, un máximo de 10 caracteres, números (0-9), letras (az, Az), caracteres especiales (solo se permiten guiones bajos, puntos y guiones). No se puede dejar en blanco. La identificación del usuario debe comenzar con un número/carácter. No puede incluir caracteres especiales.
El campo de contraseña requiere un mínimo de 6 caracteres, un máximo de 8 caracteres, números (0-9), letras (az, AZ), todos caracteres especiales. No puede estar en blanco.
El escenario de caso de uso anterior se puede probar mediante una variedad de técnicas de prueba funcionales .

1. Pruebas del sistema/basadas en el usuario final

Pruebe el sistema para medir si todos los componentes funcionan perfectamente en combinación.

En el ejemplo, esto implicaría probar el recorrido del cliente: cargar la aplicación HRMS, ingresar credenciales precisas, dirigirlo a la página de inicio, realizar tareas y cerrar sesión en el sistema. Esta prueba garantiza que este flujo de trabajo continúe y se complete sin errores.

2. Pruebas de equivalencia

Los datos de prueba se segregan en particiones llamadas casos de datos de equivalencia. En esta prueba, los datos de cada partición deben responder de la misma manera. En consecuencia, sólo necesita probar una condición en todas las particiones. Si la condición no funciona en una partición, no funcionará en ninguna de las demás.

En el ejemplo, dado que el campo de identificación de usuario puede contener un máximo de 10 caracteres, debería comportarse de la misma manera cada vez que se ingresan datos > 10.

3. Pruebas de valores

Estas pruebas se utilizan para comprobar cómo se comporta el sistema cuando se implementan límites de datos.

En el ejemplo, dado que la identificación de usuario requiere un mínimo de 6 caracteres, esta prueba se utilizará para verificar cómo responde el sistema cuando se ingresan menos de 6 caracteres.

4. Pruebas basadas en decisiones

Estas pruebas se inician para verificar los posibles resultados del sistema cuando se cumple una condición particular.

En el ejemplo, se pueden realizar las siguientes pruebas basadas en decisiones:

Si se ingresan credenciales incorrectas, el sistema debe informar al usuario y recargar la página de inicio de sesión.
Si se ingresan las credenciales correctas, el sistema debería llevar al usuario a la interfaz de usuario de la página de inicio.
Si se ingresan las credenciales correctas pero el usuario desea cancelar el inicio de sesión, el sistema no debe dirigirse a la interfaz de usuario de la página de inicio.
En su lugar, debería recargar la página de inicio de sesión.

5. Pruebas ad hoc

Estas pruebas descubren discrepancias que podrían no haberse identificado en ninguna de las otras pruebas. Las pruebas ad hoc tienen como objetivo romper el sistema y comprobar su respuesta.

En el ejemplo, se podría realizar una prueba ad hoc para comprobar lo siguiente:

Mientras un usuario todavía está conectado, el administrador elimina su cuenta, también mientras el usuario realiza tareas. La prueba verificaría si la aplicación respondió correctamente en tal escenario.

1. ¿Para ti qué es hacer testing?
El objetivo de esta pregunta es conocer la visión que tiene el candidato sobre qué es el testing. Lo más básico que debería de responder el candidato es que el testing son procesos, metodologías y herramientas para identificar errores en el software, para que se puedan corregir antes de que el usuario final lo utilice.

2. ¿Por qué decidiste ser tester?
Esta pregunta es para identificar que el candidato sea un apasionado de su profesión. Los mejores profesionales son aquellos que les gusta lo que hacen.

3. ¿Has hecho análisis de requerimientos?
Un análisis de requerimiento es bajar en papel cuáles son las necesidades tecnológicas que tiene una empresa. O sea, qué es lo que debe tener el sistema para cumplir con los requerimientos del cliente.
Esto es importante para que después el tester pueda definir los casos de prueba.
 
4. ¿Has diseñado casos de prueba?
Los casos de prueba son las condiciones o variables bajo las cuales un tester determina si una aplicación, o una funcionalidad de esa aplicación es satisfactoria.
En palabras más simples son la guía o estándares que usa el tester para determinar si un programa funciona correctamente o no.
 
5. ¿Qué tipos de pruebas hay?
Realizar pruebas de software permiten al tester determinar que el sistema cumple con los requerimientos del cliente e identificar un error antes de que llegue al usuario final.
En el testing existen pruebas funcionales y no funcionales. 
Estas son algunas de las pruebas que podría mencionar el candidato.
 
Pruebas funcionales
 
Pruebas unitarias: aseguran que cada célula del código desarrollado en un componente brinde los resultados adecuados.
Pruebas de componentes:  su objetivo es verificar las funcionalidades y/o usabilidades de los componentes.
Prueba de humo: se realizan para verificar si las funcionalidades más significativas de la aplicación funcionan o no.
Prueba de integración: es uno de los tipos de prueba funcional más común y se realiza de forma automatizada. Se realizan para probar componentes individuales con el objetivo de verificar cómo los módulos, que trabajan de forma individual, funcionan cuando están integrados.
Pruebas de regresión: el objetivo de estas pruebas es encontrar errores que puedan haber sido introducidos accidentalmente en la compilación existente.
Pruebas de aceptación:  los usuarios reales usan el software para verificar que cumpla con las tareas requeridas en un ambiente 'real'.
Pruebas no funcionales
 
Pruebas de compatibilidad: sirven para verificar el funcionamiento de un sistema en distintos entornos. Por ejemplo, probar una aplicación web en distintos navegadores como Chrome o Microsoft Edge.
Pruebas de carga: validar que la respuesta de una aplicación sea buena cuando está siendo usada por varios usuarios de forma simultánea. Por ejemplo, probar la aplicación con 100 usuarios.
Pruebas de rendimiento: Calcular la respuesta a la aplicación con diferentes números de usuario. Probar la aplicación con 1, 10 o 100 usuarios.
Pruebas de estrés: comprobar cuántos usuarios puede soportar una aplicación de manera simultánea sin presentar errores.
 
6. ¿Cuáles son los niveles de severidad de los bugs?
El tester debe de ser capaz de diferenciar el nivel de severidad de un bug. Un bug es un error en el código del programa que provoca que el sistema no funcione correctamente.
Los niveles de severidad son...
Bajo: el error no provocará una avería notable del sistema
Menor: resulta en algún comportamiento inesperado o no deseado, pero no lo suficiente como para interrumpir el funcionamiento del sistema
Mayor: error capaz de colapsar grandes partes del sistema
Crítico: error capaz de desencadenar el apagado completo del sistema
 
7. ¿Has hecho pruebas automatizadas?
Las pruebas automatizadas, son pruebas que se han automatizado a través de herramientas de software y que se pueden ejecutar sin intervención humana.
Esta pregunta, es en especial importante si el tester tiene que realizar pruebas automatizadas para el puesto. Aunque no todo el testing que se hace es automatizado, es una tendencia que se está viendo cada vez más en las empresas.
 
8. ¿Qué herramientas utilizas para realizar pruebas automatizadas?
Algunas de las herramientas utilizadas para realizar testing automatizado son:
Selenium
Katalon Studio
UFT One
TestComplete
SoapUI
Appium
 
9. ¿Cómo reportarías un error?
Cada empresa tiene una metodología para reportar un error al equipo de desarrollo. Algunas de los puntos más básicos que debería de incluir el reporte de un error son:
Descripción del error
Pasos a seguir para replicar el error. Si el desarrollador quisiera ver el error él mismo, que tiene que hacer para replicarlo.
Resultado aceptable. Lo que debería de suceder en la aplicación si estuviera construido correctamente.
Evidencias del error. Imágenes o video del error.
 
10. ¿Qué haces cuando un programador no está de acuerdo con tu retroalimentación?
Parte del trabajo del tester, es hacerle saber al equipo de desarrollo que hay errores en el código del sistema. A veces el programador puede tomar personal que el tester le diga que su código no está bien. El tester debe de ser capaz de mediar estas situaciones para evitar fricciones en el equipo. Esta pregunta te ayudará a saber cómo el candidato reacciona cuando hay conflictos con sus compañeros de trabajo.

🔥 𝗦𝗤𝗟 (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗤𝘂𝗲𝗿𝘆 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲) 𝗼 𝗟𝗲𝗻𝗴𝘂𝗮𝗷𝗲 𝗱𝗲 𝗖𝗼𝗻𝘀𝘂𝗹𝘁𝗮 𝗘𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗱𝗮 es un poderoso lenguaje muy útil para comunicarse y extraer datos
🔥 Útil en #DataScience
🔥 Saber más sobre qué es SQL: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

𝗩𝗲𝗮𝗺𝗼𝘀 𝗮𝗵𝗼𝗿𝗮 𝗲𝗹 𝗧𝗢𝗣 𝗗𝗘 𝗖𝗨𝗥𝗦𝗢𝗦 𝗚𝗥𝗔𝗧𝗜𝗦:

1️⃣ 𝗦𝗤𝗟 𝗖𝗲𝗿𝘁𝗶𝗳𝗶𝗰𝗮𝗱𝗼 𝗲 𝗶𝗻𝘁𝗲𝗿𝗮𝗰𝘁𝗶𝘃𝗼
👉No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
¿Te interesa el Análisis de Datos? ¿Estás adentrándote en el fascinante mundo del Data Science? ¿O tal vez estás buscando fortalecer tus habilidades para proyectos FullStack? Independientemente de tu objetivo, el dominio de SQL es crucial en el mundo tecnológico actual.


2️⃣ 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘁𝗼 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗤𝘂𝗲𝗿𝘆 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 (𝗦𝗤𝗟)
👉No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Pasos para instalar un editor de texto, MAMP o XAMPP y creación de MySQL database, además de la sintáxis básica del lenguaje SQL, y mucho más

3️⃣ 𝗦𝗤𝗟 𝗳𝗼𝗿 𝗗𝗮𝘁𝗮 𝗦𝗰𝗶𝗲𝗻𝗰𝗲
👉No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
- Útil para quien no tenga NINGÚN/CASI NINGÚN conocimiento en SQL❗❗
- fundamentos de SQL y trabajo con datos
- Aprenderás a crear tablas, operadores comunes, combinación de datos y escribir consultas simples y complejas para seleccionar, entre otras cosas

4️⃣ 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘁𝗼 𝗦𝗤𝗟 𝗳𝗼𝗿 𝗕𝗶𝗴𝗤𝘂𝗲𝗿𝘆 𝗮𝗻𝗱 𝗖𝗹𝗼𝘂𝗱 𝗦𝗤𝗟
👉No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
- Identificación de componentes y jerarquías de BigQuery
- Creación de una nueva instancia Cloud SQL y carga de tu archivo CSV como una nueva tabla
- Utilización del Create Database, Create Table, Delete, Insert Into, y Union en Cloud SQL

5️⃣ 𝗙𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻𝘀 𝗳𝗼𝗿 𝗕𝗶𝗴 𝗗𝗮𝘁𝗮 𝗔𝗻𝗮𝗹𝘆𝘀𝗶𝘀 𝘄𝗶𝘁𝗵 𝗦𝗤𝗟
👉 No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
- Uso de SQL para Big Data y conceptos clave base
- Características del Big Data y herramientas de SQL para trabajar en plataformas de Big Data
- Exploración inicial de databases y tablas en un ambiente de ejercicios virtual

𝗦𝗤𝗟 𝗳𝗼𝗿 𝗗𝗮𝘁𝗮 𝗦𝗰𝗶𝗲𝗻𝗰𝗲 𝘄𝗶𝘁𝗵 𝗥
👉No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
- Comenzando con SQL
- Introducción a Base de datos relacionales y tablas
- SQL intermedio
-Comenzando con bases de datos usando R

La documentación es un pilar fundamental en el mundo de las pruebas de software. Ayuda a mantener el control, la trazabilidad y la calidad del proceso, y permite a todos los miembros del equipo trabajar de manera coordinada. Si alguna vez te has preguntado cómo se lleva a cabo este importante trabajo, aquí te dejo una visión general de los pasos que un tester sigue en la creación de la documentación:

1️⃣ No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Todo comienza con la creación de un plan de pruebas. En este acuerdo, se establece la hoja de ruta para el proyecto, describiendo el alcance, roles y responsabilidades, cronograma, criterios de entrada y salida, y más.

2️⃣ Casos de Prueba: Los casos de prueba son instrucciones detalladas para probar diversos escenarios. Estos incluyen datos, precondiciones, trazabilidad y etiquetas que ayudan a los testers a abordar distintos aspectos del software. Link para No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Link para ejecutar los No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

3️⃣ Documentación de Configuración: Antes de comenzar las pruebas, se debe preparar el entorno. La documentación de configuración detalla cómo configurar el entorno y realizar una verificación de preparación para garantizar que esté listo para las pruebas.

4️⃣ Reporte de Defectos: Cuando se encuentran errores en el software, es crucial documentarlos adecuadamente. Esto incluye información sobre cómo reproducirlos, el entorno, evidencia, prioridad, severidad y más.

5️⃣ Informes de Ejecución de Pruebas: Los informes de ejecución proporcionan un resumen de las pruebas realizadas, incluyendo los resultados y los defectos identificados. Estos informes son esenciales para tomar decisiones informadas sobre el lanzamiento del software.

6️⃣ Documentación de Pruebas de Regresión: Para asegurarse de que los cambios no afecten las funcionalidades existentes, se documentan las pruebas de regresión, sus resultados y cualquier defecto encontrado.

7️⃣ Documentación de Pruebas de Carga y Rendimiento: Las pruebas de carga y rendimiento evalúan el comportamiento del sistema bajo diferentes cargas de trabajo. Aquí se registran las pruebas realizadas, los resultados y las recomendaciones para mejorar el rendimiento.

8️⃣ Manuales de Usuario: En ocasiones, los testers contribuyen a la creación de manuales de usuario, proporcionando instrucciones detalladas para los usuarios finales. Esto reduce la probabilidad de errores y mejora la satisfacción del cliente.

La documentación en las pruebas de software es un proceso meticuloso que garantiza la calidad y la confiabilidad del software que utilizamos a diario. Los testers desempeñan un papel crucial en este proceso, asegurándose de que cada detalle se registre y se utilice para tomar decisiones informadas.

😀 Antes de sumergirte en el emocionante mundo de las pruebas de APIs con Postman, es fundamental dominar algunos conocimientos clave. Aquí te comparto 5 puntos esenciales:

📚 Conoce los #métodos que se pueden utilizar para cada acción en las peticiones. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

📊Familiarízate con los #códigos de respuesta. No es necesario memorizarlos todos, pero sí saber que existen códigos específicos para diferentes acciones. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

🔍 Aprende a #identificar y #diferenciar entre parámetros de consulta (query param) y parámetros de ruta (path param) y cuándo utilizar cada uno. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

📦El formato #JSON es tu aliado. Conócelo a fondo, ya que es el más utilizado para enviar y recibir datos en las peticiones. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

🔒 Para una #seguridad óptima, no puedes pasar por alto el Top 10 de #OWASP para APIs. Conoce las mejores prácticas de seguridad. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

👩�💻 Tener estos conocimientos te permitirá ser un experto en pruebas de APIs y asegurar la calidad en tus proyectos. 🚀

Y estos son los principios SOLID de una manera mejor explicada



Los 5 principios SOLID de diseño de aplicaciones de software son:

•   S – Single Responsibility Principle (SRP)
•   O – Open/Closed Principle (OCP)
•   L – Liskov Substitution Principle (LSP)
•   I – Interface Segregation Principle (ISP)
•   D – Dependency Inversion Principle (DIP)

Entre los objetivos de tener en cuenta estos 5 principios a la hora de escribir código encontramos:

•   Crear un software eficaz: que cumpla con su cometido y que sea robusto y estable.
•   Escribir un código limpio y flexible ante los cambios: que se pueda modificar fácilmente según necesidad, que sea reutilizable y mantenible.
•   Permitir escalabilidad: que acepte ser ampliado con nuevas funcionalidades de manera ágil.

En este sentido la aplicación de los principios SOLID está muy relacionada con la comprensión y el uso de patrones de diseño, que nos permitirán mantener una alta cohesión y, por tanto, un bajo acoplamiento de software.

¿Qué son la cohesión y el acoplamiento?

Son dos conceptos muy relevantes a la hora de diseñar y desarrollar software. Veamos en qué consisten.

Acoplamiento

El acoplamiento se refiere al grado de interdependencia que tienen dos unidades de software entre sí, entendiendo por unidades de software: clases, subtipos, métodos, módulos, funciones, bibliotecas, etc.
Si dos unidades de software son completamente independientes la una de la otra, decimos que están desacopladas.

Cohesión

La cohesión de software es el grado en que elementos diferentes de un sistema permanecen unidos para alcanzar un mejor resultado que si trabajaran por separado. Se refiere a la forma en que podemos agrupar diversas unidades de software para crear una unidad mayor.

1. Principio de Responsabilidad Única
"A class should have one, and only one, reason to change."
La S del acrónimo del que hablamos hoy se refiere a Single Responsibility Principle (SRP). Según este principio "una clase debería tener una, y solo una, razón para cambiar". Es esto, precisamente, "razón para cambiar", lo que Robert C. Martin identifica como "responsabilidad".
El principio de Responsabilidad Única es el más importante y fundamental de SOLID, muy sencillo de explicar, pero el más difícil de seguir en la práctica.
El propio Bob resume cómo hacerlo: "Gather together the things that change for the same reasons. Separate those things that change for different reasons", es decir: "Reúne las cosas que cambian por las mismas razones. Separa aquellas que cambian por razones diferentes".

2. Principio de Abierto/Cerrado

"You should be able to extend a classes behavior, without modifying it."
El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro "Object Oriented Software Construction" y dice: "Deberías ser capaz de extender el comportamiento de una clase, sin modificarla". En otras palabras: las clases que usas deberían estar abiertas para poder extenderse y cerradas para modificarse.
En su blog Robert C. Martin defendió este principio que a priori puede parecer una paradoja. Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de desarrollar clases, librerías o frameworks.

3. Principio de Sustitución de Liskov

"Derived classes must be substitutable for their base classes."
La L de SOLID alude al apellido de quien lo creó, Barbara Liskov, y dice que "las clases derivadas deben poder sustituirse por sus clases base".
Esto significa que los objetos deben poder ser reemplazados por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema o lo que es lo mismo: si en un programa utilizamos cierta clase, deberíamos poder usar cualquiera de sus subclases sin interferir en la funcionalidad del programa. 
Según Robert C. Martin incumplir el Liskov Substitution Principle (LSP) implica violar también el principio de Abierto/Cerrado.

4. Principio de Segregación de la Interfaz

"Make fine grained interfaces that are client specific."
En el cuarto principio de SOLID, el tío Bob sugiere: "Haz interfaces que sean específicas para un tipo de cliente", es decir, para una finalidad concreta.
En este sentido, según el Interface Segregation Principle (ISP), es preferible contar con muchas interfaces que definan pocos métodos que tener una interface forzada a implementar muchos métodos a los que no dará uso.

5. Principio de Inversión de Dependencias

"Depend on abstractions, not on concretions."
Llegamos al último principio: "Depende de abstracciones, no de clases concretas".
Así, Robert C. Martin recomienda:

1.   Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.
2.   Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.

El objetivo del Dependency Inversion Principle (DIP) consiste en reducir las dependencias entre los módulos del código, es decir, alcanzar un bajo acoplamiento de las clases.





Críticas a SOLID

El ámbito del desarrollo de software es un terreno de continuo debate y SOLID no se queda fuera de la controversia.

Aunque estos cinco principios son considerados por muchos como una base fundamental de un buen desarrollo o al menos como una guía a tener en cuenta, no son pocos los profesionales que critican los principios SOLID.

Los acusan de ambiguos, confusos, de complicar el código, de demorar el proceso de desarrollo y los tildan incluso de totalmente equivocados e innecesarios.

Aquí tienes un par de ejemplos de estas críticas:
•   The SOLID Design Principles – Absolute Nonsense
•   Why Every Element of SOLID is Wrong
Y como a toda acción le corresponde una reacción, las respuestas en defensa de SOLID:
•   In Defense of the SOLID Principles
•   Why Every Single Argument of Dan North is Wrong



Los principios SOLID son eso: principios, es decir, buenas prácticas que pueden ayudar a escribir un mejor código: más limpio, mantenible y escalable.

Como indica el propio Robert C. Martin en su artículo "Getting a SOLID start" no se trata de reglas, ni leyes, ni verdades absolutas, sino más bien soluciones de sentido común a problemas comunes. Son heurísticos, basados en la experiencia: "se ha observado que funcionan en muchos casos; pero no hay pruebas de que siempre funcionen, ni de que siempre se deban seguir."

Dice el tío Bob, que SOLID nos ayuda a categorizar lo que es un buen o mal código y es innegable que un código limpio tenderá más a salir airoso del "control de calidad de código" WTFs/Minute. Consejo: cuando estés revisando un código, lleva la cuenta de cuántas veces por minuto sale de tu boca un WTF?

Hoy comparto un tema que me ha ayudado mucho en mi trabajo...




Los 5 principios SOLID son fundamentales para crear software de calidad:

1️⃣ S - Single Responsibility Principle (SRP): Cada clase debe tener una única razón para cambiar. ¡Sé enfocado!
2️⃣ O - Open/Closed Principle (OCP): El software debe estar abierto para la extensión pero cerrado para la modificación. ¡Sé flexible!
3️⃣ L - Liskov Substitution Principle (LSP): Las subclases deben ser sustituibles por sus clases base. ¡Sé compatible!
4️⃣ I - Interface Segregation Principle (ISP): Los clientes no deben verse obligados a depender de interfaces que no utilizan. ¡Sé específico!
5️⃣ D - Dependency Inversion Principle (DIP): Depende de abstracciones, no de implementaciones. ¡Sé adaptable!


Al aplicar estos principios, logramos:
💡 Software eficaz y robusto
🧹 Código limpio y flexible
🚀 Escalabilidad ágil


En resumen, desarrollamos software de calidad. 💯

La aplicación de SOLID se relaciona con patrones de diseño, manteniendo alta cohesión y bajo acoplamiento. 🧩

¿Que testeo si me piden hacer testing de UX?

Además de la usabilidad, hay varias pautas que podés revisar para evaluar y
mejorar la experiencia de usuario (UX) de un software.

Las más utilizadas son:

Hola gente, les traigo una herramienta muy simple para trabajar, No tienes permitido ver los links. Registrarse o Entrar a mi cuenta registra todo lo

que hace tu aplicación y te proporciona una nueva óptica de depuración. La grabación es una

combinación de video, código fuente de su aplicación, instantáneas de DOM y herramientas de

desarrollo habilitadas para viajar en el tiempo que le permiten agregar retroactivamente

declaraciones impresas a la ejecución de su aplicación.

Se puede integrar tanto en Cypress como en Playwright.

No la dejes de ver y probar...

Hola Underc0ders, hoy quiero compartir estos consejos geniales de una gran persona, lo dejo a continuación y espero sus opiniones, al final les dejo el nombre de la profesional que lo aportó:




📩 Consejos rápidos para tu próxima postulación vía mail.

Hoy quisiera brindarles algunos tips para sus próximas #postulaciones.

✅ Recuerda siempre cambiar el nombre del archivo de tu CV y guardarlo con tu nombre, apellido y perfil profesional, por ejemplo: Juan Díaz - Técnico en Seguridad & Hogiene.

✅ Es importante que además tu CV esté guardado en formato PDF.

✅ En el asunto del mail coloca el nombre de la posición a la cuál te estás postulando o en caso de tener un número de Ref la postulación también podrías colocarla, por ejemplo:
Postulación Ref 9120 - H&S.

✅ Utiliza el cuerpo del mail para presentarte, remarcar algunas skills necesarias para el rol e interés en el mismo.
Además puedes marcar en negrita aquellas palabras claves para llevar la atención de tu lector.
Si queres, podes utilizar el siguiente formato para tu presentación:

✔️ Saludo
✔️ Breve presentación profesional.
✔️ Habilidades o skills requeridas para el rol.
✔️ Interés en el puesto empresa.

❌ No hace falta que adjuntes tus certificados de cursos o diferentes estudios, con que estén colocados en tu CV es suficiente.

✅ Puedes personalizar una firma y en el caso de tener un portafolio, perfil de Github y/o Linkedln puedes colocar los enlaces con accesos directos.

✅ Si te encontras en búsqueda activa, podes armar un Excel para ir teniendo un seguimiento de tus postulaciones y ayudarte ( te doy un tip, si usas MailTrack, extensión de Chrome, te notifica sobre quién leyó tu mail).

🙌🏼 Por último, se que estamos atravesando momentos muy complicados como país y puede que hoy no estés muy motivado buscando empleo.
Sin embargo, quiero decirte que espero que pronto recibas ese mensaje sobre que fuiste contratado.

Repetilo como un mantra: BUSCAR TRABAJO ES UN TRABAJO.


Info proporcionada por: Maria Celina de Irureta Aguilar (Lic. en Psicología)

Las pruebas de rendimiento son un subconjunto de la ingeniería de rendimiento. Es un proceso de evaluación del comportamiento de un sistema bajo diversas condiciones extremas. El objetivo principal de las pruebas de rendimiento es monitorear y mejorar los indicadores clave de rendimiento, como el tiempo de respuesta, el rendimiento, la memoria, la utilización de la CPU y más.

Hay tres objetivos (tres S) de las pruebas de rendimiento que se deben observar y evaluar: Speed, Scalability y Stability.

A continuación se detallan los tipos de pruebas de rendimiento más utilizados, entre otros:

Prueba de carga

Pruebas de estrés

Prueba de picos

Pruebas de resistencia

Prueba de volumen

Pruebas de escalabilidad

Prueba de capacidad


La prueba de carga es un tipo de prueba de rendimiento. Ayuda a evaluar la aplicación bajo comportamientos de prueba, como el tiempo de respuesta, el rendimiento, las transacciones de aprobación/falla y más bajo la carga de trabajo normal. por ejemplo, el tiempo de respuesta de pago del carrito es de 500 milisegundos en el horario comercial habitual.


Lighthouse



Webpage Test



Gatling



K6



Artillery



JMeter



Locust

Artillery es un conjunto de herramientas de prueba de rendimiento moderno, potente y fácil de usar. Úselo para enviar aplicaciones escalables que mantengan su rendimiento y resistencia bajo cargas elevadas.

Artillery prioriza la productividad y la felicidad de los desarrolladores y sigue la filosofía de "baterías incluidas".


Características

Emule el comportamiento complejo del usuario con escenarios

Pruebas de carga y pruebas de humo.

Baterias incluidas

Extensible y pirateable

Integraciones y complementos

Diseñado para la colaboración entre equipos

Pruebas a escala planetaria




Más información en la página de No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Primeros pasos con la configuración de Playwright

Requisitos previos:

1 - Instale Visual Studio Code: descargue e instale Visual Studio Code (No tienes permitido ver los links. Registrarse o Entrar a mi cuenta).

2 - Instalar NodeJS: Descargar e instalar No tienes permitido ver los links. Registrarse o Entrar a mi cuenta.


A continuación en 8 pasos te voy a mostrar como instalarlo para que puedas usarlo:

Paso 1: cree un directorio nuevo (por ejemplo, Playone) en VSCode

Paso 2: abra el directorio en Visual Studio Code. Desde el código VS,

Haga clic en Archivo > Abrir carpeta > Elegir carpeta recién creada (Playone)

Paso 3: desde VS Code, haga clic en Menú Terminal > Haga clic en Nueva Terminal

Paso 4: Ingrese el siguiente comando para iniciar la instalación de Playwright

npm init playwright@latest

El comando anterior realiza la siguiente operación:

* Crea paquete.json

* Instala la biblioteca npm

* Configura archivos y carpetas básicos:

Carpeta de pruebas: esta carpeta contiene scripts de prueba reales. De forma predeterminada, se creará un archivo example.spec.ts dentro de esta carpeta.

.gitignore: este archivo ayuda si está utilizando el repositorio git

package.json y package-lock.json: este archivo ayuda a rastrear dependencias, crear un acceso directo para ejecutar pruebas, etc.

playwright.config.ts: este es el archivo de configuración global de Playwright, que puede configurar con las opciones disponibles.



Paso 5: instalar navegadores
Playwright está configurado para ejecutarse en navegadores existentes, lo que puede crear problemas al ejecutar las pruebas, por lo que se recomienda utilizar los navegadores Playwright. Usando el siguiente comando, puede instalar todos los navegadores diferentes en Playwright.

npx playwright install

Paso 6: crea la primera prueba de playwright

Navegue dentro de la carpeta de pruebas y cree un archivo de especificaciones de prueba, por ejemplo: demo.spec.ts

Comencemos un caso de prueba con el siguiente escenario.

Guión:

 - Navegue a No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

 - Verifique que el mensaje de error se muestre o no.
El demo.spec.ts es nuestro script de prueba de Playwright de la siguiente manera

//demo.spec.ts

import { test, expect, Page } from '@playwright/test';

test.beforeEach(async ({ page }) => {

  await page.goto('www.playwright.dev');

});

Paso 7: ejecutar el script de prueba de playwright

Como se mencionó anteriormente, durante la instalación, Playwright crea playwright.config.ts ( playwright.config.ts es el archivo de configuración global) que tendrá algunas configuraciones. De forma predeterminada, la configuración global contiene el valor que se ejecutará en todos los navegadores. Se ejecuta en los tres navegadores diferentes cuando ejecuta la prueba Playwright. No lo necesitamos, por lo que debemos eliminar esa opción.

Navegue hasta playwright.config.ts . Comenta la opción que comienza con proyectos: [
Si desea hacer lo anterior, copie y pegue la siguiente línea de código en playwright.config.ts

//playwright.config.ts

import type { PlaywrightTestConfig } from '@playwright/test';

const config: PlaywrightTestConfig = {

  testDir: './tests',

  timeout: 30 * 1000,

  expect: {

    timeout: 5000

  },

  reporter: 'html',

  use: {

    actionTimeout: 0,

    trace: 'on-first-retry',

  },

};

export default config;

Entonces, ha configurado playwright.config.ts y estamos listos para ejecutar el primer script de prueba de Playwright.

Ejecute Playwright Spec usando el siguiente comando

npx playwright test  demo.spec.ts –headed

Entendamos el comando anterior:

* Estamos especificando qué archivo de prueba necesitamos ejecutar, es decir , demo.spec.ts. No mencione ningún nombre de archivo de especificaciones si desea ejecutar todos los archivos de especificaciones dentro de la carpeta de pruebas, no mencione ningún nombre de archivo de especificaciones.

* Playwright se ejecuta en modo sin cabeza de forma predeterminada, por lo que especificamos –headed para que se ejecute en modo con cabeza.

* No mencionamos ningún nombre de navegador; De forma predeterminada, la prueba Playwright se ejecuta en el navegador Chromium.

Una vez que ejecuta el comando anterior, las pruebas de Playwright comienzan a ejecutarse en el navegador Chromium.

Little Example:

Paso 8: ver el informe

En nuestro playwright.config.ts , especificamos el informe HTML, por lo que después de ejecutar la prueba Playwright, el informe HTML se genera automáticamente en la carpeta playwright-report .

Para ver el informe HTML generado simplemente escriba:

npx playwright show-report

Ejemplo---->










Espero que te sirva y puedas hacer muchas automatizaciones con este nuevo framework.

Saludos

Playwright es una biblioteca de automatización de pruebas de código abierto desarrollada inicialmente por colaboradores de Microsoft. Admite lenguajes de programación como Java, Python, C# y NodeJS. Playwright viene con licencia Apache 2.0 y es más popular con NodeJS con Javascript/Typecript. Este tutorial de Playwright le ayudará a configurar NodeJS utilizando Visual Studio Code.


Aunque Playwright es nuevo en el mercado, difícilmente podemos enumerar las limitaciones, ya que admite varios idiomas. Las personas que quieran migrar de Selenium a Playwright pueden hacerlo rápidamente ya que Playwright admite C#, Java y Python. Los lenguajes de programación no son una barrera. El primer lanzamiento de Playwright fue en enero de 2020 y desde entonces ha ganado mucha popularidad.

• Aprovecha el protocolo DevTools para escribir pruebas automatizadas potentes y estables.[/size
• Puede ver y controlar el navegador en lugar de depender de una capa de traducción intermedia; permite la simulación de escenarios de usuario más reveladores y relevantes.

Los colaboradores de los dramaturgos son muy activos en el lanzamiento de nuevas funciones cada mes, que se enumeran a continuación:

• Fácil instalación y configuración: al ser un marco de automatización de pruebas , solo necesita una configuración ya que la instalación no lleva mucho tiempo. Dependiendo del idioma que usemos con Playwright, los pasos de instalación pueden cambiar
• Compatibilidad con varios navegadores: todos los navegadores de la familia Chromium (Chrome, Edge), Webkit (Safari) y Firefox son compatibles.
• Compatibilidad con varios idiomas: Playwright admite Java, C#, Python, Javascript/Typecript, lo que la convierte en una opción popular. La mayoría de los marcos modernos de automatización de pruebas de código abierto omiten esta característica.
• Tipos de pruebas: Playwright admite pruebas funcionales, de extremo a extremo y de API. Con un complemento de terceros, Playwright se puede integrar con Accessibility Testing .
• Pruebas de navegador paralelo: Playwright también admite la ejecución de pruebas simultáneas (también conocidas como  pruebas paralelas ) a través del contexto del navegador y puede ejecutar pruebas paralelas con varios navegadores. Esto amplía las pruebas y resulta útil cuando se deben probar varias páginas web simultáneamente.
• Compatibilidad con múltiples pestañas/ventanas del navegador: Playwright admite múltiples pestañas y múltiples ventanas . Algunos casos de prueba deben verificar el escenario iniciando una nueva ventana y regresando a la ventana principal. Playwright admite todos los diferentes tipos de casos de prueba.
• Reporteros integrados: el marco Playwright, de forma predeterminada, viene con muchos reporteros valiosos como List, Dot, Line, JSON, JUnit y HTML Reporters. Lo interesante es que con Playwright, uno puede crear reporteros personalizados. Playwright también apoya al reportero externo Allure Report.
• Compatibilidad con mecanografiado lista para usar: no se requiere configuración para la compatibilidad con el lenguaje mecanografiado, ya que comprende su código mecanografiado y javascript.
• Soporte de integración CI/CD: Playwright admite la integración CI/CD. Incluso proporciona imágenes acoplables para algunos enlaces de idiomas.
• Compatibilidad con herramientas de depuración: las pruebas de Playwright admiten diferentes opciones de depuración, lo que las hace fáciles de usar para los desarrolladores. Algunas opciones de depuración son Playwright Inspector, VSCode Debugger, Browser Developer Tools y Trace Viewers Console Logs.

• Soporte de marco flotante
• Soporte para el modelo de objetos de página
• Reporteros incorporados
• Patrón de objeto de página
• Soporte de navegación entre orígenes
• Soporte de selectores
• DOM en la sombra
• Espera automática
• Soportes de ejecución de pruebas de terceros
• Vídeos y captura de pantalla
• Emulación del navegador
• reintento de prueba,
• Proyecto parametrizado, etc.

Si te llamó la atención, te gusta programar y testear, no te lo pierdas.

Pronto voy a realizar un post de este tema

A continuación, te proporcionaré una guía paso a paso para crear una API de prueba simple utilizando Django Rest Framework (DRF), que es una potente biblioteca para crear APIs RESTful en Django.



Paso 1: Configuración del entorno Asegúrate de tener Python instalado en tu sistema. Luego, puedes crear un entorno virtual para tu proyecto:

python -m venv myenv

Activa el entorno virtual:

•    En Windows:

myenv\Scripts\activate

•    En macOS y Linux:
 

source myenv/bin/activate

Paso 2: Instala Django y Django Rest Framework Dentro del entorno virtual, instala Django y Django Rest Framework:

pip install django
pip install djangorestframework

Paso 3: Crea un nuevo proyecto Django Crea un nuevo proyecto Django:

django-admin startproject projectname

Reemplaza projectname con el nombre de tu proyecto.

Paso 4: Crea una aplicación Dentro del proyecto, crea una nueva aplicación:

cd projectname python manage.py startapp myapp

Paso 5: Configura la aplicación en tu proyecto Agrega la aplicación recién creada al archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta de tu proyecto:

INSTALLED_APPS = 
[ # ...
'myapp',
'rest_framework', 
]

Paso 6: Define un modelo En el archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta de tu aplicación, define un modelo que represente los datos que deseas exponer a través de la API. Por ejemplo:

from django.db import models
 
    class Item(models.Model): 
    name = models.CharField(max_length=100) 
    description = models.TextField() 
    def __str__(self): 
    return self.name 

Paso 7: Crea migraciones y aplica los cambios a la base de datos Ejecuta los siguientes comandos para crear migraciones y aplicar los cambios a la base de datos:

python manage.py makemigrations 
python manage.py migrate

Paso 8: Crea un serializador En tu aplicación, crea un archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y define un serializador para el modelo Item:

from rest_framework import serializers
from .models import Item

class ItemSerializer(serializers.ModelSerializer):
   class Meta: model = Item 
   fields = '__all__'

Paso 9: Crea vistas y rutas (URLs) En tu aplicación, crea un archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y define una vista utilizando DRF:

from rest_framework import generics
from .models import Item
from .serializers import ItemSerializer 

class ItemList(generics.ListCreateAPIView): 
    queryset = Item.objects.all() 
    serializer_class = ItemSerializer

Luego, configura las rutas (URLs) en el archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta de tu aplicación:

from django.urls import path
from .views import ItemList 
urlpatterns = [ 
        path('items/', ItemList.as_view(), name='item-list'), 
]

Paso 10: Ejecuta el servidor de desarrollo Inicia el servidor de desarrollo de Django para probar tu API:

python manage.py runserver

Ahora puedes acceder a tu API en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta. Puedes usar herramientas como curl, httpie, o un navegador web para realizar solicitudes a la API y probar su funcionalidad.
Este es un ejemplo simple de cómo crear una API de prueba con Python y Django utilizando el Django Rest Framework. Puedes agregar más modelos, vistas y funcionalidades según tus necesidades específicas.

En el mundo del desarrollo, la práctica hace al maestro. Es por eso que debes encontrar todas las formas posibles de practicar. En este blog te explicaremos 6 APIs públicas y gratuitas que te ayudarán a hacer todo tipo de pruebas y desarrollar prototipos de aplicaciones frontend.


1. API de Marvel

Esta es la favorita de muchos devs. Para poder usarla, solo debes registrarte en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y podrás consumir todo el contenido de Marvel como los personajes, los comics, las películas, los videojuegos y mucho más.



2. PokéAPI

Esta API posee una documentación muy bien detallada para que aprendas a consumirla. Además, tiene mucha información de los Pokémon como sus movimientos, habilidades, tipos, poderes, habitad y más. Con esta API puedes crear fácilmente un pokedex 😁.

¡Ingresa a No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y comienza a usarla ahora!



3. COVID Tracking

¿Quieres hacer algo más serio? entonces la API COVID Tracking es para ti. Consume datos del COVID-19 de todo el mundo como número de contagios, pruebas, pacientes hospitalizados, fallecidos y mucho más. Ingresa No tienes permitido ver los links. Registrarse o Entrar a mi cuenta para comenzar a usarla.



4. Nomics

Si lo que necesitas hacer es económico, entonces entra a No tienes permitido ver los links. Registrarse o Entrar a mi cuenta y podrás consumir los datos de las principales criptomonedas del mundo. Es decir, sus precios, cambios y predicciones. Con esta información podrás crear aplicaciones móviles, bots comerciales, gráficos y mucho más. ¡Solo debes generar tu clave API gratis!



5. OpenWeather APIs

Esta es una de las mejores APIs para obtener información del clima, como los datos meteorológicos del día y de los años anteriores, previsión climática, radiación solar, e incluso, podrás consumir una colección de mapas. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



6. No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Proporciona una API de prueba que simula una API RESTful para realizar operaciones CRUD (Crear, Leer, Actualizar, Borrar) en datos ficticios, ideal para prácticas de desarrollo y pruebas de API.

porque no aparece el buscador de cypress en algunos módulos de las páginas, ejemplo el register de mercado pago

📦 CAJA NEGRA: En lugar de examinar el código fuente, los testers se centran en probar las entradas y salidas esperadas del sistema.

✅ EJ: Tienes una aplicación de calculadora en tu teléfono. Quieres asegurarte de que funcione correctamente, pero no necesitas saber cómo está programada internamente. Eso es una prueba de caja negra.

📦 CAJA BLANCA: Los testers conocen la estructura interna del software. El objetivo es evaluar cómo se procesan los datos y cómo interactúan los diferentes componentes dentro del sistema. Tenemos acceso a "Base de Datos, Apis y Código"

✅ EJ: Revisar el código fuente de una función de sumar en un programa y diseñar casos de prueba para verificar si maneja correctamente diferentes tipos de números.

📦 CAJA GRIS: Son un equilibrio entre las pruebas de caja blanca y caja negra, aprovechando el conocimiento parcial del sistema para diseñar pruebas que aborden tanto la funcionalidad externa como la lógica interna del software.

✅ EJ: Imagina que estás probando una app GPS y sabes que el software considera tanto la distancia como el tráfico en sus cálculos de ruta, pero no tienes acceso al código exacto del algoritmo. Diseñas casos de prueba utilizando ubicaciones cercanas y lejanas en diferentes momentos del día para evaluar si las rutas recomendadas son precisas y eficientes.

La automatización de pruebas de aplicaciones web es esencial en el desarrollo de software para garantizar la calidad y el rendimiento. Dos herramientas populares para este propósito son Cypress y Playwright, cada una con sus propias ventajas y características únicas. A continuación, comparamos ambas herramientas para ayudarte a tomar una decisión informada.

Aspecto	Cypress	Playwright
Browser	Principalmente para Chrome y Electron.	Admite varios navegadores, incluyendo Chrome, Firefox, WebKit (Safari), y más.
Lenguaje de Programación	JavaScript	JavaScript, TypeScript, Python, C# (según el lenguaje de la biblioteca)
Facilidad de Uso	Sintaxis simple y fácil de aprender.	Sintaxis intuitiva y fácil de aprender.
Velocidad de Ejecución	Rápido y eficiente para aplicaciones pequeñas y medianas.	Rápido y eficiente para aplicaciones de cualquier tamaño.
Comunidad y Soporte	Comunidad activa y buena documentación.	Comunidad creciente y documentación sólida.
Herramientas de Depuración	Ofrece Cypress Dashboard para ver y depurar resultados.	Permite la depuración en el propio navegador, lo que facilita la identificación de problemas.
Grabación y Reproducción	No se centra en grabación/reproducción, se enfoca en escritura de código.	No se centra en grabación/reproducción, se enfoca en escritura de código.
Aplicaciones Soportadas	Principalmente aplicaciones web de un solo dominio.	Aplicaciones web de un solo dominio y aplicaciones nativas de escritorio y móviles (Playwright for Python y C#).
Automatización de Navegación	Automatiza la navegación y las interacciones del usuario.	Automatiza la navegación y las interacciones del usuario, así como tareas de nivel de página como la captura de pantallas.
Flexibilidad	Altamente flexible para personalizar pruebas.	Altamente flexible, permite la personalización a nivel de red y más.
Herramientas de Pruebas Paralelas	Requiere Cypress Dashboard o herramientas de terceros para pruebas paralelas.	Soporte nativo para pruebas paralelas.
Licencia	Código abierto, licencia MIT.	Código abierto, licencia Apache 2.0.

Pros de Playwright

• Soporte de lenguajes (JS, Python, Java, C#)
• Ejecución de pruebas en paralelo (también puede probar varios navegadores en paralelo)
• Soporte multipestaña
• Compatibilidad entre dominios
• Soporte para iframes
• Safari WebKit

Pros de Cypress:

• Documentación
• Apoyo de la comunidad (también muchos plugins)
• Esperas estáticas
• Control de redes y pruebas de API
• Admite la nube de dispositivos reales y servidores remotos
• La sintaxis es más fluida

La elección entre Cypress y Playwright depende de tus necesidades específicas, la tecnología de tu aplicación y tus preferencias personales. Ambas son herramientas sólidas para la automatización de pruebas de aplicaciones web y ofrecen distintas ventajas en diferentes áreas.

Como en Cypress y en cualquier nuevo proyecto que vamos a empezar, primero es muy importante tener definido:

•    ¿Cuál es el nombre?

•    El autor

•    ¿Qué librerías se van a usar?

•    Versión entre otros...

Como segunda parte importante, se definen que comandos se van a usar, que modelos van a usar y cuantos van a ser.

Paso a Paso

1. md nameproject    --> crear carpeta del nuevo proyecto

2. cd nameproject    – >entrar a la carpeta

3. npm init    � cypress crea un archive json con toda la descripción del nuevo proyecto

4. Se crea un json---->
�    name
�    version
�    description: Pruebas automatizadas del sistema de sistema de...
�    test command:
�    git repository:
�    keywords: qa, automation, sistema ejemplo, etc.
�    author: Mr. Bones
                                                                                                Nota: se puede ver con type package.json

5. npm install cypress-- > cypress instala todos sus componentes

6. npm cypress run -- > se abre la parte del código de cypress

7. npx cypress open -- > se abre la parte gráfica de cypress
 se hace para configurar cypress y sus carpetas

-->e2e

-->fixtures

-->support

8. git init -- > se usa para crear un nuevo repositorio en github

9. git remote add origin No tienes permitido ver los links. Registrarse o Entrar a mi cuenta -- > a través de la terminal se agrega el repo a nuestro github

10. git add * -- > sube todos los archivos modificados al repositorio git

11. git commit -m "Commit inicial" -- >se pone un mensaje para acordarse o porque trabajamos con gente

12. git push origin master -- > se usa para subir toda la info al repo de git en la red

13. Se agrega en el json del proyecto la url del repositorio  -- >cuando quiera bajarlo otra persona se copia la direccion del git hub

14. git clone (Url del repo a clonar) -- > en el caso de que se quiera clonar el repo y bajarlo nuestro equipo

15. En GitHub, se crea un nuevo proyecto y se arma un tablero Kanban para llevar un control del trabajo del proyecto.

A practicar:

*Usando cualquier e-commerce, se deben realizar los siguientes Test Cases:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

*Ahora probemos con páginas de turnos, por ejemplo, Space (No tienes permitido ver los links. Registrarse o Entrar a mi cuenta), es un entorno de prueba proporcionado por No tienes permitido ver los links. Registrarse o Entrar a mi cuenta, ofrece la oportunidad de explorar y probar su plataforma para pruebas de software.
En este caso tienes que armar los casos de prueba y documentarlos (puedes ayudarte con la tarea anterior)

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
 

Gif a modo de Ejemplo:

Paso a paso:

1 - Se escribe en el prompt un script de un ejemplo de happy path a testear.

2 - Se copia la Url.

3 - Se copia el codigo fuente de la página.

4 - Resultado casi perfecto para hacer copy paste en nuestro VS code.

5 - Por último correr cypress para ver nuestra prueba corriendo. 😎

Y Arrancamos...

    Nuestra arquitectura front-end se basa en el enfoque BFF utilizando Node + React, que combina la velocidad de JavaScript y utiliza nuevas formas de representar sitios web, haciéndolos altamente dinámicos y receptivos para los usuarios. Para ello hacemos uso de GraphQL para solicitar datos al backend.
 
GraphQL se desarrolló para hacer frente a la necesidad de mayor flexibilidad y eficiencia que experimentan los desarrolladores al interactuar con las API REST, lo que hace que el flujo de trabajo sea mucho más eficiente.





Hace un tiempo decidimos empezar a utilizar Cypress, una herramienta que pretende superar a Selenium (o hacerte olvidarlo de inmediato), eliminando todos sus inconvenientes, como la configuración y la depuración. Si quieres profundizar en esta comparativa, aquí puedes leer más.



Cypress es una herramienta de prueba creada para la web moderna. Se pueden ver muchas similitudes entre ellos, pero los beneficios y limitaciones que enfrentará son bastante diferentes dependiendo de cuál utilice. Si lo que busca es facilidad de configuración y depuración, Cypress puede ser una buena opción.

Cypress es un operador de pruebas de código abierto que le permite escribir pruebas en código JavaScript. Puede consultar su repositorio y contribuir a su misión si así lo desea.

En mi caso, cambié de Selenium a Cypress por varias razones. El más importante es que parecía bastante fácil de configurar y trabajar con él, y eso nos permitió desde el control de calidad escalar los esfuerzos de prueba al difundir su uso entre los controles de calidad y los desarrolladores. Dado que utiliza JavaScript, nuestro equipo de desarrollo lo acogió con agrado y comenzó a usarlo casi sin fricciones o básicamente porque no me gusta Java.


Cypress está escrito en JavaScript y te permite escribir pruebas en JavaScript. Una cosa a tener en cuenta es que este framework está construido sobre Mocha, por lo que, si ya está acostumbrado a escribir scripts de prueba utilizando Mocha como marco de prueba, es probable que encuentre algunos viejos amigos aquí.

Cypress adopta de Mocha su sintaxis BDD que encaja muy bien tanto con la integración como con las pruebas unitarias. Otras tecnologías incluidas con Cypress son Chai, Chai-jQuery, Sinon y Sinon-Chai.


Al ejecutar la prueba en modo GUI, vemos lo siguiente:



Lo que hace Cypress es abrir un navegador, luego a la izquierda ves el 'registro en vivo' que refleja todo lo que hace el navegador durante la prueba, y a la derecha tienes la aplicación bajo prueba.

Vale la pena mencionar aquí que Cypress no es una herramienta externa que se comunica con el navegador a través de una API, sino que se ejecuta directamente en el navegador, y esto hace que esté tan cerca de la aplicación web bajo prueba que puedes hacer cosas que quieras.

Una de las características clave aquí es la capacidad de depuración. Cuando la prueba finaliza o falla, el estado no se restablece, lo que significa que puede desplazarse por el 'registro en vivo' para ver qué o dónde estaba haciendo Cypress en ese momento; se muestra una captura de pantalla para ese momento para cada acción. Incluso puede abrir la consola del navegador y obtener una descripción completa de los pasos que seleccione en el registro. Esta característica ha impulsado tanto todo el proceso de desarrollo de pruebas que ahora no podemos prescindir de ella.


Para nuestro sistema de CI utilizamos Brigade, que es una herramienta basada en eventos para ejecutar tareas automatizadas en la nube. Nuestros colegas del equipo de DevOps escribieron una serie de publicaciones sobre cómo funciona esto, por lo que, en caso de que esté interesado, puede profundizar aquí.

Como se comentó al principio del post, dividimos nuestra aplicación en diferentes BFF, lo que nos permite construirlas e implementarlas de forma independiente, lo que hace que el proceso de lanzamiento sea más rápido y fácil de escalar.

Todos estos BFF tienen al menos un repositorio de prueba e2e adjunto, que se activará como un evento diferente cada vez que se fusione una solicitud de extracción.



Este caso anterior ilustra la serie típica de eventos que ocurren al fusionar una nueva solicitud de extracción en nuestro entorno de prueba: canalización BFF. Primero viene el evento push (incluidas las pruebas unitarias  ), luego la implementación en el entorno de prueba y, finalmente, un post_deploy_hook activa las pruebas e2e configuradas. Tenemos Slack integrado en este bucle para notificarnos de cada paso y advertirnos en caso de que algo salga mal.

Las pruebas e2e se almacenan en un repositorio propio (que representan más de 15 repositorios). Enviamos todos los cambios en el código de prueba de e2e a esos repositorios para crear una nueva imagen de Docker que el BFF tomará y ejecutará cada vez que llegue el evento.

Centrándonos en el evento de prueba e2e, el comando que utilizamos para ejecutar las pruebas es:


Analizando brevemente los parámetros:

• grabar: envía las grabaciones de video a Cypress Dashboard para realizar un seguimiento de las ejecuciones
• grupo: Agrupa las pruebas grabadas juntas en una sola ejecución.
• paralelo: Permite la paralelización de las pruebas.
• buildId: necesario para definir una compilación o ejecución única

La última parte del viaje. Cypress Dashboard es un servicio que nos permite acceder a pruebas grabadas, siendo bastante útil cuando las ejecutamos en el CI. Nos brinda información sobre todas las ejecuciones de prueba activadas, incluidos registros, capturas de pantalla y videos.



Aunque podríamos prescindir del Panel, lo encontramos bastante útil y lo utilizamos ampliamente; tenemos un plan pago que permite que varios de nuestros ingenieros tengan acceso a él y trabajen de una manera más eficiente.

Si estás buscando sitios web o aplicaciones en línea para realizar pruebas manuales, hay varios sitios que ofrecen entornos de pruebas donde puedes practicar y mejorar tus habilidades de pruebas exploratorias, usabilidad y más. Aquí tienes algunas opciones:

The Internet Chuck Norris Database: Esta es una página web humorística que te permite buscar datos inventados sobre Chuck Norris. Puede ser un lugar divertido para practicar pruebas de búsqueda y exploración.

Sitio web: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Herokuapp: Herokuapp ofrece una variedad de aplicaciones de muestra para que los testers practiquen sus habilidades en un entorno real. Puedes explorar y probar diferentes aplicaciones para encontrar errores y problemas.

Sitio web: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



The Internet Archive: El Internet Archive es un recurso que te permite explorar y navegar por versiones antiguas de sitios web reales. Puedes usarlo para practicar pruebas en sitios web reales, aunque no todos los enlaces pueden funcionar perfectamente en todas las versiones.

Sitio web:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



The Internet Arcade: Este proyecto del Internet Archive te permite jugar a una amplia variedad de videojuegos clásicos en tu navegador. Puedes probar y explorar diferentes juegos para verificar su funcionalidad.

Sitio web:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



TodoMVC: TodoMVC es un sitio que muestra diferentes implementaciones del mismo proyecto de lista de tareas en varios frameworks JavaScript. Puedes probar la funcionalidad y la usabilidad de estas aplicaciones web.

Sitio web: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



The Guardian: El sitio web de noticias The Guardian ofrece una amplia variedad de artículos y contenido en línea. Puedes explorar y probar diferentes partes del sitio para verificar la navegación y la presentación de contenido.

Sitio web:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Wikipedia: Wikipedia es una enciclopedia en línea colaborativa que contiene una gran cantidad de información en diferentes temas. Puedes explorar y navegar por artículos para practicar pruebas de búsqueda y usabilidad.

Sitio web:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Reddit: Reddit es una plataforma de redes sociales basada en comunidades y foros. Puedes explorar diferentes subreddits para practicar pruebas de interacción, navegación y comentarios.

Sitio web:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta



Estos sitios te ofrecen diversas oportunidades para practicar pruebas manuales en diferentes contextos y tipos de aplicaciones. Recuerda que la práctica constante y la exploración detallada son clave para desarrollar habilidades sólidas de pruebas exploratorias.

Suponiendo que haya instalado Cypress exitosamente y haya abierto Cypress , ahora es el momento de agregar su primera prueba. Haremos esto con el botón Crear new empty spec.



Al hacer clic en él, debería ver un cuadro de diálogo donde puede ingresar el nombre de su nueva especificación. Simplemente acepte el nombre predeterminado por ahora.



La especificación recién generada se muestra en un cuadro de diálogo de confirmación. Simplemente continúa y ciérralo con el botón ✕.



Una vez que hayamos creado ese archivo, debería verlo aparecer inmediatamente en la lista de especificaciones de un extremo a otro. Cypress monitorea sus archivos de especificaciones para detectar cualquier cambio y los muestra automáticamente.



Aunque todavía no hemos escrito ningún código, está bien, hagamos click en su nueva especificación y veamos cómo Cypress la inicia.



Ahora es el momento de escribir tu primera prueba:

1 Escribe tu primer examen aprobado.
2 Actualízalo para que falle.
3 Mira la recarga de Cypress en tiempo real.

Abra el archivo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta en su IDE (ej: Visual Studio Code) y reemplace el contenido de su especificación con el siguiente código.


Una vez que guarde este cambio, debería ver que el navegador se recarga.

Aunque no hace nada útil, ¡esta es nuestra primera prueba que aprobamos! ✅

En el Registro de comandos verá que Cypress muestra la suite, la prueba y su primera afirmación (que debería pasar en verde).



Observe que Cypress muestra un mensaje indicando que esta es la página predeterminada en el lado derecho . Cypress supone que querrás salir y visitar una URL en Internet, pero también puede funcionar bien sin eso.

Ahora escribamos nuestra primera prueba fallida.


Que pasó???

Una vez que guarde nuevamente, verá que Cypress muestra la prueba fallida en rojo ya que trueno es igual a false.

Cypress también muestra el seguimiento de la pila y el marco de código donde falló la aserción (cuando esté disponible). Puede hacer clic en el enlace del archivo azul para abrir el archivo donde ocurrió el error en su abridor de archivos preferido . Para leer más sobre la visualización del error, lea sobre Errores de depuración



si te gustó, aca abajo te dejo un link para que puedas hacer un ejemplo real:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Una prueba sólida generalmente cubre 3 fases:

• Configure el estado de la aplicación.
• Toma una acción.
• Haga una afirmación sobre el estado de la aplicación resultante.

También puede ver esto redactado como "Dado, cuándo, entonces" o "Organizar, actuar, afirmar". Pero la idea es: primero colocas la aplicación en un estado específico, luego realizas alguna acción en la aplicación que hace que cambie y finalmente verificas el estado resultante de la aplicación.

Hoy, analizaremos estos pasos de forma restringida y los asignaremos claramente a los comandos de Cypress:

• Visita una página web.
• Consulta por un elemento.
• Interactuar con ese elemento.
• Afirmar sobre el contenido de la página.

Paso 1: visita una Página

Primero, visitemos una página web. Visitaremos nuestra aplicación Kitchen Sink en este ejemplo para que pueda probar Cypress sin tener que preocuparse por encontrar una página para probar.

Podemos pasar la URL que queremos visitar cy.visit(). Reemplacemos nuestra prueba anterior con la siguiente que realmente visita una página:

describe('Real Test', () => {
  it('Visits the Google', () => {
    cy.visit('No tienes permitido ver los links. Registrarse o Entrar a mi cuenta')
  })
})

Guarde el archivo y vuelva a cambiar a Cypress Test Runner. Es posible que notes algunas cosas:

• • El Registro de comandos ahora muestra la nueva VISITacción.
  • La aplicación Kitchen Sink se ha cargado en el panel Vista previa de la aplicación .
  • La prueba es verde, aunque no hicimos ninguna afirmación.
  • Muestra VISITun estado pendiente azul hasta que la página termine de cargarse.

Si esta solicitud hubiera regresado con un código sin estado como 404 o 500, o si hubiera un error de JavaScript en el código de la aplicación, la prueba habría fallado.Paso 2: Consulta de un elementoAhora que tenemos una página cargada, debemos realizar alguna acción al respecto. ¿Por qué no hacemos click en un enlace de la página? Suena bastante fácil, busquemos uno que nos guste... ¿qué tal Gmail?Para encontrar este elemento por su contenido, usaremos cy.contains() .Agreguémoslo a nuestra prueba y veamos qué sucede:describe('Real Test', () => {  it('finds the content "Gmail"', () => {    cy.visit('No tienes permitido ver los links. Registrarse o Entrar a mi cuenta')    cy.contains('Gmail')      })}) Nuestra prueba ahora debería aparecer CONTAINS en el Registro de comandos y aún estar en verde.Incluso sin agregar una afirmación, ¡sabemos que todo está bien! Esto se debe a que muchos de los comandos de Cypress están diseñados para fallar si no encuentran lo que esperan encontrar. Esto se conoce como aserción predeterminada .Para verificar esto, reemplácelo typecon algo que no esté en la página, como Red. Notarás que la prueba se pone roja, ¡pero solo después de unos 4 segundos!¿Puedes ver lo que Cypress está haciendo debajo del capó? Automáticamente espera y vuelve a intentarlo porque espera que el contenido finalmente se encuentre en el DOM. ¡No falla inmediatamente!cy.contains(): Este método busca un elemento que contiene el texto especificado. En el caso del ejemplo, se busca un enlace que contiene el texto "Gmail" y luego se realiza un clic en él. Esto es útil para seleccionar elementos basados en su contenido de texto en lugar de utilizar selectores CSS o XPath.Paso 3: Haz click en un elementoOk, ahora queremos hacer click en el enlace que encontramos. ¿Como hacemos eso? Agregue un comando .click() al final del comando anterior, así:describe('Real Test', () => {  it('clicks the link "Imágenes"', () => {    cy.visit('No tienes permitido ver los links. Registrarse o Entrar a mi cuenta')    cy.contains('Imágenes').click();      })}) ¡Casi puedes leerlo como una pequeña historia! Cypress llama a esto "encadenamiento" y encadenamos comandos para crear pruebas que realmente expresen lo que hace la aplicación de forma declarativa.También tenga en cuenta que el panel Vista previa de la aplicación se actualizó aún más después del click, siguiendo el enlace y mostrando la página de destino:¡Ahora podemos afirmar algo sobre esta nueva página!Paso 4: Has una afirmaciónHagamos una afirmación sobre algo en la nueva página en la que hicimos click. Quizás nos gustaría asegurarnos de que la nueva URL sea la URL esperada. Podemos hacerlo buscando la URL y encadenándole una afirmación con .should() .Así es como se ve:describe('Real Test', () => {  it('clicking "Imágenes" navigates to a new url', () => {    cy.visit('No tienes permitido ver los links. Registrarse o Entrar a mi cuenta')    cy.contains('Imágenes').click()    // Should be on a new URL which    // includes '/imghp?hl=es-419&ogbl'    cy.url().should('include', '/imghp?hl=es-419&ogbl')  })}) Pronto voy a subir más ejemplos para practicar, saludos.[/list]

Como puedo crer un Sub foro dentro de un Tema principal

💡 Es un framework para la automatizción de pruebas y test
💡 No utiliza Selenium
💡 Viene con todas las herramientas que necesitamos out of the box para e2e (end to end o de extremo a extremo)
💡 Utiliza JS (Java Script)


✏ Fácil de instalar
✏ Curva de aprendizaje baja.
✏ Es fácil categorizar pruebas.
✏ En muchas ocasiones es mas rápido que las soluciones basadas en Selenium
✏ Tiene una UI para administrar pruebas
✏ Waits automáticos


🗝 Configurar pruebas
🗝 Escribir pruebas
🗝 Ejecutar pruebas
🗝 Pruebas de depuración


🆗 Pruebas de un extremo a otro
🆗 Pruebas de componentes
🆗 Pruebas de integración
🆗 Pruebas unitarias

A diferencia de las pruebas estructuradas, aquí los testers se convierten en exploradores digitales, interactuando con la aplicación como usuarios finales. No se trata solo de encontrar defectos, sino de destapar sorpresas y escenarios no previstos.



En otras palabras sirve para cuando somos nuevos en un proyecto y no hay documentación, de esta manera tambien conocemos el negocio.

🔍 ¿Cómo se Hace? 🔍

💬 Se planifica y se organizan las pantallas a testear
💬 Tiempo de ejecución
💬 Se documenta grabando la pantalla

🔍 ¿Cuándo se Hace? 🔍

💬 Cuándo terminamos el tiempo
💬 Cuándo terminamos de testear las pantallas

🔥 ¿Qué es el Smoke Test y Por Qué es tan Relevante? 🔥

Un "Smoke Test" es una prueba rápida para verificar que un software pueda iniciarse correctamente después de cambios importantes en el código, sin detectar fallos críticos.



💬 En otras palabras sirve para probar la "Funcionalidad Principal del Sistema"

🔥 ¿Cuando se Realiza? 🔥

💬 Despues de cada #Deploy

🔥 ¿Para qué sirve? 🔥

💬 Para revisar que siempre funcione el "Flujo Principal del Sistema"
💬 Para revisar si el Deploy fue Exitoso
💬 Para revisar si una Feature grande funciona correctamente

🔑 Claves para un Smoke Test efectivo 🔑

* Foco en lo esencial: Concéntrate en las funciones clave y la estabilidad básica del software.

 * Automatización: Automatizar el proceso del Smoke Test garantiza rapidez y consistencia en las pruebas.

 * Integración continua: Integra el Smoke Test en tu flujo de trabajo para una calidad constante en cada iteración.

Hola chicos, hoy les traigo un super resumen de preguntas para entrevistas o solo para que tengan agendadas (Interview Questions Overview)



Saludos

Si estas Empezando como QA y queres saber más de APi´s, aca te dejo un resúmen en orden para que te sea amigable y fácil de entender.




1 - El término API es una abreviatura de Application Programming Interfaces, (interfaz de programación de aplicaciones).

2 - La API se utiliza para permitir la comunicación entre dos aplicaciones a través de un conjunto de reglas.

3 - Sirve para poder facilitarle el trabajo a los desarrolladores y ahorrar tiempo y dinero.

4 - Las API se manejan con EndPoint (URLs de una API) y cada EndPoint puede tener varios métodos. Los métodos son todas las formas que tenemos de poder interactura con ese EndPoint.

Entre los métodos más comunes encontramos a los siguientes:

    POST: crear un recurso nuevo.
    PUT: modificar un recurso existente.
    GET: consultar información de un recurso.
    DELETE: eliminar un recurso determinado.
    PATCH: modificar solamente un atributo de un recurso.

5 - Las Herramientas que se utilizan para gestionar peticiones a las APIs pueden ser:

11 de Agosto del 2023

Hoy les traigo un post corto de algunas de la preguntas más comunes que se hacen al corregir un Bug (Error)



¿Cuáles son los detalles necesarios?
Si ve la mayoría de los errores registrados en un sistema, a menudo se escriben rápidamente con muy poca atención a los detalles, en la mayoría de los casos, probablemente con un título de una sola línea.

Esto puede generar mucha frustración para la persona que lo mira a continuación porque no conoce algunos de los detalles importantes y luego tiene que ponerse su sombrero de Sherlock Holmes y buscar respuestas y esto a menudo es mucho de ida y vuelta entre Desarrollo/Prueba/PM para averiguar el área donde está presente el problema

Algunas de las preguntas comunes que hace una persona cuando intenta corregir un error en una aplicación típica para consumidores/negocios para sistemas web/móviles/backend son en su mayoría del tipo.

Si estas iniciando como QA acá te dejo un resumen de SQL y su sintaxis más usada, al final del Aporte te dejo varios links con paginas llena de tutoriales para que indagues más en este Lenguaje.


SQL es un lenguaje de programación diseñado para almacenar, manipular y recuperar datos almacenados en bases de datos relacionales. La primera vez que SQL apareció, fue en 1974, cuando un grupo de IBM desarrolló el primer prototipo de una base de datos relacional. Relational Software (luego se convirtió en Oracle) lanzó la primera base de datos relacional comercial.
Existen estándares para SQL, sin embargo, el SQL que puede utilizarse en cada uno de las principales RDBMS actuales viene en distintas formas. Esto se debe a dos razones:

•   El estándar SQL es bastante complejo, y no es práctico implementar el estándar completo.

•   Cada proveedor de base de datos necesita una forma de diferenciar su producto de otros.





A continuación muestro la sintaxis SQL para cada uno de los comandos SQL en esta guía de referencia:

Select
SELECT "nom de colonne" FROM "nombre_tabla";

Distinct
SELECT DISTINCT "nombre_columna"
FROM "nombre_tabla";

Where
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "condition";

And/Or
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "condición simple"
{[AND|OR] "condición simple"}+;

In
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" IN ('valor1', 'valor2', ...);

Between
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" BETWEEN 'valor1' AND 'valor2';

Like
SELECT "nombre_columna"
FROM "nombre_tabla"
WHERE "nombre_columna" LIKE {patrón};

Order By
SELECT "nombre_columna"
FROM "nombre_tabla"
[WHERE "condición"]
ORDER BY "nombre_columna" [ASC, DESC];

Count
SELECT COUNT("nombre_columna")
FROM "nombre_tabla";

Group By
SELECT "nombre_columna 1", SUM("nombre_columna 2")
FROM "nombre_tabla"
GROUP BY "nombre_columna 1";

Having
SELECT "nombre_columna 1", SUM("nombre_columna 2")
FROM "nombre_tabla"
GROUP BY "nombre_columna 1"
HAVING (condición de función aritmética);

Create Table
CREATE TABLE "nombre_tabla"
("columna 1" "tipo_de_datos_para_columna_1",
"columna 2" "tipo_de_datos_para_columna_2",
... );

Drop Table
DROP TABLE "nombre_tabla";

Truncate Table
TRUNCATE TABLE "nombre_tabla";

Insert Into
INSERT INTO "nombre_tabla" ("colonne 1", "colonne 2", ...)
VALUES ("valor 1", "valor 2", ...);

Update
UPDATE "nombre_tabla"
SET "colonne 1" = [nuevo valor]
WHERE "condición";

Delete From
DELETE FROM "nombre_tabla"
WHERE "condición";



Si te interesó y quieres ver más en detalle, podes hacerlo en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta, este sitio muestra una guía de referencia SQL enumera los comandos SQL normalmente utilizados, y se divide en las siguientes secciones:

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Las instrucciones SQL básicas para almacenamiento, recuperación y manipulación de datos en una base de datos relacional.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Cómo se utilizan las instrucciones SQL para administrar las tablas dentro de una base de datos.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta Comandos SQL avanzados.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta








Mr. Bones