¿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. npm 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

Hola Hola comunidad, hoy vamos a ver una introduccion simpificada de las pruebas funcionales y su consideraciones ante un marco de trabajo Ágile (scrum o Kanban)

Enfoques de pruebas funcionales y consideraciones ágiles
La prueba de funcionalidad es el examen de la respuesta de un sistema codificado al uso esperado. Tenga en cuenta que no habla de apariencia cosmética, rendimiento, seguridad o cumplimiento de ningún tipo.



La prueba funcional es un proceso de verificación de que un sistema funciona como se espera cuando sus características son ejercidas por otro sistema o directamente por un usuario. Esto significa que se presta muy bien a las definiciones de casos de prueba y casos de uso que pueden proporcionar una base estable y repetible para evaluar el progreso del desarrollo del sistema.
Toda la gama del proceso de desarrollo está bajo el control de la verificación de la funcionalidad.

Las pruebas unitarias deben comenzar desde el principio para garantizar que cada bloque de código realice la manipulación prevista de las entradas en las salidas deseadas para el siguiente módulo.
Las pruebas de integración aseguran que los módulos de la unidad se conectan entre sí como se esperaba y transmiten datos y comandos a través del sistema según las especificaciones para las que fue construido.
Las comprobaciones de cordura verifican que las modificaciones y correcciones aplicadas al cuerpo del código no tengan efectos secundarios inesperados en, aparentemente, partes no relacionadas del sistema.
Las pruebas de regresión verifican que las adiciones de características posteriores y las correcciones de errores no deshagan los esfuerzos anteriores ni interactúen con ellos para causar problemas completamente nuevos.
La aceptación de la usabilidad es la operación real del sistema en el contexto en el que fue diseñado para ser utilizado y es la puerta de entrada a la implementación.
Todos los anteriores son variedades de pruebas funcionales y todos contribuyen a la creación de un sistema de software que está listo para implementarse para el uso previsto.

Enfoques de pruebas funcionales

Tres enfoques se utilizan comúnmente para implementar pruebas funcionales.

Pruebas de caja negra
La prueba de caja negra toma una serie de entradas y busca la generación de salidas específicas. La idea detrás del nombre es que el contenido del código bajo prueba es desconocido para el caso de prueba y, por definición, para el probador que solo se preocupa por la verificación de funciones.

Pruebas de caja blanca
Las pruebas de caja blanca están en el otro extremo del espectro. Se basan en saber exactamente qué está pasando con el código bajo prueba y las pruebas se ejecutan principalmente para verificar la solidez del código en lugar de su funcionalidad absoluta.
Las pruebas de caja blanca se realizan al comienzo del proceso de desarrollo con pruebas unitarias y en las primeras partes de la fase de integración. El trabajo de prueba de caja negra es típico de las últimas fases donde la respuesta a escenarios operativos específicos es importante.

Pruebas de caja gris
El tercer tipo de prueba es una mezcla de caja blanca y negra. Esto sucede a medida que el desarrollo avanza hacia una zona de cruce hacia el final de la integración y el comienzo de la usabilidad.

Obviamente, las pruebas de caja negra se prestan a casos de prueba estrechamente definidos y resultados de prueba rigurosamente definidos. Estas son pruebas que pueden realizar los técnicos de prueba que son capaces de seguir cuidadosamente las instrucciones del plan de prueba y documentar meticulosamente los resultados.

Las pruebas de caja blanca las realizan mejor los ingenieros de software que entienden cómo se escribe el código y las permutaciones de cómo se espera que funcione.




El paso del SDLC en cascada al desarrollo Agile y de allí a la Integración Continua y luego a Dev/Ops ha impulsado con fuerza el paradigma de la calidad del software. Con el cambio a Agile en particular, el tiempo de prueba se consideró un lujo y, por lo tanto, algo prescindible. El retroceso en esto ha sido brutal.

Las aplicaciones lanzadas sin suficientes pruebas fueron atacadas por las reseñas de los clientes en Internet que hace que las malas noticias viajen como un avión supersónico. Una consecuencia lógica de esta situación ha sido el impulso hacia la automatización de pruebas y tiene mucho sentido en los entornos de desarrollo de alta velocidad de la actualidad. Desafortunadamente, esto ha llevado a una expectativa infundada de que todas las pruebas deben automatizarse y que curarán todos los males del desarrollo.

Automatización de pruebas funcionales
La automatización de pruebas funciona mejor cuando hay una prueba que está bien definida y debe realizarse muchas veces o requiere una configuración de sistema avanzada muy compleja. Las pruebas que varían de una versión a otra, requieren la cognición humana (piense en la validación de la interfaz de usuario intuitiva) o necesitan una variación ad hoc, como en las pruebas exploratorias, no son buenas candidatas para la automatización. Los scripts de prueba escritos para pruebas inadecuadas incurrirán en costos de mantenimiento de scripts que resultarán en su abandono final debido a fallas debido a errores de diseño de prueba.

Documentación de prueba funcional
La documentación de prueba es oro. Por mucho que la presión por el desarrollo rápido y los intervalos de lanzamiento cortos empujen la calidad a tomar atajos, la documentación es demasiado valiosa para ignorarla. La automatización de pruebas, cuando corresponda, ayudará a documentar los procesos de prueba, al igual que la finalización cuidadosa de los informes de defectos que documentan las pruebas de regresión.

Y reconozca que se necesita una combinación de talentos en todo el desarrollo de software. Agile exige la integración de la calidad y el desarrollo con la gestión de productos. Utilice esta motivación para hacer que los equipos sean cada vez más granulares y sembrarlos con ingenieros de prueba. Poner la calidad y el desarrollo en asientos adyacentes poliniza las dos disciplinas en beneficio de ambas.






Me despido y cualquier cosa me escriben.




Mr Bones

Hola Underc0ders, hoy vamos a ver algunas preguntas que nos pueden hacer en las entrevistas sobre SQL

Las paso en Español y en Ingles para el que necesite practicar.





