Ir al final de los metadatos
Ir al inicio de los metadatos

Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 6 Siguiente »

CANAL PARA ENVIAR LOS DELIVERYs → https://upexqa.slack.com/archives/C02PTCKNV7E


🚀DELIVERY DE TESTING AL GRANO:

  1. DELIVERY CLASE #1 — SDLC VS STLC: Dibujo (ver imagen C#1)


  2. DELIVERY CLASE #2 — NIVELES DE TESTING: Dibujo (ver imagen C#2)


  3. DELIVERY CLASE #3 — TIPOS DE TESTING: Dibujo (ver imagen C#3)


  4. DELIVERY CLASE #4 — METODOLOGÍA SCRUM VS SDLC: Dibujo (ver imagen C#4)


  5. DELIVERY CLASE #5 — ELEMENTOS GUI (CUESTIONARIO): Examen (ver dibujo C#5)


  6. DELIVERY CLASE #6 — PROBANDO JIRA POR PRIMERA VEZ: Entrar en UPEX-JIRA (ver dibujo C#6)


  7. DELIVERY CLASE #7 — HISTORIA DE USUARIO: Dibujo (ver imagen C#7)


  8. DELIVERY CLASE #8 — CRITERIOS DE ACEPTACIÓN: Dibujo (ver imagen C#8)

🚀DELIVERY DE SQL:

NO OLVIDES USAR EL MATERIAL DE APOYO:
MARCO-SINTAXIS SQL TESTING (Fórmula)

  1. DELIVERY CLASE #1 — SINTAXIS SQL:
    DELIVERY PARA TODOS LOS QUE SIGUEN EL CURSO:" ARTISTA QUERY-TESTER "

    • MISSION:

      • USAR LA TABLA ACTUALIZADA DE SINTAXIS PARA CREAR ARTES DE QUERY! (SIN USAR JOINS AÚN)

      • TRATAR DE USAR TODOS LOS COMANDOS POSIBLES EN UNA MISMA QUERY

      • ENVIAR EL DELIVERY AL CANAL #task etiquetándome a mí “Ely”

      • SE PONDERARÁ SU TRABAJO EN BASE AL ESFUERZO Y CREATIVIDAD Vamos a divertirnos!

  2. DELIVERY CLASE #2 — FULL INNER:
    DELIVERY PARA TODOS LOS QUE SIGUEN EL CURSO: “FULL INNER JOINS QUERY"

    • MISSION:

      • HACER VARIAS QUERIES CREATIVAS CON "INNER JOIN"

      • Son libres de usar su creatividad!

      • Combinen 2,3,4 o más Tablas!

      • SELECT
FROM
INNER JOIN
ON

        Todos sus Delivery dejarán una huella a la comunidad de UPEX para futuros estudiantes

  3. DELIVERY CLASE #3 — INSERTAR TODA UNA DATA NUEVA, Y VALIDARLA POR SELECT:
    DELIVERY PARA TODOS LOS QUE SIGUEN EL CURSO: “FULL INNER JOINS QUERY"

    • MISSION:

      • Realizar una Infografía de "CÓMO REALIZAR UNA VALIDACIÓN END-TO-END con SQL" + "INSERTAR TODA UNA DATA NUEVA EN LA TABLA CUSTOMER (3 FILAS mínimo)"

        • Este tipo de Delivery es de investigación y ejecución. Esto requerirá su nivel evolucionar un poco su nivel cognitivo y aprenderán x1000 más!!

        • Realizar una INFOGRAFÍA con cualquier programa (o a lápiz) como conveniencia.

        • La INFOGRAFÍA debe ser concisa y fácil de identificar el dibujo.

        • Deben dibujar un PASO A PASO desde analizar la Data antes de Insertar, hasta la comprobación de la Data insertada, usando el SELECT con el JOIN.

        • Luego del Dibujo, como adicional: Deben realizar ustedes mismo el proceso de INSERCIÓN y SELECCIÓN en MySQL con Sakila.

        • TOMAR FOTO DE TODAS LAS QUERY HECHA DE INSERT, Y FOTO DEl ÚLTIMO SELECT CON EL JOIN y FOTO DE LA VISUALIZACIÓN DE LA TABLA.

        Dejaré por aquí un recuerdo de lo que hicimos.

🚀DELIVERY DE API:

NO OLVIDES USAR EL MATERIAL DE APOYO:

  1. DELIVERY CLASE #1 — FUNCIONES DEL API:
    EL PRIMER DELIVERY de API TESTING:

    1. ⏲ Tendrán que elaborar un MAPA MENTAL intuitivo de todas las terminologías de API!

    2. 📝 Les dejé un ejemplo (mi dibujo todo improvisado) para hagan el suyo 100 veces mejor!PD: Si estás empezando en UPEX y aún no has terminado TESTING AL GRANO, te recomiendo primero, terminar el primer Curso antes de estudiar éste.
      Pero siempre serán bienvenidos a las Meeting que haré ahora en adelante.

    3. 🚀 GANEMOS MÁS EXPERIENCIA CON LAS API!

  2. DELIVERY CLASE #2 — VALIDACIÓN Y VERIFICACIÓN DE API TESING MANUAL:
    COMPLETAR UNA HISTORIA DE USUARIO DE TRELLO CON API TESTING:
    UPEX-3144 - Obteniendo datos de tique... ESTADO

    1. Para validar las API (en caso de validación full integración),
      el Scope está en:

      1. GET, POST, PUT y DELETE
        según la documentación.

    2. No limitarse a usar solo 1 Query Parameter para la creación y actualización de la Card.
      SE PUEDE REALIZAR VALIDACIÓN:

      1. FRONTEND → FRONTEND
        (Validar y Verificar todo usando solo UI Testing)

      2. FRONTEND → BACKEND
        (Validar acciones por la UI y Verificar resultados por API con GET)

      3. BACKEND → BACKEND
        (Validar acciones por API con POST, PUT, DELETE, y verificar resultados por API con GET)

      4. BACKEND → FRONTEND
        (Validar acciones por API con POST, PUT, DELETE, y verificar resultados por la UI)

    3. NOTA PARA QA:
      En esta US en particular no debería tener un DEFECTO ya que es una funcionalidad muy limpia.

  • Sin etiquetas