¿Cuál es la diferencia entre un "Stored Procedure" (Procedimiento almacenado) y una "Function" (Función)?

Un procedimiento puede tener parámetros de entrada y salida, pero una función solo puede tener parámetros de entrada.
Dentro de un procedimiento, podemos usar sentencias DML (INSERT/UPDATE/DELETE), pero dentro de una función no podemos usar sentencias DML.
No podemos utilizar un procedimiento almacenado en una declaración SELECT, pero sí podemos usar una función en una declaración SELECT.
Podemos usar un bloque Try-Catch en un procedimiento almacenado, pero no podemos usarlo en una función.
Podemos administrar transacciones en un procedimiento, pero no en una función.
No podemos unir procedimientos almacenados, pero sí podemos unir funciones.
Los procedimientos almacenados no se pueden utilizar en ninguna parte de las declaraciones SQL en las secciones WHERE/HAVING/SELECT, pero sí podemos usar una función en cualquier lugar.
Un procedimiento puede devolver 0 o n valores (máximo 1024), pero una función solo puede devolver 1 valor que es obligatorio.
No se puede llamar a un procedimiento desde una función, pero sí podemos llamar a una función desde un procedimiento.

¿Cuál es la diferencia entre un "Clustered Index" (Índice agrupado) y un "Non-Clustered Index" (Índice no agrupado)?

Un índice agrupado almacena físicamente los datos de la tabla en orden de los valores clave, y los datos se reorganizan cada vez que se inserta un nuevo valor o se actualiza un valor en la columna en la que está definido. Por otro lado, un índice no agrupado crea una lista separada de valores clave (o crea una tabla de punteros) que apunta a la ubicación de los datos en las páginas de datos.
Un índice agrupado no requiere un almacenamiento separado del almacenamiento de la tabla. Obliga a que las filas se almacenen ordenadas según la clave del índice, mientras que un índice no agrupado requiere un almacenamiento separado del almacenamiento de la tabla para almacenar la información del índice.
Una tabla con un índice agrupado se llama tabla agrupada. Sus filas se almacenan en una estructura de árbol B mientras que una tabla sin índices agrupados se llama tabla no agrupada y sus filas se almacenan en una estructura heap sin ordenar.
El índice predeterminado se crea como parte de la columna de clave primaria como un índice agrupado.
En un índice agrupado, el nodo hoja contiene los datos reales, mientras que en un índice no agrupado, el nodo hoja contiene el puntero a las filas de datos de la tabla.
Un índice agrupado siempre tiene un Id de índice de 1, mientras que los índices no agrupados tienen Ids de índice > 1.
Una tabla puede tener solo 1 índice agrupado, mientras que antes de SQL Server 2008 solo se podían crear 249 índices no agrupados. Con SQL Server 2008 y versiones posteriores, se pueden crear 999 índices no agrupados.
Una restricción de clave primaria crea un índice agrupado de forma predeterminada, mientras que una restricción de clave única crea un índice no agrupado de forma predeterminada.

¿Cuál es la diferencia entre los comandos "DELETE" y "TRUNCATE"?

El comando DELETE se utiliza para eliminar filas de una tabla basándose en una condición WHERE, mientras que TRUNCATE elimina todas las filas de una tabla.
Por lo tanto, podemos usar una cláusula WHERE con DELETE para filtrar y eliminar registros específicos, pero no podemos usar una cláusula WHERE con TRUNCATE.
DELETE se ejecuta utilizando un bloqueo de fila, es decir, cada fila en la tabla se bloquea para su eliminación, mientras que TRUNCATE se ejecuta utilizando un bloqueo de tabla, es decir, toda la tabla se bloquea para la eliminación de todos los registros.
DELETE es un comando DML (Lenguaje de Manipulación de Datos), mientras que TRUNCATE es un comando DDL (Lenguaje de Definición de Datos).
DELETE conserva la identidad del valor de la columna, mientras que en TRUNCATE, la columna de identidad se restablece a su valor inicial (seed) si la tabla contiene alguna columna de identidad.
Para usar DELETE se necesita permiso DELETE en la tabla, mientras que para usar TRUNCATE en una tabla se necesita al menos permiso ALTER en la tabla.
DELETE utiliza más espacio de transacción que la instrucción TRUNCATE, mientras que TRUNCATE utiliza menos espacio de transacción que DELETE.
DELETE se puede utilizar con vistas indexadas, mientras que TRUNCATE no se puede utilizar con vistas indexadas.
La declaración DELETE elimina filas una por una y registra una entrada en el registro de transacciones por cada fila eliminada, mientras que TRUNCATE TABLE elimina los datos desasignando las páginas de datos utilizadas para almacenar los datos de la tabla y registra solo las desasignaciones de páginas en el registro de transacciones.
DELETE activa un disparador (trigger) porque la operación se registra individualmente, mientras que TRUNCATE TABLE no puede activar un disparador porque la operación no registra eliminaciones individuales de filas.

¿Cuál es la diferencia entre la cláusula "WHERE" y la cláusula "HAVING"?

La cláusula WHERE se puede usar con las declaraciones SELECT, UPDATE y DELETE, pero la cláusula HAVING solo se puede usar con una declaración SELECT.
No podemos usar una función de agregado en la cláusula WHERE a menos que esté en una subconsulta contenida en una cláusula HAVING, mientras que sí podemos usar una función de agregado en la cláusula HAVING. Podemos usar el nombre de una columna en la cláusula HAVING, pero la columna debe estar contenida en la cláusula GROUP BY.
La cláusula WHERE se utiliza antes de la cláusula GROUP BY, mientras que una cláusula HAVING se utiliza para imponer una condición en la función GROUP y se utiliza después de la cláusula GROUP BY en la consulta.
Una cláusula WHERE se aplica a cada fila, mientras que una cláusula HAVING se aplica a filas resumidas (resumidas con GROUP BY).
En la cláusula WHERE, se recuperan los datos que coinciden con la condición desde la memoria, mientras que en HAVING, primero se recuperan todos los datos completos y luego se separan según la condición.

¿Cuál es la diferencia entre una "Primary Key" (Clave primaria) y una "Unique Key" (Clave única)?

Solo podemos tener una clave primaria en una tabla, mientras que podemos tener más de una clave única en una tabla.
La clave primaria no puede tener un valor NULL, mientras que una clave única puede tener solo un valor NULL.
De forma predeterminada, una clave primaria es un índice agrupado, mientras que de forma predeterminada, una clave única es un índice único no agrupado.
Una clave primaria admite un valor de incremento automático (Auto Increment), mientras que una clave única no admite un valor de incremento automático.

¿Cuál es la diferencia entre una "Local Temporary Table" (Tabla temporal local) y una "Global Temporary Table" (Tabla temporal global)?

Una tabla temporal local se crea al darle un prefijo de "#", mientras que una tabla temporal global se crea al darle un prefijo de "##".
Una tabla temporal local no se puede compartir entre múltiples usuarios, mientras que una tabla temporal global puede compartirse entre múltiples usuarios.
Una tabla temporal local solo está disponible para la conexión de base de datos actual para el usuario actual y se borra cuando se cierra la conexión, mientras que una tabla temporal global está disponible para cualquier conexión una vez creada y se borra cuando se cierra la última conexión.

¿Qué son las claves super, primaria, candidata y foránea?

Una clave super es un conjunto de atributos de un esquema de relación en el que todos los atributos del esquema dependen funcionalmente. No pueden haber dos filas con el mismo valor de atributos de clave super.
Una clave candidata es una clave super minimal, es decir, no puede haber un subconjunto propio de los atributos de la clave candidata que sea una clave super.
Una clave primaria es una de las claves candidatas. Se selecciona una de las claves candidatas como la más importante y se convierte en la clave primaria. No puede haber más de una clave primaria en una tabla.
Una clave foránea es un campo (o una colección de campos) en una tabla que identifica de manera única una fila de otra tabla.

¿Cuál es la diferencia entre la clave primaria y las restricciones únicas?

La clave primaria no puede tener valores NULL, mientras que las restricciones únicas pueden tener valores NULL.
Solo puede haber una clave primaria en una tabla, pero puede haber múltiples restricciones únicas.

¿Qué es la normalización de bases de datos?

La normalización de bases de datos es un proceso para analizar los esquemas de relación dados en función de sus dependencias funcionales y claves primarias para lograr las siguientes propiedades deseables:
Minimizar la redundancia.
Minimizar las anomalías de inserción, eliminación y actualización.
Los esquemas de relaciones que no cumplen con estas propiedades se descomponen en esquemas de relaciones más pequeños que puedan cumplir con las propiedades deseables.

¿Qué es SQL?

SQL (Structured Query Language) es un lenguaje de programación diseñado para insertar y modificar datos en un sistema de gestión de bases de datos relacionales (RDBMS).

¿Cuáles son las diferencias entre DDL, DML y DCL en SQL?

DDL (Data Definition Language) corresponde a las consultas que definen la estructura de una base de datos, como CREATE, ALTER, DROP y RENAME.
DML (Data Manipulation Language) corresponde a las consultas que manipulan los datos en la base de datos, como SELECT, INSERT y UPDATE.
DCL (Data Control Language) corresponde a las consultas que controlan los permisos de acceso y la seguridad de la base de datos, como GRANT y REVOKE.

¿Cuál es la diferencia entre la cláusula HAVING y la cláusula WHERE?

HAVING se utiliza para especificar una condición para un grupo o una función de agregado utilizada en una instrucción SELECT. WHERE se utiliza para seleccionar antes de agrupar.
La cláusula HAVING puede contener funciones de agregado, mientras que la cláusula WHERE no puede contener funciones de agregado. Se pueden usar columnas en la cláusula HAVING, pero esas columnas deben estar contenidas en la cláusula GROUP BY.
La cláusula WHERE se aplica a cada fila, mientras que la cláusula HAVING se aplica a filas resumidas (resumidas con GROUP BY).

¿Qué es una "Join" (Unión)?

Un Join en SQL se utiliza para combinar datos de dos o más tablas basándose en un campo común entre ellas. Por ejemplo, podemos unir dos tablas para mostrar los nombres de los estudiantes inscritos en diferentes cursos.

¿Qué es una "Identity" (Identidad)?

La "Identity" (Identidad) o "AutoNumber" es una columna que genera automáticamente valores numéricos. Se puede establecer un valor de inicio e incremento, pero la mayoría de los DBA (Administradores de bases de datos) los dejan en 1. Una columna GUID también genera números, pero el valor de esta no se puede controlar. Las columnas Identity/GUID no necesitan ser indexadas.

¿Qué es una vista en SQL? ¿Cómo se crea una?

Una vista es una tabla virtual basada en el conjunto de resultados de una instrucción SQL. Podemos crear una vista utilizando la sintaxis CREATE VIEW.
Ejemplo:

sql
Copy code
CREATE VIEW nombre_vista AS
SELECT nombre_columnas
FROM nombre_tabla
WHERE condicion;

¿Cuáles son los usos de las vistas?

Las vistas pueden representar un subconjunto de los datos contenidos en una tabla, lo que permite limitar el grado de exposición de las tablas subyacentes al mundo exterior: un usuario dado puede tener permiso para consultar la vista, pero se le deniega el acceso al resto de la tabla base.
Las vistas pueden combinar y simplificar múltiples tablas en una sola tabla virtual.
Las vistas pueden actuar como tablas agregadas, donde el motor de la base de datos agrega datos (suma, promedio, etc.) y presenta los resultados calculados como parte de los datos.
Las vistas pueden ocultar la complejidad de los datos; por ejemplo, una vista podría aparecer como Sales2000 o Sales2001, particionando de manera transparente la tabla subyacente real.

¿Qué es un "Trigger" (Disparador)?

Un Trigger es un código que se asocia con operaciones de inserción, actualización o eliminación. El código se ejecuta automáticamente cada vez que se ejecuta la consulta asociada en una tabla. Los triggers pueden ser útiles para mantener la integridad en la base de datos.

¿Qué es un "Stored Procedure" (Procedimiento almacenado)?

Un Stored Procedure es como una función que contiene un conjunto de operaciones compiladas juntas. Contiene un conjunto de operaciones que se utilizan comúnmente en una aplicación para realizar algunas tareas comunes de la base de datos.

¿Cuál es la diferencia entre un Trigger y un Stored Procedure?

A diferencia de los Stored Procedures, los Triggers no se pueden llamar directamente. Solo pueden asociarse con consultas.

¿Qué es una "transacción"? ¿Cuáles son las propiedades ACID?

Una Transacción de base de datos es un conjunto de operaciones de base de datos que deben tratarse como un todo, lo que significa que todas las operaciones se ejecutan o ninguna se ejecuta.
Las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) son un conjunto de propiedades que garantizan que las transacciones de base de datos se procesen de manera confiable.







Mr. Bones

Hola Underc0ders, hoy traigo un tema resumido de los tipos de pruebas de interrupción que suelen estar tanto en páginas y dispositivos móviles


App o Páginas Web



Los "tests tipo crash" (también conocidos como pruebas de bloqueo o pruebas de choque) son un tipo de pruebas que se realizan para evaluar cómo responde una aplicación o software ante situaciones inesperadas o condiciones extremas que puedan llevar al bloqueo o cierre inesperado del programa.

El objetivo principal de estas pruebas es detectar y corregir posibles fallos graves o "crashes" que puedan surgir durante la ejecución de la aplicación. Estos fallos pueden deberse a diversos factores, como errores de programación, problemas de memoria, conflictos de recursos o situaciones imprevistas.

Algunos escenarios comunes que se prueban mediante tests tipo crash son:

Pruebas de excepciones: Se generan situaciones que pueden generar excepciones no controladas en el software, como divisiones por cero, acceso a memoria no válida, etc.

Pruebas de estrés: Se somete la aplicación a cargas extremas o condiciones de uso inusualmente intensas para verificar si puede manejar la presión y no bloquearse.

Pruebas de memoria: Se evalúa cómo se comporta el software ante situaciones de asignación excesiva de memoria o fugas de memoria.

Pruebas de interrupciones: Se simulan eventos externos, como llamadas telefónicas o mensajes, para ver cómo la aplicación responde y recupera su estado correctamente después de tales interrupciones.

Pruebas de rendimiento: Se evalúa el comportamiento del software bajo condiciones de baja conectividad o ancho de banda limitado.

Pruebas de condiciones extremas: Se llevan a cabo pruebas bajo situaciones poco comunes pero posibles, como un espacio de almacenamiento casi lleno o una batería baja.


Mobile


En cuanto a los test mobile, las pruebas crash, son un tipo de prueba que evalúa cómo una aplicación o sistema responde ante eventos externos que pueden interrumpir su funcionamiento normal. Estos eventos pueden ser llamadas telefónicas, notificaciones, mensajes entrantes, cambios de red, cambios en la conectividad, entre otros.
El objetivo principal de estas pruebas es verificar que la aplicación sea capaz de manejar adecuadamente estas interrupciones y recuperarse correctamente después de que el evento haya finalizado. Estos escenarios son críticos en dispositivos móviles, donde las aplicaciones pueden ser interrumpidas por diversas actividades externas mientras están en uso.

Algunos ejemplos resumidos de pruebas de interrupción incluyen:

Prueba de llamadas telefónicas: Se verifica cómo la aplicación maneja una llamada telefónica entrante o saliente mientras se encuentra en uso, y si puede recuperar correctamente su estado después de finalizar la llamada.

Prueba de mensajes entrantes: Se evalúa cómo la aplicación reacciona cuando se recibe un mensaje o notificación mientras está en funcionamiento, y si puede recuperar su estado sin problemas después de revisar el mensaje.

Prueba de cambio de red: Se comprueba cómo la aplicación responde si se cambia el tipo de red (por ejemplo, de Wi-Fi a datos móviles) mientras está en uso.

Prueba de pérdida de conectividad: Se verifica cómo la aplicación maneja la pérdida temporal de conectividad a Internet o de la señal de red y cómo se recupera cuando la conexión se restablece.

Prueba de suspensión y recuperación: Se evalúa cómo la aplicación responde cuando el dispositivo entra en estado de suspensión (pantalla apagada) y cómo se recupera una vez que el dispositivo se vuelve a activar.



Si te interesó este tipo de interrupciones, podes ver mas información en el post que te dejo el enlace:



Saludos




  Mr. Bones

En este aporte, traigo una versión extendidas de todos los test posibles que encontre para móviles, dame like si te gustó y tus comentarios para seguir aprendiendo con esta comunidad.


En el anterior post se había hablado de que los test de interrupción son un tipo de prueba que evalúa cómo una aplicación o sistema responde ante eventos externos que pueden interrumpir su funcionamiento normal.
Y que las pruebas para verificar que la aplicación sea capaz de manejar adecuadamente estas interrupciones y recuperarse correctamente después de que el evento haya finalizado
En este posteo vamos a ampliarlas para que conozcas más del tema:



Las pruebas de interrupción de llamadas telefónicas se centran en verificar cómo una aplicación móvil responde y se recupera ante eventos relacionados con llamadas telefónicas entrantes o salientes mientras la aplicación está en uso. Estas pruebas son esenciales para garantizar que la aplicación pueda manejar adecuadamente las interrupciones de las llamadas y que el usuario no experimente problemas o pérdida de datos cuando reciba o realice una llamada mientras utiliza la aplicación.

Los aspectos que se evalúan en estas pruebas incluyen:

Recepción de llamadas entrantes: Se verifica si la aplicación puede detectar correctamente una llamada entrante y cómo maneja esta interrupción. La aplicación debe pausar o suspender sus actividades de manera adecuada para que el usuario pueda atender la llamada.

Respuesta a llamadas salientes: Se evalúa cómo la aplicación responde si el usuario inicia una llamada desde dentro de la aplicación. La aplicación debe ser capaz de realizar la llamada sin problemas y permitir al usuario retomar sus actividades después de finalizar la llamada.

Recuperación del estado: Es importante comprobar si la aplicación es capaz de recuperar su estado y volver a funcionar correctamente una vez que la llamada se haya completado o rechazado. La aplicación no debe presentar errores o pérdida de datos después de una interrupción por llamada.

Gestión de eventos de llamadas: Se verifica cómo la aplicación maneja eventos específicos relacionados con las llamadas, como la duración de la llamada, el estado de la llamada (conectada, en espera, finalizada), y si muestra información relevante al usuario durante la llamada.

Integración con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para gestionar las llamadas entrantes y salientes de manera apropiada.

Es esencial realizar estas pruebas en una variedad de escenarios, como con diferentes operadores de telefonía móvil, condiciones de señal débil o fuerte, y en diferentes modelos de dispositivos para garantizar la compatibilidad y el rendimiento óptimo en diversas situaciones del mundo real.


Las pruebas de mensajes entrantes se centran en verificar cómo una aplicación móvil responde ante la recepción de mensajes, notificaciones o eventos similares mientras está en uso. Estos mensajes pueden incluir SMS, mensajes de aplicaciones de mensajería instantánea, notificaciones push, correos electrónicos, entre otros.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda manejar adecuadamente las interrupciones causadas por la llegada de mensajes, y que el usuario no experimente problemas o pérdida de datos cuando se recibe un mensaje mientras se utiliza la aplicación.
En estas pruebas incluyen:

Recepción de mensajes: Se verifica si la aplicación detecta correctamente la llegada de mensajes o notificaciones mientras está en uso y cómo maneja esta interrupción.

Respuesta a mensajes: Se evalúa cómo la aplicación reacciona si el usuario responde a un mensaje directamente desde la aplicación, como en aplicaciones de mensajería instantánea.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de recuperar su estado y volver a funcionar correctamente después de que se reciba un mensaje o notificación.

Visualización de mensajes: Se verifica cómo la aplicación muestra los mensajes entrantes al usuario, ya sea mediante notificaciones emergentes, bandejas de entrada u otros métodos.

Integración con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para recibir y procesar mensajes, y si se integra correctamente con las notificaciones del sistema.

Gestión de eventos de mensajes: Se verifica cómo la aplicación maneja eventos relacionados con los mensajes, como la eliminación de mensajes, la marca como leído, etc.

Es importante realizar estas pruebas en una variedad de escenarios y dispositivos móviles para garantizar que la aplicación pueda manejar diferentes tipos de mensajes y notificaciones sin afectar negativamente la funcionalidad y la experiencia del usuario.


Las pruebas de cambio de red se enfocan en verificar cómo una aplicación móvil responde cuando ocurren cambios en el tipo de red o conectividad mientras está en uso. Estos cambios de red pueden incluir la transición entre redes Wi-Fi y datos móviles (3G, 4G, 5G), o cambios en la intensidad de la señal.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda adaptarse sin problemas a diferentes tipos de red y condiciones de conectividad, para garantizar una experiencia de usuario óptima incluso cuando el dispositivo se mueve entre diferentes entornos de red.
En estas pruebas incluyen:

Transición de red: Se verifica cómo la aplicación maneja el cambio entre redes, como pasar de Wi-Fi a datos móviles o viceversa, y cómo afecta esto a las operaciones que esté realizando el usuario en ese momento.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de recuperar su estado y continuar funcionando correctamente después de un cambio de red, sin pérdida de datos o funcionalidad.

Estabilidad y rendimiento: Se evalúa cómo la aplicación responde a cambios en la intensidad de la señal o a conexiones de red débiles, y si sigue siendo estable y eficiente en su funcionamiento.

Integración con funciones del sistema operativo: Se verifica cómo la aplicación interactúa con el sistema operativo para adaptarse a los cambios de red y cómo se comunica con el sistema para obtener información sobre la conectividad.

Gestión de eventos de red: Se evalúa cómo la aplicación maneja eventos específicos relacionados con la conectividad, como la pérdida temporal de conexión o la restauración de la misma.

Es fundamental realizar estas pruebas en diferentes condiciones y ubicaciones para garantizar que la aplicación pueda ajustarse correctamente a los cambios de red y que el usuario no experimente problemas de conexión o rendimiento al utilizar la aplicación en diferentes entornos.



Las pruebas de pérdida de conectividad, también conocidas como pruebas de desconexión, se centran en verificar cómo una aplicación móvil responde cuando se pierde temporalmente la conectividad a Internet o cuando la señal de red es débil o inestable. Estas pruebas son importantes para evaluar cómo la aplicación maneja situaciones donde no hay acceso a Internet o la conexión es intermitente, lo que puede ocurrir debido a áreas con mala cobertura o problemas en la red.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda funcionar adecuadamente en condiciones de baja o nula conectividad y que el usuario no experimente problemas graves o pérdida de datos debido a la falta de conexión.
En estas pruebas incluyen:

Comportamiento en modo desconectado: Se verifica cómo la aplicación se comporta cuando la conectividad a Internet está ausente, si proporciona mensajes claros al usuario y si es capaz de realizar ciertas funciones en modo sin conexión.

Gestión de datos sin conexión: Se evalúa cómo la aplicación almacena y maneja datos localmente cuando no hay conexión a Internet y cómo sincroniza estos datos cuando la conexión se restaura.

Visualización de información: Se verifica si la aplicación muestra de manera adecuada la información disponible en modo sin conexión y si evita que el usuario realice acciones que requieran conexión.

Recuperación de la conexión: Es esencial comprobar si la aplicación puede detectar automáticamente la restauración de la conexión y si puede reanudar sus operaciones normalmente una vez que la conexión se reestablece.

Estabilidad y rendimiento: Se evalúa cómo la aplicación se comporta cuando la señal de red es débil o inestable, y si sigue siendo estable y eficiente en su funcionamiento.

Es fundamental realizar estas pruebas en diferentes ubicaciones y condiciones para garantizar que la aplicación pueda manejar adecuadamente la pérdida temporal de conectividad y proporcionar una experiencia de usuario consistente y confiable, incluso en áreas con problemas de conectividad.


Las pruebas de suspensión y recuperación, también conocidas como pruebas de estado en espera o pruebas de hibernación, se centran en verificar cómo una aplicación móvil responde cuando el dispositivo entra en un estado de suspensión o inactividad y cómo se recupera una vez que el dispositivo se vuelve a activar.

El objetivo principal de estas pruebas es asegurarse de que la aplicación pueda manejar correctamente los cambios en el estado del dispositivo y que pueda recuperar su estado y continuar funcionando de manera adecuada cuando el dispositivo salga del estado de suspensión.
En estas pruebas incluyen:

Suspensión del dispositivo: Se verifica cómo la aplicación responde cuando el dispositivo entra en un estado de suspensión, donde la pantalla se apaga y la mayoría de las actividades se detienen.

Recuperación del estado: Es esencial comprobar si la aplicación es capaz de guardar su estado de manera adecuada antes de la suspensión y si puede recuperar ese estado correctamente después de la reactivación.

Comportamiento en segundo plano: Se evalúa cómo la aplicación se comporta cuando se encuentra en segundo plano durante la suspensión y cómo responde cuando vuelve a estar en primer plano después de la reactivación.

Proceso de inicio y carga: Se verifica cómo la aplicación se inicia y carga después de salir del estado de suspensión, y si lo hace de manera rápida y eficiente.

Compatibilidad con diferentes sistemas operativos: Se asegura que la aplicación maneje la suspensión y recuperación correctamente en diferentes versiones del sistema operativo móvil.

Pruebas de interacción con el sistema operativo: Se evalúa cómo la aplicación interactúa con el sistema operativo para manejar eventos de suspensión y reactivación.

Es fundamental realizar estas pruebas en diferentes dispositivos y sistemas operativos para garantizar que la aplicación pueda manejar adecuadamente la suspensión y recuperación, y que ofrezca una experiencia de usuario fluida y sin problemas cuando el dispositivo entra y sale del estado de suspensión.



Las pruebas de interrupciones para aplicaciones móviles se enfocan en verificar cómo el software responde a situaciones inesperadas. Estas pruebas incluyen verificar cómo se manejan las llamadas telefónicas entrantes y salientes, cómo se reacciona ante mensajes y notificaciones, cómo se adapta a cambios de red y cómo se comporta al entrar y salir del estado de suspensión. El objetivo es garantizar que la aplicación sea robusta y brinde una experiencia fluida al usuario, sin errores ni pérdida de datos, incluso ante interrupciones externas.




  Mr. Bones

Hola comunidad, hoy les comparto algunas preguntas y respuestas para una entrevista de pruebas movile.

A medida que la tecnología mundial se vuelve cada vez más móvil, las pruebas de aplicaciones y sitios web diseñados para varios dispositivos móviles se vuelven cada vez más demandadas. Si va a realizar una entrevista para un proyecto móvil, no se deje sorprender por todos los nuevos desarrollos. En su lugar, actualice y estructure su conocimiento revisando esta lista de preguntas y respuestas comunes de la entrevista de prueba móvil, ¡y prepárese para participar!



1. ¿Cuál es la principal diferencia entre las pruebas móviles y web?
Las pruebas web requieren acceder al sitio a través de un navegador de Internet. Las pruebas móviles pueden significar pruebas web móviles (que son pruebas de aplicaciones web en navegadores en dispositivos móviles) o pruebas de aplicaciones móviles (lo que implica ejecutar una aplicación dedicada instalada en un dispositivo).

2. ¿Cuáles son los tipos de aplicación móvil?
Las aplicaciones móviles pertenecen a uno de tres tipos:
•   Aplicación web
•   Aplicación nativa
•   Aplicación Híbrida

3. ¿Puede nombrar las versiones más recientes de iOS y Android?
Su respuesta debe ser la versión más reciente, así que revísela antes de su entrevista si no está seguro.

4. ¿Cuáles son los desafíos más importantes en las pruebas de aplicaciones móviles?
Las aplicaciones móviles deben ser capaces de:
•   se ejecuta en una variedad de dispositivos, plataformas y tamaños de pantalla con diferentes versiones del sistema operativo
•   trabajar en diferentes tipos de redes (2G/Edge, 3G, 4G, Wifi, etc.)
•   lidiar con la duración de la batería y el consumo de energía;
•   manejar interrupciones tales como llamadas entrantes o mensajes.
 
5. Enumere los enfoques para las pruebas móviles en diferentes dispositivos
•   Priorizar la lista de dispositivos/resoluciones compatibles y centrarse en los más importantes
•   Uso de emuladores, simuladores
•   Uso de servicios de prueba colaborativos
•   Uso de servicios de prueba de aplicaciones basados en la nube
•   Pruebas beta del mundo real

6. ¿Cuáles son las limitaciones del uso de emuladores como medio de prueba de aplicaciones móviles?
Aunque pueden replicar el trabajo del hardware, los emuladores no pueden garantizar que el resultado sea idéntico al de un dispositivo real.
Además, los emuladores no pueden recrear las siguientes condiciones.
•   Interrupciones o Crash (llamada entrante, SMS, etc.)
•   Diversas configuraciones/características de hardware y software específicas de un dispositivo/SO
•   Los colores, el brillo y el contraste genuinos de la pantalla en ambientes oscuros y claros
•   Interacciones con otros sistemas o componentes (que forman parte de las pruebas de interoperabilidad)

7. Nombre algunas herramientas populares de prueba de automatización móvil
Hay una serie de herramientas populares de automatización de pruebas móviles, y es común que le pregunten sobre aquellas con las que ha tenido experiencia.
Algunas de las herramientas más populares:
•   Appium (Android e iOS)
•   Selendroid (solo Android)
•   Robotium (solo Android)
•   MonkeyRunner (solo Android)


8. ¿Cuáles son los tipos de pruebas más importantes para las pruebas de aplicaciones móviles?
•   Instalación/Desinstalación
•   Compatibilidad
•   UI, UX, capacidad de respuesta
•   Actuación
•   Seguridad
•   Interrupción
•   internacionalización
•   Estabilidad
•   interoperabilidad
•   usabilidad

9. Describa cualquier error interesante que haya encontrado recientemente.
Describa cualquier error no trivial que requirió un esfuerzo adicional para localizar. Puede ser un error que requirió un análisis profundo para encontrar la causa raíz o algún problema de seguridad, defecto relacionado con la memoria o reproducido en una configuración específica de dispositivo/SO.

10. ¿Cómo probaría la capacidad de recuperación?
La capacidad de recuperación o las pruebas de recuperación verifican que la aplicación puede recuperarse después de un bloqueo o falla. Todos los datos importantes deben estar seguros, sin que se pierda nada durante tales bloqueos. Puede requerir mucho esfuerzo y recursos realizar pruebas de recuperación exhaustivas. Estos ejemplos comunes son bastante fáciles de realizar para reproducir:
•   la pérdida de red durante alguna acción crítica para una aplicación que requiere conexión a Internet
•   carga de batería baja, reinicio del dispositivo debido a la carga baja
•   interrupción repentina o cierre de la aplicación mientras los procesos o acciones críticos aún se están ejecutando en la aplicación

Hemos visto algunas de las preguntas más comunes relacionadas con las pruebas mobile. Si conoces mas puedes agregarlas en los comentarios. Todos los éxitos para esa entrevista!!!

Hola underc0ders, hoy expongo el tema de....el pensamiento de un QA???

¿Qué pensamiento se esconde detrás del QA eficaz y eficiente? ¿Y cuáles son los detalles de la mentalidad de prueba ágil? Investiguemos juntos.



Entre todos los factores involucrados en las buenas prácticas, la psicología de los test ocupa un lugar importante, ya que puede afectar la forma en que abordamos los test, sin que seamos conscientes de que estamos haciendo ciertas llamadas de valor. Por ejemplo, se ha observado que los desarrolladores son menos efectivos al probar su propio código (o incluso el de sus compañeros de equipo) como testers y futuros QA dedicados. Hay varias razones por las que esto puede suceder:

•   Es difícil encontrar defectos en algo creado por uno mismo.
•   Puede ser un desafío pensar en lo que podría salir mal cuando se concentra en lo que debería hacer el sistema.
•   En general, los desarrolladores tienden a tener una mente orientada a la solución, mientras que los evaluadores deben estar orientados a los problemas, es decir, buscar 'cómo romper' las cosas en lugar de 'cómo construirlas'.
•   Por lo general, los evaluadores no necesitan saber en profundidad cómo funciona el sistema que se está probando. En su lugar, deben ponerse el sombrero del usuario final y pensar en posibles escenarios desde el punto de vista del usuario. En estos términos, el conocimiento de los desarrolladores sobre la forma en que funciona el sistema puede evitar que vean escenarios alternativos que podrían causar algún comportamiento inesperado.



Esto significa que para ser un tester efectivo, debe concentrarse en las formas de romper el software. En cierto sentido, su intención debería ser probar que 'no funciona', pero ese enfoque por sí solo puede no ser todo lo que se necesita para el éxito.


Al mismo tiempo, necesita algunas habilidades especiales para poder comunicar los problemas que ha encontrado. Simplemente ser un 'chico malo' que rompe todo no es eficiente en una perspectiva a largo plazo. Recuerde que los desarrolladores están emocionalmente apegados a los resultados de su trabajo, por lo que es natural que puedan ser sensibles a sus bien intencionadas críticas.
Aquí es donde algunas de las habilidades explicadas en nuestra publicación sobre Comunicación Constructiva pueden ser útiles para usar. Los puntos principales se enumeran a continuación:

•   Hable de un problema, no de una persona;
•   Sea específico, no general;
•   Operar con hechos, no con juicios;
•   Enfócate en el futuro, no en el pasado.
•   Comunicar desde la posición del objetivo común.

Usar un tono constructivo y amigable es fácil y natural cuando te das cuenta del objetivo común por el que se esfuerzan los evaluadores y los desarrolladores. De hecho, la razón por la que los desarrolladores pueden sentirse heridos por las críticas a su código es que luchan por la calidad antes de llegar a la etapa de prueba, que es exactamente lo que tú también estás buscando. En un entorno amigable, los desarrolladores pueden sentirse agradecidos por la oportunidad de aprender sobre sus propios errores y por recibir sus comentarios. Respetarán a los testers y futuros QA que colaboran con ellos, lo que les ayudará a aprender a usar el sombrero de tester cuando sea necesario, ampliando su experiencia. Así nace un verdadero equipo.


El trabajo de un tester de software significa no solo encontrar errores, sino también prevenirlos. Eso incluye el análisis de requisitos, la optimización de procesos y la implementación de un enfoque de prueba continuo. En este sentido, la mentalidad de un tester significa preocuparse por la calidad durante todas las etapas del ciclo de vida del desarrollo del software. En el desarrollo ágil, la calidad es responsabilidad de todo el equipo, por lo que el enfoque principal de los test ágiles se desplaza hacia la iniciativa y el control de las actividades que previenen la ocurrencia de defectos.


Para ser un tester exitoso, debe ser crítico con el software, amable con los desarrolladores y tener una excelente comunicación. En otras palabras, un verdadero tester de software no solo sabe cómo descifrar el software, sino también cómo construir relaciones amistosas y productivas y elaborar el proceso que previene los defectos.


Saludos

Mr Bones

Hola underc0ders, ahora les comparto las Pruebas de instalación en Pruebas de software

Prerrequisito: Pruebas de software

Prueba de instalación:


La prueba de los procedimientos para lograr un sistema de software instalado que se pueda utilizar se conoce como prueba de instalación. En esta instalación, se incluyen pruebas de verificación de actualizaciones completas o parciales y otras características, procesos de instalación/desinstalación. La prueba de instalación garantiza que la aplicación de software se haya instalado correctamente con todas sus características inherentes o no. También se denomina prueba de implementación, principalmente se realiza en la fase final.

¿Cuáles son las características de las pruebas de instalación?

Pruebas basadas en actividades
Ejecutado durante las pruebas de aceptación operativas
Realizado por ingenieros de pruebas de software junto con el administrador de configuración
Ayuda a ofrecer una experiencia de usuario óptima
Ayuda en la identificación y detección de errores durante la instalación
Las pruebas de instalación se ejecutan durante la última etapa de STLC
Hay desafíos que a veces afectan el proceso de prueba de instalación y muchas veces simplemente se vuelven caóticos.

Numerosas condiciones de validación
El producto debe probarse en diferentes configuraciones.
Como el proceso de instalación del software se valida por muchas razones, los requisitos también varían en las diferentes plataformas y, para reducir el consumo de tiempo, se utilizan los flujos de trabajo automatizados.



Trabajando en las pruebas de instalación:

La prueba de instalación se obtiene de los desarrolladores. El desarrollo de la empresa proporciona el acceso para instalar paquetes, así como el manual. Entonces, a partir de estas cosas, los probadores básicamente obtienen una idea de los componentes comprobables y no comprobables. Si hay alguna dificultad durante el proceso, se informa al equipo de desarrolladores. El principal objetivo de la condición es hacer el manual más fácil y simple para obtener el mejor resultado.

Los objetivos de las pruebas de instalación:

El objetivo principal es garantizar que no haya bloqueos que impidan que los usuarios finales utilicen el software y minimicen su eficiencia. El error y los errores son obtenidos por esto. Se asegura de que no se enfrente ningún problema con respecto a las diferentes plataformas.

Ayuda a verificar la distribución adecuada del siguiente software a la ubicación particular.

Tipos de tipos de asistencia:

Instalación silenciosa
instalación asistida
Instalación desatendida
Instalación de red
instalación limpia
Instalación automatizada

Ventajas de las pruebas de instalación:


La primera gran ventaja es que verifica los diseños de aplicaciones y software en un nivel básico de rendimiento de prueba.
Es una parte muy crucial de STLC que ayuda a mantener el estándar de acuerdo con eso.
Es un método muy rápido y práctico para comprobar la versión del software.
Los mejores resultados de salida de las pruebas de instalación ayudan al desarrollador a mejorar la aplicación o el software.

Contras de las pruebas de instalación:

A veces hay una falla causada por algunos factores externos, así como errores en el código, por lo que es un proceso lento y agotador.
El proceso de ejecución de casos de prueba requiere mucho tiempo, especialmente durante las pruebas de instalación.
El resultado o los resultados dependen completamente del caso de prueba impulsado.

Conclusión:

Las pruebas de instalación son uno de los aspectos críticos de las pruebas de software que se omiten y provocan un mal funcionamiento del software. En general, hay una gran cantidad de pruebas de instalación que a menudo conducen a varios desafíos. Una buena prueba de instalación no genera problemas y, por lo tanto, la instalación del software se lleva a cabo y la instalación sin problemas genera en los clientes la confianza para seguir usando el software.


Saludos y que sigas aprendiendo


Mr Bones

Verificación
¿Estamos construyendo el producto correctamente?

*Verificar los productos intermedios como documentos de requisitos, documentos de diseño, diagramas ER, plan de pruebas y matriz de trazabilidad.
*Punto de vista del desarrollador.
*Verificación sin ejecutar el código del software.
*Técnicas utilizadas: Revisión informal, Inspección, Recorrido, Revisión técnica y por pares.





Validación
¿Estamos construyendo el producto correctamente?

*Validar el producto final, como el software desarrollado, el servicio o el sistema.
*Punto de vista del cliente
*Validado mediante la ejecución del código del software.
*Técnicas utilizadas: Pruebas funcionales, pruebas del sistema, pruebas de humo, pruebas de regresión y muchas más.

----------------------------------------------------

In English

Verification
Are we building the product rigtht?

*Verify the intermediary products lik requirement documents, design documents, ER diagrams, test plan and traceability matrix.
*Developer point of view.
*Verified without executing the softarw code.
*Techniques used: informal Review, Inspection, Walkthrough, Technical and peer review


Validation
Are we building the product rigtht?

*Validate the Final end product like developed software or service or system.
*Customer point of view
*Validated by executing the software code.
*techniques used: Functional testing, System testing, Smoke testing, Regression testing and many more




Saludos

Mr. Bones

Buenos dia a todos los UnderC0ders, a partir de hoy voy a empezar mi taller de Scrum Master ---

Y que es un Scrum Master??? Es un jefe, un rol, alguien importante por como suena el Nombre?

La persona que cumple el rol de Scrum Master no es un gerente tradicional o un líder jerárquico, sino más bien un facilitador y un defensor del proceso de Scrum. Su enfoque principal es ayudar al equipo a lograr la entrega de valor de manera efectiva, asegurándose de que Scrum se aplique adecuadamente y se sigan las mejores prácticas.

Nos vemos pronto con más Información sobre Scrum Master

Hoy compartieron un artículo sobre ibm que ya despidió a 8 mil empleados, y el título es la cañería de la IA,
Quería consultar que tan de acuerdo están con este pensamiento ya que la IA nos ayuda a ser más eficientes en lo que hacemos, más rápidos para responder y resolver problemas.

Espero sus respuestas:::::

Mi conulta es como la IA puede ayudar a la traduccion de los difrentes tipos de idiomas a nivel mundia