├── Modulo-01-Introduccion-al-QA-Manual └── README.md ├── Modulo-02-Fundamentos-de-QA └── README.md ├── Modulo-03-Ciclo-de-Vida-del-Desarrollo-de-Software-SDLC └── README.md ├── Modulo-04-Ciclo-de-Vida-del-Testing-STLC └── README.md ├── Modulo-05-Diseño-de-Casos-de-Prueba └── README.md ├── Modulo-06-Tipos-de-Pruebas-Manuales └── README.md ├── Modulo-07-Gestion-de-Defectos └── README.md ├── Modulo-08-Herramientas-de-QA-Manual └── README.md ├── Modulo-09-Documentacion-de-Pruebas └── README.md ├── Modulo-10-Automatizacion-de-Pruebas-Introduccion-para-QA-Manual └── README.md ├── Modulo-11-Pruebas-en-Entornos-Agiles └── README.md ├── Modulo-12-Buenas-Practicas-en-QA-Manual └── README.md ├── Modulo-13-Preparacion-para-Entrevistas-de-QA-Manual └── README.md ├── Modulo-14-Talleres-Practicos-y-Ejercicios └── README.md ├── Modulo-15-Certificaciones-y-Crecimiento-Profesional-en-QA └── README.md ├── Modulo-16-Conclusion-del-Curso └── README.md └── README.md /Modulo-01-Introduccion-al-QA-Manual/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 1: Introducción al QA Manual 2 | 3 | ¡Bienvenido al primer módulo del curso de QA Manual! En este módulo, exploraremos los conceptos fundamentales del aseguramiento de la calidad en el desarrollo de software. 4 | 5 | ## Contenido 6 | 7 | ### 1. ¿Qué es el QA (Quality Assurance)? 8 | 9 | El aseguramiento de la calidad (QA) se refiere al proceso sistemático de evaluar y mejorar la calidad de los productos de software. El objetivo del QA es garantizar que el software cumpla con los estándares de calidad y satisfaga las necesidades de los usuarios finales. 10 | 11 | ### 2. Diferencia entre QA, Testing y Control de Calidad (QC) 12 | 13 | Es fundamental entender las diferencias entre estos tres términos, ya que cada uno juega un papel crucial en la entrega de un software de calidad. Vamos a desglosarlos uno por uno, acompañados de ejemplos cotidianos que ilustran cada concepto. 14 | 15 | #### **QA (Quality Assurance)** 16 | 17 | **Definición**: QA se centra en la mejora de procesos y en la prevención de defectos a lo largo del ciclo de vida del desarrollo del software. El objetivo del QA es garantizar que se sigan las mejores prácticas y se cumplan los estándares durante todo el proceso de desarrollo. 18 | 19 | **Ejemplo de la vida real**: Imagina que estás construyendo una casa. Antes de comenzar la construcción, se elaboran planes detallados y se definen estándares de calidad. Durante el proceso de construcción, se realizan revisiones y auditorías para asegurarse de que los materiales utilizados cumplen con las especificaciones. Si algo no se alinea con estos estándares, se corrige antes de que la casa sea terminada. De esta manera, el enfoque está en prevenir problemas antes de que ocurran. 20 | 21 | #### **Testing** 22 | 23 | **Definición**: El Testing es una parte del QA que se enfoca en la ejecución de pruebas para identificar defectos en el software. Se lleva a cabo una vez que el software está desarrollado, con el fin de asegurarse de que funciona como se espera. 24 | 25 | **Ejemplo de la vida real**: Siguiendo con el ejemplo de la casa, el Testing sería como llevar a cabo una inspección después de que la casa esté construida. Los inspectores revisan el sistema eléctrico, la fontanería y otros aspectos de la casa para asegurarse de que todo funcione correctamente. Si encuentran un problema, como una fuga en la tubería, se necesita arreglarlo antes de que la casa esté lista para habitar. En el software, esto significa ejecutar pruebas para identificar errores, como si un botón no funcionara o si la aplicación se cierra inesperadamente. 26 | 27 | #### **Control de Calidad (QC)** 28 | 29 | **Definición**: QC se refiere a las actividades específicas que aseguran que el producto final cumpla con los estándares de calidad establecidos. Esto puede incluir pruebas, revisiones y validaciones que se llevan a cabo para garantizar que el software es el correcto y cumple con las expectativas del cliente. 30 | 31 | **Ejemplo de la vida real**: Imagina que has terminado de construir la casa. Antes de entregarla al propietario, realizas una última revisión. Esto incluye comprobar que las puertas se abren y cierran correctamente, que no hay grietas en las paredes y que todo está limpio y ordenado. Si encuentras algún problema, se resuelve antes de que se entregue la casa. En el contexto del software, QC implica actividades como la revisión del producto final, la verificación de que todas las funciones especificadas están presentes y que no hay defectos críticos que afecten al usuario final. 32 | 33 | --- 34 | 35 | ### Resumen de las Diferencias 36 | 37 | - **QA** es proactivo, enfocado en prevenir defectos desde el inicio. 38 | - **Testing** es reactivo, enfocado en identificar defectos una vez que el software está desarrollado. 39 | - **QC** se centra en la conformidad del producto final con los estándares de calidad. 40 | 41 | --- 42 | 43 | ### 3. Importancia del QA en el ciclo de desarrollo de software 44 | 45 | El aseguramiento de la calidad (QA) juega un papel crucial en el ciclo de desarrollo de software por varias razones clave: 46 | 47 | - **Aumenta la satisfacción del cliente**: Un software de calidad que funciona correctamente y cumple con las expectativas de los usuarios es fundamental para la satisfacción del cliente. Cuando los usuarios encuentran un producto libre de errores y que satisface sus necesidades, es más probable que recomienden el software y se conviertan en clientes leales. Por ejemplo, una aplicación de banca móvil que funcione sin problemas permitirá a los usuarios realizar transacciones de manera confiable, aumentando su confianza en la plataforma. 48 | 49 | - **Reduce costos a largo plazo**: Identificar y corregir defectos en las primeras etapas del desarrollo es significativamente menos costoso que abordar problemas después de que el software ha sido entregado. Según estudios, los costos de corregir errores pueden aumentar hasta 30 veces si se encuentran en la fase de mantenimiento en comparación con la fase de desarrollo. Implementar un enfoque de QA sólido puede ayudar a minimizar estos costos, permitiendo que las empresas optimicen sus recursos y eviten gastos inesperados. 50 | 51 | - **Mejora la reputación de la empresa**: Un producto de alta calidad refuerza la confianza de los clientes en la empresa. La reputación de una empresa puede verse gravemente afectada por un software defectuoso; los errores frecuentes pueden llevar a críticas negativas y disminuir la lealtad del cliente. Por ejemplo, empresas como Microsoft y Apple han invertido fuertemente en QA para asegurar que sus productos sean percibidos como confiables y de alta calidad. Esto no solo aumenta la satisfacción del cliente, sino que también contribuye al crecimiento del negocio y a una imagen de marca positiva. 52 | 53 | En resumen, el QA no solo se trata de encontrar y corregir errores, sino que es un componente esencial para garantizar un desarrollo de software exitoso que beneficie tanto a los clientes como a la empresa. 54 | 55 | 56 | ## Recursos Adicionales 57 | 58 | - [Artículo sobre QA en el desarrollo de software](https://www.computing.es/infraestructuras/pasos-para-asegurar-la-calidad-del-software/) 59 | 60 | --- 61 | 62 | ¡Gracias por unirte a este módulo! Asegúrate de revisar los siguientes materiales y ejercicios para afianzar tu comprensión. En el próximo módulo, exploraremos los fundamentos de QA. 63 | -------------------------------------------------------------------------------- /Modulo-02-Fundamentos-de-QA/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 2: Fundamentos de QA 2 | 3 | ¡Bienvenido al segundo módulo del curso de QA Manual! En este módulo, abordaremos los conceptos fundamentales del aseguramiento de la calidad y los distintos tipos de pruebas que se realizan en el desarrollo de software. 4 | 5 | ## Contenido 6 | 7 | ### 1. Conceptos Clave 8 | 9 | #### Defectos, Errores, Bugs y Fallos 10 | 11 | - **Defecto**: Un defecto es cualquier discrepancia entre el producto real y lo que se esperaba. Por ejemplo, si un botón en una aplicación web no funciona como se esperaba, eso se considera un defecto. 12 | 13 | - **Error**: Un error es la acción incorrecta realizada por un desarrollador que lleva a un defecto. Por ejemplo, un error en la lógica de programación que hace que un cálculo no se ejecute correctamente. 14 | 15 | - **Bug**: Es un término informal que se utiliza para referirse a un defecto o error en el software. Por ejemplo, si una aplicación se cierra inesperadamente cuando el usuario hace clic en un botón, eso es considerado un bug. 16 | 17 | - **Fallo**: Un fallo ocurre cuando un software no cumple con los requisitos establecidos. Por ejemplo, si una función debe retornar un valor y lo hace de manera incorrecta, esto es un fallo. 18 | 19 | # Tipos de Pruebas en QA 20 | 21 | El aseguramiento de la calidad (QA) abarca diferentes tipos de pruebas, cada una diseñada para evaluar aspectos específicos del software. A continuación, se presenta una clasificación detallada: 22 | 23 | ## 1. Pruebas Funcionales 24 | 25 | Las pruebas funcionales se centran en verificar que las funciones del software cumplan con los requisitos especificados. Incluyen: 26 | 27 | ### 1.1. Pruebas de Aceptación 28 | - **Descripción**: Verifican si el software cumple con los requisitos y expectativas del cliente. 29 | - **Ejemplo**: Un cliente prueba una aplicación de compras en línea para asegurarse de que todos los procesos de pago funcionen correctamente. 30 | 31 | ### 1.2. Pruebas de Regresión 32 | - **Descripción**: Aseguran que los cambios recientes en el software no afecten las funcionalidades existentes. 33 | - **Ejemplo**: Después de una actualización de la aplicación, se prueba que las funciones anteriores sigan funcionando como se esperaba. 34 | 35 | ### 1.3. Pruebas Smoke 36 | - **Descripción**: Pruebas básicas que verifican que las funcionalidades principales del software funcionen. 37 | - **Ejemplo**: Un equipo realiza pruebas rápidas para verificar que la aplicación se inicie y que las funciones críticas estén accesibles. 38 | 39 | ### 1.4. Pruebas Sanity 40 | - **Descripción**: Verifican que una funcionalidad específica funcione correctamente después de un cambio. 41 | - **Ejemplo**: Tras corregir un error en el proceso de registro, se prueba únicamente esa función para asegurarse de que el problema se haya solucionado. 42 | 43 | ### 1.5. Pruebas Exploratorias 44 | - **Descripción**: Se centran en explorar el software sin un conjunto de casos de prueba predefinidos. 45 | - **Ejemplo**: Un tester utiliza su conocimiento del software para intentar encontrar defectos al interactuar con la aplicación de manera no estructurada. 46 | 47 | ## 2. Pruebas No Funcionales 48 | 49 | Las pruebas no funcionales evalúan aspectos que no están directamente relacionados con las funciones específicas del software, como rendimiento, usabilidad y seguridad. 50 | 51 | ### 2.1. Pruebas de Usabilidad 52 | - **Descripción**: Evalúan la facilidad de uso de la aplicación. 53 | - **Ejemplo**: Se realiza una prueba con usuarios reales para observar si pueden navegar por el sitio web sin problemas. 54 | 55 | ### 2.2. Pruebas de Rendimiento 56 | - **Descripción**: Miden el comportamiento del software bajo diversas condiciones de carga. 57 | - **Ejemplo**: Se simula el acceso de múltiples usuarios a la vez para comprobar cómo se comporta la aplicación. 58 | 59 | #### 2.2.1. Pruebas de Carga 60 | - **Descripción**: Evalúan cómo el software se desempeña bajo una carga específica. 61 | - **Ejemplo**: Se determina cuántos usuarios puede manejar simultáneamente un sitio web sin degradar su rendimiento. 62 | 63 | #### 2.2.2. Pruebas de Estrés 64 | - **Descripción**: Evalúan el software más allá de sus límites especificados para determinar su comportamiento bajo condiciones extremas. 65 | - **Ejemplo**: Se aumenta el número de usuarios concurrentes hasta que el sistema falle, para identificar el límite máximo. 66 | 67 | #### 2.2.3. Pruebas de Escalabilidad 68 | - **Descripción**: Evalúan cómo se comporta el sistema a medida que aumenta la carga. 69 | - **Ejemplo**: Se verifica si la aplicación puede manejar un incremento en el número de usuarios sin afectar su rendimiento. 70 | 71 | ### 2.3. Pruebas de Seguridad 72 | - **Descripción**: Verifican la protección contra vulnerabilidades y ataques. 73 | - **Ejemplo**: Se realizan pruebas para detectar posibles brechas de seguridad que podrían permitir el acceso no autorizado a datos sensibles. 74 | 75 | ### 2.4. Pruebas de Compatibilidad 76 | - **Descripción**: Aseguran que el software funcione correctamente en diferentes entornos (navegadores, dispositivos, sistemas operativos). 77 | - **Ejemplo**: Se prueba una aplicación web en varios navegadores para garantizar que se muestre correctamente en todos ellos. 78 | 79 | ## Resumen de Clasificación 80 | 81 | - **Pruebas Funcionales**: Aceptación, regresión, smoke, sanity, exploratorias. 82 | 83 | - **Pruebas No Funcionales**: Usabilidad, rendimiento (carga, estrés, escalabilidad), seguridad, compatibilidad. 84 | 85 | 86 | ### 3. Principios Básicos del Testing de Software 87 | 88 | 1. **El testing debe comenzar lo antes posible**: Detectar defectos en las primeras etapas del desarrollo es más eficiente. 89 | 90 | 2. **El testing es un proceso continuado**: Las pruebas deben realizarse a lo largo de todo el ciclo de vida del software, no solo al final. 91 | 92 | 3. **El testing debe ser exhaustivo**: Aunque es difícil probar todas las combinaciones posibles, se deben cubrir los escenarios más críticos. 93 | 94 | 4. **El testing es una actividad conjunta**: Todos los miembros del equipo, incluidos desarrolladores y analistas de negocio, deben estar involucrados en el proceso de pruebas. 95 | 96 | 5. **La ausencia de defectos no significa calidad**: Un software puede pasar todas las pruebas y aún así no ser de alta calidad si no cumple con las expectativas de los usuarios. 97 | 98 | --- 99 | 100 | ¡Gracias por unirte a este módulo! En el próximo módulo, exploraremos el ciclo de vida del desarrollo de software (SDLC) y cómo el QA se integra en cada modelo. 101 | -------------------------------------------------------------------------------- /Modulo-03-Ciclo-de-Vida-del-Desarrollo-de-Software-SDLC/README.md: -------------------------------------------------------------------------------- 1 | # 📋 **Ciclo de Vida del Desarrollo de Software (SDLC)** 2 | 3 | El **Ciclo de Vida del Desarrollo de Software (SDLC)** es el proceso que sigue un proyecto de software desde su concepción hasta su entrega y mantenimiento. Incluye todas las fases necesarias para garantizar que el software sea de alta calidad, cumpla con los requisitos del cliente y esté listo para su uso final. En este módulo, exploraremos los modelos más comunes de desarrollo de software y el papel crucial que juega el QA en cada uno de ellos. 4 | 5 | --- 6 | 7 | ## 🏗️ **Modelos de Desarrollo de Software** 8 | 9 | ### 1. **Waterfall (Cascada)** 10 | El modelo Waterfall es uno de los enfoques más tradicionales en el desarrollo de software. Este modelo sigue un proceso lineal y secuencial en el que cada fase debe completarse antes de que comience la siguiente. Las fases típicas incluyen: 11 | 12 | - **Requisitos** 13 | - **Diseño** 14 | - **Implementación** 15 | - **Pruebas** 16 | - **Despliegue** 17 | - **Mantenimiento** 18 | 19 | **Ejemplo del mundo real:** Imagina construir una casa. Primero, necesitas planos (requisitos), luego se diseña la estructura, se construye la casa, se revisa para asegurarse de que todo funcione correctamente, se entrega al dueño, y finalmente se mantiene si surgen problemas. 20 | 21 | **Ventajas:** 22 | - Fácil de entender y gestionar. 23 | - Ideal para proyectos pequeños con requisitos bien definidos. 24 | 25 | **Desventajas:** 26 | - Rigidez: no se adapta bien a cambios en los requisitos. 27 | - Identificación tardía de errores, ya que las pruebas se realizan al final. 28 | 29 | **Rol del QA:** En el modelo Waterfall, el QA participa principalmente durante la fase de pruebas, pero también puede estar involucrado desde la fase de requisitos para asegurar que se entiendan correctamente. 30 | 31 | ### 2. **Agile (Ágil)** 32 | El desarrollo ágil es un enfoque iterativo e incremental. Se centra en entregar pequeñas partes funcionales del software de manera continua y frecuente a lo largo del proyecto, permitiendo recibir retroalimentación y hacer ajustes rápidamente. Los equipos trabajan en ciclos cortos llamados **sprints**, que suelen durar entre 1 y 4 semanas. 33 | 34 | **Ejemplo del mundo real:** Imagina construir una aplicación móvil en la que primero se lanza una versión básica (con pocas funciones) para recibir comentarios de los usuarios y luego se agregan nuevas características y mejoras en versiones posteriores. 35 | 36 | **Ventajas:** 37 | - Flexibilidad para adaptarse a cambios en los requisitos. 38 | - Entrega rápida de valor al cliente. 39 | - Retroalimentación continua y mejoras constantes. 40 | 41 | **Desventajas:** 42 | - Puede ser difícil de gestionar si no hay una planificación adecuada. 43 | - Requiere colaboración constante del equipo. 44 | 45 | **Rol del QA:** En Agile, el QA trabaja de la mano con desarrolladores y otros miembros del equipo desde el inicio del proyecto. Realiza pruebas continuas y colabora para garantizar que cada sprint entregue una funcionalidad de alta calidad. Participa en las **ceremonias ágiles** como la planificación de sprint, retrospectivas y revisiones, ayudando a mejorar el proceso de desarrollo. 46 | 47 | ### 3. **DevOps** 48 | DevOps es una combinación de prácticas, herramientas y una filosofía cultural que busca mejorar la colaboración entre los equipos de desarrollo (Dev) y operaciones (Ops). Su objetivo es acelerar el ciclo de desarrollo, mejorar la calidad del software y reducir el tiempo de entrega. DevOps enfatiza la automatización de procesos desde el desarrollo hasta la entrega y despliegue. 49 | 50 | **Ejemplo del mundo real:** Una empresa que lanza actualizaciones automáticas de su software, como una nueva versión de una app móvil que se publica directamente sin intervención manual cada vez que se realiza una mejora. 51 | 52 | **Ventajas:** 53 | - Automatización y eficiencia: las tareas repetitivas y largas se pueden automatizar. 54 | - Rápido tiempo de entrega con menos errores. 55 | - Despliegue continuo y seguro. 56 | 57 | **Desventajas:** 58 | - Requiere una fuerte cultura de colaboración. 59 | - Necesidad de habilidades técnicas avanzadas en el equipo. 60 | 61 | **Rol del QA:** En el contexto de DevOps, el QA se integra aún más en el proceso. Se involucra en el desarrollo de pruebas automatizadas que se ejecutan automáticamente en cada despliegue. Además, colabora con los equipos de operaciones para asegurar que las nuevas versiones del software sean estables y seguras. 62 | 63 | --- 64 | 65 | ## 🎯 **Cómo el QA se Integra en Cada Modelo** 66 | 67 | ### **Waterfall:** 68 | El QA suele involucrarse después de que se completa el desarrollo. Sin embargo, es esencial para los equipos de QA participar desde la fase de requisitos para detectar posibles errores de interpretación. Esto asegura que las pruebas finales cubran todos los aspectos críticos. 69 | 70 | ### **Agile:** 71 | Aquí, el QA es una parte esencial del equipo ágil, trabajando desde el principio. Realiza pruebas a medida que se desarrolla cada funcionalidad y colabora en las reuniones diarias (**dailies**) para discutir problemas encontrados y sugerir soluciones. Su objetivo es garantizar que cada incremento del producto sea funcional y de alta calidad. 72 | 73 | ### **DevOps:** 74 | El QA colabora no solo en las pruebas manuales sino también en la **automatización**. Implementa pruebas automatizadas que se ejecutan en cada despliegue y desarrolla scripts para pruebas de rendimiento, seguridad y otros tipos de pruebas no funcionales. El QA en DevOps busca reducir el número de errores en producción y acelerar la entrega de nuevas características. 75 | 76 | --- 77 | 78 | ## 👥 **Roles y Responsabilidades del QA Manual en Cada Fase del SDLC** 79 | 80 | 1. **Requisitos:** 81 | - Entender y revisar los requisitos del software. 82 | - Identificar posibles errores o ambigüedades. 83 | - Participar en reuniones de planificación para aclarar dudas. 84 | 85 | 2. **Diseño:** 86 | - Revisar el diseño técnico para asegurarse de que cubra todos los requisitos. 87 | - Identificar casos potenciales de prueba basados en los diseños. 88 | 89 | 3. **Implementación:** 90 | - Crear casos de prueba detallados que cubran todas las funcionalidades. 91 | - Revisar el código si es necesario (en prácticas ágiles, por ejemplo, para apoyar a los desarrolladores). 92 | 93 | 4. **Pruebas:** 94 | - Ejecutar casos de prueba manualmente y reportar defectos. 95 | - Realizar pruebas funcionales, de regresión, de integración y otras necesarias. 96 | - Colaborar con el equipo de desarrollo para resolver errores. 97 | 98 | 5. **Despliegue:** 99 | - Realizar pruebas finales en el entorno de pre-producción. 100 | - Verificar que todas las correcciones de errores estén implementadas y validadas. 101 | - Apoyar en la planificación del despliegue para garantizar que el software funcione sin problemas en producción. 102 | 103 | 6. **Mantenimiento:** 104 | - Realizar pruebas en caso de parches o actualizaciones. 105 | - Documentar problemas recurrentes para la mejora continua del software. 106 | - Asegurar la calidad continua durante el ciclo de vida del producto. 107 | 108 | --- 109 | 110 | ## 📌 **Resumen** 111 | El SDLC es la columna vertebral del desarrollo de software y define cómo se llevan a cabo los proyectos de principio a fin. Entender los modelos Waterfall, Agile y DevOps, y cómo se integra el QA en cada uno, es clave para asegurar la calidad del software. Como profesional de QA, tu rol no es solo encontrar errores, sino prevenirlos y colaborar con todo el equipo para ofrecer un producto final que cumpla con las expectativas del cliente y del mercado. 112 | 113 | ¡Sigamos aprendiendo y asegurando calidad en cada fase del proyecto! 🚀✨ 114 | -------------------------------------------------------------------------------- /Modulo-04-Ciclo-de-Vida-del-Testing-STLC/README.md: -------------------------------------------------------------------------------- 1 | # 🧪 **Ciclo de Vida del Testing (STLC)** 2 | 3 | El **Ciclo de Vida del Testing (STLC)** es un proceso sistemático que define todas las actividades realizadas durante las fases de prueba de software. Es una parte esencial del desarrollo de software, que asegura que el producto final cumpla con los requisitos y estándares de calidad antes de ser lanzado. El STLC no solo se centra en encontrar errores, sino también en mejorar la calidad del producto desde las primeras fases del proyecto. 4 | 5 | En este módulo, aprenderemos en detalle sobre las fases del STLC, las entradas y salidas necesarias para cada una, y cómo definir una estrategia de pruebas efectiva. 6 | 7 | --- 8 | 9 | ## 🗂️ **Fases del STLC** 10 | 11 | ### 1. **Planificación de Pruebas** 12 | La fase de planificación es la primera en el STLC y se centra en definir el alcance, los objetivos y la estrategia de pruebas que se va a seguir durante el proyecto. Aquí se identifican los recursos necesarios (equipo, herramientas, ambientes de pruebas), se determinan los riesgos potenciales y se crean los cronogramas. 13 | 14 | **Actividades clave:** 15 | - Entender los requisitos del proyecto. 16 | - Definir el alcance y los tipos de pruebas (funcionales, no funcionales, de seguridad, etc.). 17 | - Estimar el tiempo y esfuerzo necesario para las pruebas. 18 | - Identificar riesgos y definir un plan de mitigación. 19 | - Seleccionar herramientas para la gestión y ejecución de pruebas. 20 | 21 | **Entrada (Entry Criteria):** 22 | - Requisitos del proyecto aprobados y definidos. 23 | - Documento de diseño técnico disponible. 24 | - Herramientas de pruebas seleccionadas. 25 | 26 | **Salida (Exit Criteria):** 27 | - Plan de pruebas documentado y aprobado. 28 | - Estrategia de pruebas definida. 29 | - Recursos asignados y cronograma de pruebas establecido. 30 | 31 | **Ejemplo del mundo real:** Piensa en el lanzamiento de un nuevo smartphone. Antes de que llegue al mercado, la empresa debe planificar qué funciones se van a probar (llamadas, mensajes, cámara, batería), quién lo hará, cuánto tiempo tomará y qué riesgos existen (por ejemplo, problemas de rendimiento bajo ciertas condiciones). 32 | 33 | --- 34 | 35 | ### 2. **Diseño de Casos de Prueba** 36 | En esta fase, se crean los **casos de prueba** detallados basados en los requisitos y criterios de aceptación del proyecto. Un caso de prueba es un conjunto de condiciones y pasos que se deben seguir para validar una funcionalidad específica del software. 37 | 38 | **Actividades clave:** 39 | - Revisar los requisitos para identificar qué funcionalidades necesitan ser probadas. 40 | - Crear casos de prueba detallados que cubran todas las posibles situaciones, incluyendo pruebas positivas (funcionamiento esperado) y negativas (errores esperados). 41 | - Diseñar los datos de prueba necesarios para ejecutar los casos de prueba. 42 | - Revisar y validar los casos de prueba para asegurar que sean precisos y completos. 43 | 44 | **Entrada (Entry Criteria):** 45 | - Documentación de requisitos clara y aprobada. 46 | - Plan de pruebas aprobado. 47 | - Diseño técnico disponible. 48 | 49 | **Salida (Exit Criteria):** 50 | - Casos de prueba documentados, revisados y aprobados. 51 | - Datos de prueba preparados. 52 | - Entornos de prueba configurados para la ejecución. 53 | 54 | **Ejemplo del mundo real:** Para una aplicación bancaria, un caso de prueba podría ser validar que un usuario pueda iniciar sesión correctamente con sus credenciales. Además, habría casos de prueba negativos para verificar qué ocurre si el usuario introduce una contraseña incorrecta o deja el campo en blanco. 55 | 56 | --- 57 | 58 | ### 3. **Ejecución de Pruebas** 59 | Durante la fase de ejecución, se llevan a cabo los casos de prueba diseñados previamente. El equipo de QA ejecuta cada caso, registra los resultados y documenta cualquier defecto encontrado para ser corregido por el equipo de desarrollo. 60 | 61 | **Actividades clave:** 62 | - Ejecutar casos de prueba manualmente o mediante herramientas automatizadas. 63 | - Comparar los resultados reales con los resultados esperados. 64 | - Registrar cualquier desviación como defectos. 65 | - Realizar pruebas de regresión para asegurar que las correcciones de errores no generen nuevos problemas en otras partes del sistema. 66 | 67 | **Entrada (Entry Criteria):** 68 | - Casos de prueba aprobados y listos. 69 | - Ambiente de pruebas configurado. 70 | - Datos de prueba cargados y disponibles. 71 | 72 | **Salida (Exit Criteria):** 73 | - Resultados de las pruebas documentados. 74 | - Defectos registrados y comunicados al equipo de desarrollo. 75 | - Pruebas de regresión completadas. 76 | 77 | **Ejemplo del mundo real:** Imagina que estás probando la función de pago de una tienda en línea. Ejecutas los casos de prueba para verificar que los pagos se procesen correctamente usando diferentes métodos (tarjeta de crédito, PayPal, transferencia). Si encuentras que los pagos con tarjeta no funcionan, registras el defecto para que sea solucionado. 78 | 79 | --- 80 | 81 | ### 4. **Reporte de Pruebas** 82 | La fase de reporte se centra en recopilar todos los resultados de las pruebas y generar informes detallados. Estos informes se utilizan para analizar el estado del proyecto, identificar posibles áreas problemáticas y decidir si el software está listo para el lanzamiento. 83 | 84 | **Actividades clave:** 85 | - Crear informes detallados sobre los resultados de las pruebas (cuántos casos de prueba se pasaron, cuántos fallaron, cuántos defectos se encontraron). 86 | - Realizar un análisis para identificar tendencias (por ejemplo, si una funcionalidad específica tiene muchos errores recurrentes). 87 | - Recomendar si el software está listo para avanzar a la siguiente fase o si se necesitan más pruebas. 88 | 89 | **Entrada (Entry Criteria):** 90 | - Ejecución de pruebas completada. 91 | - Defectos registrados. 92 | 93 | **Salida (Exit Criteria):** 94 | - Informe de pruebas generado y compartido con las partes interesadas. 95 | - Decisión tomada sobre la liberación del software o la necesidad de más pruebas. 96 | 97 | **Ejemplo del mundo real:** Después de probar un sistema de reservas de vuelos, el equipo de QA prepara un informe que muestra cuántos casos de prueba se ejecutaron, cuántos pasaron y fallaron, y si los problemas encontrados afectan funciones críticas. Si se encuentran errores en la selección de asientos, se recomienda volver a probar después de las correcciones. 98 | 99 | --- 100 | 101 | ### 5. **Cierre de Pruebas** 102 | El cierre de pruebas es la fase final del STLC, en la que el equipo verifica que todas las pruebas planificadas se hayan completado y que todos los defectos importantes se hayan resuelto. También se realiza una retrospectiva para identificar qué funcionó bien y qué podría mejorarse en futuros proyectos. 103 | 104 | **Actividades clave:** 105 | - Verificar que todos los casos de prueba planificados se hayan ejecutado. 106 | - Asegurarse de que todos los defectos críticos se hayan solucionado. 107 | - Realizar una retrospectiva del proyecto para documentar lecciones aprendidas. 108 | - Archivar todos los artefactos de pruebas para referencia futura. 109 | 110 | **Entrada (Entry Criteria):** 111 | - Ejecución de pruebas completada. 112 | - Todos los defectos críticos resueltos y verificados. 113 | 114 | **Salida (Exit Criteria):** 115 | - Informe final de cierre de pruebas. 116 | - Documentación archivada. 117 | - Retrospectiva completada y lecciones aprendidas documentadas. 118 | 119 | **Ejemplo del mundo real:** Imagina que un equipo de QA ha terminado de probar una nueva actualización de software para un sistema de ventas minorista. Después de asegurarse de que todos los casos de prueba planificados se completaron y de que los errores críticos se resolvieron, realizan una reunión para discutir qué se podría mejorar en el futuro (por ejemplo, automatizar ciertas pruebas repetitivas para ahorrar tiempo). 120 | 121 | --- 122 | 123 | ## 🛠️ **Entrada y Salida (Entry & Exit Criteria) para cada Fase del STLC** 124 | 125 | - **Planificación de Pruebas:** 126 | - *Entrada:* Requisitos claros y aprobados. 127 | - *Salida:* Plan de pruebas y estrategia definidos. 128 | 129 | - **Diseño de Casos de Prueba:** 130 | - *Entrada:* Plan de pruebas aprobado. 131 | - *Salida:* Casos de prueba detallados y validados. 132 | 133 | - **Ejecución de Pruebas:** 134 | - *Entrada:* Casos de prueba listos y ambiente de pruebas configurado. 135 | - *Salida:* Resultados de pruebas y reporte de defectos. 136 | 137 | - **Reporte de Pruebas:** 138 | - *Entrada:* Resultados de la ejecución de pruebas. 139 | - *Salida:* Informe de pruebas y recomendaciones. 140 | 141 | - **Cierre de Pruebas:** 142 | - *Entrada:* Todos los defectos críticos resueltos. 143 | - *Salida:* Informe de cierre y lecciones aprendidas. 144 | 145 | --- 146 | 147 | ## 📊 **Cómo Definir la Estrategia de Pruebas** 148 | 149 | Definir una estrategia de pruebas es crucial para asegurar que las actividades de QA se alineen con los objetivos del proyecto. Una buena estrategia de pruebas debe incluir: 150 | 151 | 1. **Objetivos de Pruebas:** ¿Qué se busca lograr con las pruebas? (Ej.: asegurar la estabilidad, detectar errores en la funcionalidad clave, validar la experiencia del usuario). 152 | 153 | 2. **Tipos de Pruebas:** Determinar qué tipos de pruebas se van a realizar (funcionales, de rendimiento, de seguridad, pruebas automatizadas, etc.). 154 | 155 | 3. **Enfoque y Metodología:** ¿Se usará un enfoque ágil, cascada o DevOps? ¿Qué herramientas se utilizarán? 156 | 157 | 4. **Planificación del Ambiente de Pruebas:** Asegurar que los entornos sean similares a producción para que las pruebas sean realistas. 158 | 159 | 5. **Gestión de Riesgos:** Identificar posibles riesgos y establecer cómo se manejarán. 160 | 161 | **Ejemplo:** En un proyecto ágil para una app de mensajería, la estrategia de pruebas podría incluir pruebas automatizadas para las funciones básicas (enviar y recibir mensajes), pruebas de rendimiento para asegurarse de que la app maneje miles de mensajes simultáneamente y pruebas de seguridad para proteger los datos de los usuarios. 162 | 163 | --- 164 | 165 | Siguiendo estas fases y aplicando una estrategia bien definida, te aseguras de que tu proceso de testing sea eficiente, completo y contribuya a un producto final de alta calidad. 166 | 167 | -------------------------------------------------------------------------------- /Modulo-05-Diseño-de-Casos-de-Prueba/README.md: -------------------------------------------------------------------------------- 1 | # 5. Diseño de Casos de Prueba 2 | 3 | El diseño de casos de prueba es fundamental en el proceso de QA, ya que permite definir y documentar cómo se verificará que el software cumple con los requisitos establecidos. Un caso de prueba describe las condiciones, los datos de entrada, los pasos a seguir y los resultados esperados necesarios para validar una funcionalidad específica de la aplicación. 4 | 5 | ## ¿Qué es un Caso de Prueba? 6 | 7 | Un **caso de prueba** es una especificación detallada que define las condiciones y los pasos que se deben seguir para probar una característica particular del software. Cada caso de prueba incluye entradas, resultados esperados y, en algunos casos, los datos necesarios para validar su correcto funcionamiento. Los casos de prueba son útiles no solo para validar la funcionalidad, sino también para documentar el proceso y servir como guía en pruebas futuras. 8 | 9 | ### Estructura de un Caso de Prueba 10 | 11 | 1. **Identificador**: Un código único para referenciar el caso de prueba. 12 | 2. **Título**: Un nombre claro que describa brevemente el objetivo del caso de prueba. 13 | 3. **Precondiciones**: Cualquier condición previa que deba cumplirse antes de ejecutar el caso de prueba (ej., usuario registrado). 14 | 4. **Pasos**: Las acciones que se deben realizar en el sistema para llevar a cabo el caso de prueba. 15 | 5. **Datos de Prueba**: Valores específicos de entrada para cada paso del caso de prueba. 16 | 6. **Resultado Esperado por Paso**: El resultado esperado en cada paso si la aplicación funciona correctamente. 17 | 7. **Resultado Real**: El resultado obtenido tras la ejecución del caso de prueba (solo se completa después de la prueba). 18 | 8. **Estado**: Indica si el caso de prueba fue exitoso o fallido. 19 | 20 | #### Ejemplo de Caso de Prueba para una Función de Login: 21 | 22 | - **Identificador**: TC001 23 | - **Título**: Validar el inicio de sesión con credenciales correctas. 24 | - **Precondiciones**: El usuario debe estar registrado con un nombre de usuario y contraseña válidos. 25 | - **Pasos y Resultados Esperados**: 26 | 27 | 1. **Paso 1**: Navegar a la página de inicio de sesión de la aplicación. 28 | - **Resultado Esperado**: La página de inicio de sesión se carga correctamente, mostrando los campos de usuario, contraseña y el botón "Iniciar sesión". 29 | 30 | 2. **Paso 2**: Ingresar el nombre de usuario válido (`usuario_prueba`) en el campo "Usuario". 31 | - **Resultado Esperado**: El campo acepta el nombre de usuario sin errores ni advertencias. 32 | 33 | 3. **Paso 3**: Ingresar la contraseña válida (`ContraseñaSegura123`) en el campo "Contraseña". 34 | - **Resultado Esperado**: El campo oculta los caracteres de la contraseña (por seguridad) y no muestra mensajes de error. 35 | 36 | 4. **Paso 4**: Hacer clic en el botón "Iniciar sesión". 37 | - **Resultado Esperado**: El sistema valida las credenciales, y el usuario es redirigido a la página de inicio, mostrando un mensaje de bienvenida. 38 | 39 | - **Datos de Prueba**: 40 | - Nombre de usuario: `usuario_prueba` 41 | - Contraseña: `ContraseñaSegura123` 42 | 43 | - **Resultado Real**: *(a completar después de la prueba)*. 44 | - **Estado**: *(Éxito/Fallo)* 45 | 46 | Este nivel de detalle en cada paso permite identificar con precisión dónde ocurre un fallo, lo cual es esencial en pruebas manuales detalladas. 47 | 48 | ## Diferencia entre Casos de Prueba y Scripts de Prueba 49 | 50 | - **Casos de Prueba**: Documentación detallada que especifica pasos, datos y resultados esperados para verificar una funcionalidad. 51 | - **Scripts de Prueba**: Instrucciones de código en pruebas automatizadas para validar funcionalidades sin intervención manual. Requieren conocimientos de programación y suelen estar destinados a tareas repetitivas o con gran volumen de datos. 52 | 53 | ## Técnicas de Diseño de Pruebas 54 | 55 | ### Pruebas de Caja Negra 56 | 57 | En las pruebas de caja negra, el tester no necesita conocer el código ni la lógica interna del sistema. Se enfoca en verificar la funcionalidad desde la perspectiva del usuario. 58 | 59 | 1. **Equivalencia de Partición**: 60 | - Agrupa los datos de entrada en particiones que representan valores equivalentes. 61 | - Ejemplo: En un campo de "edad" (que acepta entre 18 y 99), los valores se dividen en tres particiones: valores válidos (18-99), valores menores a 18 y valores mayores a 99. Se elige al menos un valor de cada partición para probar cómo responde el sistema. 62 | 63 | 2. **Análisis de Valores Límite**: 64 | - Enfoca la prueba en los valores extremos de los rangos de entrada. 65 | - Ejemplo: Para un campo que acepta edades entre 18 y 99, los límites a probar serían 18, 99 y valores cercanos como 17 y 100, ya que los errores suelen ocurrir en estos límites. 66 | 67 | 3. **Tablas de Decisión**: 68 | - Organiza y documenta las combinaciones de condiciones y sus resultados esperados en una tabla. 69 | - Ejemplo: En una aplicación de préstamos, la tabla incluiría variables como el "historial crediticio" y "salario mensual" para verificar si el préstamo se aprueba o rechaza. Cada combinación de condiciones lleva a un resultado específico, útil para asegurar que todas las combinaciones posibles se hayan probado. 70 | 71 | 4. **Transición de Estados**: 72 | - Se basa en cómo el sistema cambia de un estado a otro según diferentes acciones. 73 | - Ejemplo: En un sistema de cajero automático, los estados pueden incluir "Tarjeta Insertada", "PIN Verificado", "Retiro Procesado" y "Tarjeta Eyectada". Cada acción debe llevar al siguiente estado previsto. 74 | 75 | ### Pruebas de Caja Blanca 76 | 77 | En las pruebas de caja blanca, el tester debe tener conocimientos sobre la estructura interna del sistema. Son más comunes en pruebas de desarrollo o automatización, pero en QA Manual es útil conocer los conceptos básicos. 78 | 79 | 1. **Cobertura de Código**: 80 | - Evalúa qué porcentaje del código se ejecuta durante las pruebas. 81 | - Ejemplo: En una función de cálculo que tiene varias condiciones, se prueban todas las rutas posibles de ejecución (caminos) para asegurarse de que se cubre completamente el código. 82 | 83 | 2. **Flujo de Datos**: 84 | - Analiza cómo se manipulan y se transfieren los datos en el sistema. 85 | - Ejemplo: En una función que procesa y almacena la información de un formulario de registro, se verifica que cada dato ingresado (nombre, email, etc.) pase correctamente por el proceso y se almacene de forma correcta y segura en la base de datos. 86 | 87 | Estas técnicas de diseño de pruebas aseguran una cobertura adecuada y ayudan a detectar fallos potenciales en el sistema. Es fundamental documentar cada técnica y caso de prueba de forma clara, ya que sirve como referencia en pruebas futuras y garantiza que el sistema cumpla con los requisitos esperados. 88 | -------------------------------------------------------------------------------- /Modulo-06-Tipos-de-Pruebas-Manuales/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 6: Tipos de Pruebas Manuales 2 | 3 | ## Introducción 4 | En este módulo, abordaremos los diferentes tipos de pruebas manuales esenciales en el proceso de aseguramiento de calidad (QA). Cada tipo de prueba cumple un rol específico y nos ayuda a garantizar que el software cumpla con los requisitos funcionales y no funcionales. 5 | 6 | --- 7 | 8 | ## 1. Pruebas Funcionales 9 | Estas pruebas verifican que el sistema cumple con los requisitos y especificaciones definidas. Se centran en probar lo que hace el sistema desde el punto de vista del usuario, asegurando que las funcionalidades respondan correctamente. 10 | 11 | - **Casos de Uso**: Prueban escenarios específicos de interacción entre el usuario y el sistema, asegurando que las funcionalidades se comporten según lo esperado. 12 | 13 | **Ejemplo**: En una aplicación de banco, un caso de uso puede ser verificar que un usuario pueda realizar una transferencia correctamente. 14 | 15 | - **Escenarios**: Describen situaciones en las que los usuarios interactúan con el sistema. Los escenarios ayudan a estructurar las pruebas funcionales y guían los casos de prueba. 16 | 17 | **Ejemplo**: Probar un proceso de registro, donde el usuario introduce sus datos y recibe un mensaje de confirmación. 18 | 19 | - **Validación de Requerimientos**: Verifica que cada requerimiento funcional se cumpla. 20 | 21 | **Ejemplo**: Si el sistema requiere autenticación, las pruebas funcionales verificarán que sólo los usuarios autorizados puedan acceder. 22 | 23 | --- 24 | 25 | ## 2. Pruebas de Regresión 26 | Aseguran que nuevas funcionalidades o correcciones no afecten las partes ya implementadas. Estas pruebas vuelven a ejecutar casos previamente aprobados para validar que todo sigue funcionando correctamente. 27 | 28 | - **Cómo identificar y seleccionar casos para regresión**: Al implementar un cambio en el sistema, se identifican los módulos y funcionalidades impactados para seleccionar casos de prueba relevantes. 29 | 30 | **Ejemplo**: Después de actualizar el módulo de pago de una app de e-commerce, las pruebas de regresión comprueban que el carrito de compras y el proceso de checkout aún funcionan correctamente. 31 | 32 | --- 33 | 34 | ## 3. Pruebas Exploratorias 35 | Consisten en explorar el sistema de forma libre y sin guías predefinidas, buscando errores y comportamientos inusuales. En estas pruebas, el tester se basa en su experiencia e intuición. 36 | 37 | - **Técnicas y enfoques**: Las pruebas exploratorias no siguen un guion estricto; se exploran diferentes funcionalidades, interacciones y combinaciones de acciones. 38 | 39 | - **Documentación de resultados**: Aunque no se planifican previamente, es esencial documentar cualquier error encontrado o comportamiento inesperado. 40 | 41 | **Ejemplo**: En una app móvil, el tester explora la navegación entre pantallas de perfil y configuración, documentando cualquier problema de interfaz o funcionalidad. 42 | 43 | --- 44 | 45 | ## 4. Pruebas de Usabilidad 46 | Evalúan qué tan fácil es para el usuario interactuar con el sistema, identificando problemas de diseño e interfaz. 47 | 48 | - **Criterios de Evaluación**: La usabilidad se evalúa según la facilidad de uso, eficiencia, accesibilidad y satisfacción del usuario. 49 | 50 | - **Herramientas de seguimiento**: Herramientas como Hotjar o Google Analytics pueden ayudar a observar la interacción del usuario y detectar puntos problemáticos. 51 | 52 | **Ejemplo**: En una app de salud, se realiza una prueba de usabilidad para asegurar que los usuarios puedan ingresar datos de manera rápida y sin confusión. 53 | 54 | --- 55 | 56 | ## 5. Pruebas de Compatibilidad 57 | Verifican que el software funcione correctamente en distintos dispositivos, navegadores y sistemas operativos. 58 | 59 | - **Dispositivos**: Prueban el funcionamiento en una variedad de dispositivos, como móviles, tablets y computadoras. 60 | 61 | - **Navegadores**: Aseguran que la aplicación se vea y funcione bien en Chrome, Firefox, Safari, entre otros. 62 | 63 | - **Sistemas Operativos**: Verifican que el software funcione correctamente en Windows, macOS, iOS, Android, etc. 64 | 65 | **Ejemplo**: En una web de e-commerce, se prueba que el proceso de pago funcione igual de bien en Android e iOS. 66 | 67 | --- 68 | 69 | ## 6. Pruebas de Seguridad (básicas) 70 | Validan que el sistema esté protegido contra accesos no autorizados, garantizando la confidencialidad, integridad y disponibilidad de los datos. 71 | 72 | - **Validaciones de autenticación y autorización**: Aseguran que sólo usuarios autorizados tengan acceso a funcionalidades y datos específicos. 73 | 74 | - **Manejo de errores**: Verifican que los mensajes de error no revelen información sensible. 75 | 76 | **Ejemplo**: En una plataforma bancaria, las pruebas de seguridad comprueban que los usuarios no puedan acceder a cuentas ajenas. 77 | 78 | --- 79 | 80 | ## Otros Tipos de Pruebas Manuales 81 | 82 | ### Pruebas de Integración 83 | Verifican la correcta interacción entre los distintos módulos del sistema, asegurando que los componentes trabajen juntos sin problemas. 84 | 85 | - **Ejemplo**: En un sistema de reserva de vuelos, las pruebas de integración comprueban que el sistema de pagos se comunique correctamente con el sistema de reservas. 86 | 87 | ### Pruebas de Aceptación del Usuario (UAT) 88 | Aseguran que el sistema cumple con las expectativas del usuario final y esté listo para su implementación. Se realizan en un entorno similar al de producción. 89 | 90 | - **Ejemplo**: En una aplicación bancaria, las pruebas UAT validan que los usuarios puedan realizar transferencias y pagos sin problemas. 91 | 92 | ### Pruebas de Carga 93 | Evalúan el rendimiento del sistema bajo condiciones específicas de carga. 94 | 95 | - **Ejemplo**: En un portal de e-commerce, las pruebas de carga verificarían que el sistema pueda manejar múltiples usuarios simultáneos durante una campaña de descuentos. 96 | 97 | ### Pruebas de Instalación y Desinstalación 98 | Aseguran que el software se instale y desinstale correctamente sin afectar el sistema. 99 | 100 | - **Ejemplo**: Al instalar una aplicación en Windows, se verifica que los archivos necesarios se instalen correctamente y que la desinstalación los elimine sin dejar residuos. 101 | 102 | --- 103 | 104 | Este módulo ofrece una visión completa de los diferentes tipos de pruebas manuales fundamentales en QA, asegurando que el software no sólo funcione según los requisitos, sino que también sea robusto, seguro, y amigable para el usuario. 105 | -------------------------------------------------------------------------------- /Modulo-07-Gestion-de-Defectos/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 7: Gestión de Defectos 2 | 3 | ## Introducción 4 | La gestión de defectos es un aspecto fundamental en el aseguramiento de la calidad del software. Implica la identificación, registro, seguimiento y resolución de defectos o bugs que se presentan durante el ciclo de vida del desarrollo de software. Este módulo explorará qué es un defecto, su ciclo de vida, las herramientas para su gestión y cómo escribir reportes de defectos efectivos. 5 | 6 | --- 7 | 8 | ## 1. ¿Qué es un Defecto/Bug? 9 | Un defecto o bug es cualquier falla en el software que provoca que no funcione de acuerdo a los requisitos o especificaciones establecidos. Estos defectos pueden surgir de varias fuentes, como errores en el código, malentendidos de los requisitos, o problemas de diseño. 10 | 11 | ### Tipos de Defectos 12 | - **Errores de Código**: Bugs resultantes de fallos en la lógica del programa. 13 | - **Errores de Diseño**: Problemas que surgen de un diseño inadecuado que no cumple con los requisitos del cliente. 14 | - **Errores de Requisitos**: Defectos causados por requisitos mal definidos o incompletos. 15 | 16 | **Ejemplo**: Si un botón de "Enviar" en un formulario no realiza ninguna acción al ser clicado, esto es un defecto que afecta la funcionalidad del sistema. 17 | 18 | --- 19 | 20 | ## 2. Ciclo de Vida de un Defecto 21 | El ciclo de vida de un defecto describe las diferentes etapas que atraviesa desde su identificación hasta su resolución. Las etapas comunes incluyen: 22 | 23 | 1. **Nuevo**: El defecto ha sido reportado pero no ha sido revisado aún. 24 | 25 | 2. **Asignado**: Un desarrollador ha sido asignado para investigar y corregir el defecto. 26 | 27 | 3. **Corregido**: El desarrollador ha realizado los cambios necesarios en el código para resolver el defecto. 28 | 29 | 4. **Verificado**: El equipo de QA verifica que el defecto ha sido corregido y que el software funciona como se esperaba. 30 | 31 | 5. **Cerrado**: El defecto ha sido confirmado como resuelto y se cierra en el sistema de gestión. 32 | 33 | ### Ejemplo del Ciclo de Vida 34 | - **Nuevo**: Un QA encuentra un bug y lo reporta en JIRA como "Nuevo". 35 | - **Asignado**: Un desarrollador revisa el ticket y lo asigna a sí mismo. 36 | - **Corregido**: El desarrollador realiza los cambios y actualiza el estado a "Corregido". 37 | - **Verificado**: El QA realiza pruebas y confirma que el defecto está resuelto. 38 | - **Cerrado**: El ticket se cierra y se registra como "Cerrado". 39 | 40 | --- 41 | 42 | ## 3. Herramientas para Gestión de Defectos 43 | Existen varias herramientas que ayudan en la gestión de defectos. Algunas de las más populares son: 44 | 45 | ### 3.1 JIRA 46 | - **Descripción**: Herramienta de gestión de proyectos ampliamente utilizada que incluye funcionalidades para la gestión de defectos. 47 | - **Funcionalidades**: Permite crear, asignar, rastrear y cerrar tickets de defectos de manera eficiente. Los equipos pueden agregar comentarios, adjuntar archivos y establecer prioridades. 48 | 49 | ### 3.2 Bugzilla 50 | - **Descripción**: Herramienta diseñada específicamente para la gestión de defectos en proyectos de software. 51 | - **Funcionalidades**: Ofrece características como seguimiento de errores, asignación de tareas y generación de reportes sobre defectos. 52 | 53 | ### 3.3 Trello 54 | - **Descripción**: Herramienta de gestión de proyectos que puede ser adaptada para la gestión de defectos. 55 | - **Funcionalidades**: Permite crear tarjetas para cada defecto y organizarlas en columnas que representan diferentes estados del ciclo de vida. 56 | 57 | **Ejemplo de uso de JIRA**: 58 | 1. Un QA encuentra un defecto y crea un ticket en JIRA. 59 | 2. Asigna el ticket a un desarrollador. 60 | 3. El desarrollador corrige el bug y actualiza el estado del ticket a "Corregido". 61 | 4. El QA verifica la solución y cambia el estado a "Cerrado". 62 | 63 | --- 64 | 65 | ## 4. Cómo Escribir Reportes de Defectos Efectivos 66 | Un reporte de defecto efectivo debe contener información clara y concisa que permita al equipo de desarrollo entender y reproducir el problema. Los elementos clave incluyen: 67 | 68 | ### 4.1 Elementos de un Reporte de Defecto 69 | - **Descripción**: Un resumen breve pero claro del defecto. 70 | 71 | - **Pasos para Reproducir**: Una lista detallada de los pasos necesarios para replicar el defecto. Esto incluye acciones específicas que un usuario debe seguir. 72 | 73 | - **Severidad**: Clasifica el impacto del defecto en el sistema (por ejemplo, crítico, mayor, menor). 74 | 75 | - **Prioridad**: Indica la urgencia de resolver el defecto (alta, media, baja). 76 | 77 | ### 4.2 Ejemplo de Reporte de Defecto: 78 | 79 | Descripción: El botón "Enviar" en la página de contacto no responde al hacer clic. Pasos para Reproducir: 80 | 81 | Ir a la página de contacto. 82 | Completar el formulario de contacto. 83 | Hacer clic en el botón "Enviar". Severidad: Crítico (impide que los usuarios envíen información). Prioridad: Alta (debe ser corregido antes del lanzamiento). 84 | -------------------------------------------------------------------------------- /Modulo-08-Herramientas-de-QA-Manual/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 8: Herramientas de QA Manual 2 | 3 | ## Introducción 4 | En el ámbito del aseguramiento de la calidad, contar con herramientas adecuadas es crucial para optimizar el proceso de prueba y gestión de defectos. Este módulo explorará las herramientas más utilizadas en la gestión de pruebas, la gestión de proyectos y la documentación y colaboración, proporcionando ejemplos y descripciones detalladas de cada una. 5 | 6 | --- 7 | 8 | ## 1. Introducción a Herramientas de Gestión de Pruebas 9 | Las herramientas de gestión de pruebas ayudan a planificar, rastrear y organizar el proceso de pruebas. Estas herramientas son esenciales para documentar casos de prueba, gestionar la ejecución de pruebas y realizar un seguimiento de los defectos encontrados. 10 | 11 | ### 1.1 TestRail 12 | - **Descripción**: TestRail es una herramienta de gestión de pruebas que permite a los equipos planificar y ejecutar pruebas de manera eficiente. 13 | - **Funcionalidades**: 14 | - **Gestión de Casos de Prueba**: Permite crear y organizar casos de prueba, asignarles prioridades y realizar un seguimiento de su ejecución. 15 | - **Reportes y Análisis**: Genera informes sobre la cobertura de pruebas, el estado de los defectos y el rendimiento general del equipo de pruebas. 16 | 17 | **Ejemplo de uso de TestRail**: 18 | 1. Un QA crea un nuevo caso de prueba para una funcionalidad específica. 19 | 2. Asigna el caso de prueba a un ciclo de pruebas y establece su prioridad. 20 | 3. Después de ejecutar las pruebas, el QA registra los resultados y cualquier defecto encontrado. 21 | 22 | ### 1.2 Zephyr 23 | - **Descripción**: Zephyr es otra herramienta popular para la gestión de pruebas, que se integra fácilmente con herramientas de gestión de proyectos como JIRA. 24 | - **Funcionalidades**: 25 | - **Gestión de Casos de Prueba**: Permite la creación y gestión de casos de prueba directamente en JIRA. 26 | - **Ejecutar Pruebas**: Facilita la ejecución de pruebas y la documentación de resultados. 27 | 28 | ### 1.3 TestLink 29 | - **Descripción**: TestLink es una herramienta de código abierto para la gestión de pruebas. 30 | - **Funcionalidades**: 31 | - **Planificación de Pruebas**: Permite la creación de planes de prueba y la asignación de casos de prueba a diferentes ciclos. 32 | - **Gestión de Defectos**: Integra la gestión de defectos y permite su seguimiento. 33 | 34 | --- 35 | 36 | ## 2. Herramientas para Gestión de Proyectos 37 | La gestión de proyectos es esencial para coordinar los esfuerzos de desarrollo y pruebas. Las herramientas de gestión de proyectos permiten a los equipos colaborar, asignar tareas y hacer un seguimiento del progreso. 38 | 39 | ### 2.1 JIRA 40 | - **Descripción**: JIRA es una herramienta de gestión de proyectos muy utilizada en el desarrollo ágil. 41 | - **Funcionalidades**: 42 | - **Gestión de Tickets**: Permite crear tickets para defectos y tareas, asignarlos a miembros del equipo y establecer prioridades. 43 | - **Visualización de Proyectos**: Proporciona tableros kanban y gráficos burndown para visualizar el progreso. 44 | 45 | ### 2.2 Trello 46 | - **Descripción**: Trello es una herramienta visual para la gestión de proyectos basada en tarjetas. 47 | - **Funcionalidades**: 48 | - **Organización Visual**: Los equipos pueden crear tableros para diferentes proyectos, moviendo tarjetas entre columnas que representan diferentes estados de avance. 49 | - **Colaboración en Tiempo Real**: Los miembros del equipo pueden comentar y adjuntar archivos a las tarjetas. 50 | 51 | ### 2.3 Asana 52 | - **Descripción**: Asana es una herramienta de gestión de proyectos que permite la planificación y seguimiento de tareas. 53 | - **Funcionalidades**: 54 | - **Tareas y Proyectos**: Permite crear tareas, asignarlas a miembros del equipo y establecer fechas de entrega. 55 | - **Integraciones**: Se integra con otras herramientas para mejorar la colaboración y el seguimiento. 56 | 57 | --- 58 | 59 | ## 3. Herramientas para Documentación y Colaboración 60 | La documentación es clave en el proceso de QA, y las herramientas adecuadas facilitan la colaboración entre los miembros del equipo. 61 | 62 | ### 3.1 Confluence 63 | - **Descripción**: Confluence es una herramienta de colaboración que permite crear y compartir documentación. 64 | - **Funcionalidades**: 65 | - **Espacios de Trabajo**: Los equipos pueden crear espacios para proyectos específicos, donde pueden documentar requisitos, procesos y resultados de pruebas. 66 | - **Integración con JIRA**: Facilita la vinculación entre tickets de JIRA y la documentación. 67 | 68 | ### 3.2 Google Docs 69 | - **Descripción**: Google Docs es una herramienta de procesamiento de texto en línea que permite la colaboración en tiempo real. 70 | - **Funcionalidades**: 71 | - **Documentación Compartida**: Los equipos pueden trabajar juntos en documentos, realizar comentarios y realizar cambios en tiempo real. 72 | - **Accesibilidad**: Permite el acceso desde cualquier lugar y en cualquier dispositivo con conexión a Internet. 73 | 74 | --- 75 | 76 | ## Conclusión 77 | El uso de herramientas adecuadas es fundamental para un proceso de QA eficiente. Desde la gestión de pruebas hasta la gestión de proyectos y la documentación, estas herramientas ayudan a los equipos a colaborar mejor y a asegurar la calidad del software de manera efectiva. La selección de las herramientas correctas puede marcar una gran diferencia en la calidad del producto final y en la satisfacción del cliente. 78 | -------------------------------------------------------------------------------- /Modulo-09-Documentacion-de-Pruebas/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 9: Documentación de Pruebas 2 | 3 | ## Introducción 4 | La documentación de pruebas es una parte esencial del proceso de QA, ya que garantiza que todo el proceso de pruebas esté bien planificado, estructurado y documentado para que otros miembros del equipo puedan entenderlo y seguirlo. Este módulo te enseñará cómo crear y gestionar documentos clave de pruebas, desde el plan de pruebas hasta los reportes de ejecución. 5 | 6 | --- 7 | 8 | ## 1. Plan de Pruebas 9 | ### ¿Qué es un Plan de Pruebas? 10 | Un plan de pruebas es un documento detallado que describe el enfoque, los objetivos, los recursos y el cronograma de las actividades de prueba para un proyecto. Actúa como una guía para el equipo de pruebas y asegura que todos estén alineados. 11 | 12 | ### ¿Cómo crear un Plan de Pruebas? 13 | 1. **Objetivos de la prueba**: Define claramente qué se espera lograr con las pruebas (por ejemplo, validar la funcionalidad principal de una aplicación web). 14 | 2. **Alcance de las pruebas**: Detalla qué funcionalidades se van a probar y cuáles están fuera del alcance. 15 | 3. **Recursos y roles**: Especifica quién estará a cargo de cada tarea (QA, desarrolladores, analistas). 16 | 4. **Cronograma**: Indica las fechas clave para la planificación, ejecución y finalización de las pruebas. 17 | 5. **Criterios de aceptación**: Define cuándo una prueba se considera exitosa. 18 | 19 | **Ejemplo de un objetivo de plan de pruebas**: 20 | > Verificar que la funcionalidad de inicio de sesión cumpla con los requisitos de seguridad y usabilidad. 21 | 22 | --- 23 | 24 | ## 2. Estrategia de Pruebas 25 | ### ¿Qué es una Estrategia de Pruebas? 26 | Es un enfoque de alto nivel que describe cómo se llevarán a cabo las pruebas en el proyecto. La estrategia de pruebas define el tipo de pruebas, los métodos y las herramientas que se usarán. 27 | 28 | ### Componentes de una Estrategia de Pruebas 29 | - **Objetivos de la estrategia**: Qué se pretende lograr con la estrategia de pruebas (e.g., asegurar la cobertura de pruebas en componentes críticos). 30 | - **Alcance y cobertura**: Áreas de la aplicación que se probarán. 31 | - **Tipos de pruebas a realizar**: Funcionales, no funcionales, de regresión, etc. 32 | - **Criterios de aceptación y salida**: Define cuándo se puede proceder al siguiente paso o finalizar el proceso de pruebas. 33 | 34 | **Ejemplo de un criterio de salida**: 35 | > Todos los casos de prueba críticos deben pasar con éxito y no debe haber defectos de alta severidad. 36 | 37 | --- 38 | 39 | ## 3. Casos de Prueba 40 | ### ¿Cómo escribir casos de prueba claros y efectivos? 41 | Un caso de prueba es un conjunto de condiciones o acciones que se ejecutan para verificar una funcionalidad específica del software. 42 | 43 | ### Estructura de un caso de prueba: 44 | 1. **ID del caso de prueba**: Un identificador único (e.g., TC001). 45 | 2. **Título**: Breve descripción de lo que se va a probar (e.g., "Verificar la funcionalidad de inicio de sesión"). 46 | 3. **Precondiciones**: Los requisitos previos antes de ejecutar el caso (e.g., "El usuario debe estar registrado"). 47 | 4. **Pasos de prueba**: 48 | - Ingresar el nombre de usuario. 49 | - Ingresar la contraseña. 50 | - Hacer clic en "Iniciar sesión". 51 | 5. **Resultado esperado**: Qué debe ocurrir después de ejecutar los pasos (e.g., "El usuario es redirigido a su panel de control"). 52 | 6. **Resultado real**: Documentar lo que ocurrió realmente al ejecutar el caso. 53 | 7. **Estado**: Aprobado o fallido. 54 | 55 | **Ejemplo de caso de prueba**: 56 | | ID | TC001 | 57 | |--------|-------------------------------------------| 58 | | Título | Verificar inicio de sesión con datos válidos | 59 | | Precondiciones | El usuario está registrado | 60 | | Pasos | 1. Ir a la página de inicio de sesión
2. Ingresar usuario
3. Ingresar contraseña
4. Clic en "Iniciar sesión" | 61 | | Resultado esperado | El usuario accede al panel de control | 62 | | Resultado real | [Completar tras ejecución] | 63 | | Estado | [Aprobado/Fallido] | 64 | 65 | --- 66 | 67 | ## 4. Reportes de Ejecución de Pruebas 68 | ### ¿Cómo documentar los resultados de la ejecución? 69 | La documentación de los resultados es fundamental para analizar el estado de las pruebas y tomar decisiones informadas. 70 | 71 | ### Componentes de un reporte de ejecución: 72 | - **Resumen de la prueba**: Breve resumen de lo que se probó y los resultados generales. 73 | - **Casos de prueba ejecutados**: Lista de casos de prueba con sus resultados. 74 | - **Defectos encontrados**: Un resumen de los defectos identificados durante la ejecución. 75 | - **Recomendaciones**: Pasos a seguir basados en los resultados (e.g., "Repetir pruebas después de corregir defectos"). 76 | 77 | **Ejemplo de reporte de ejecución**: 78 | Se probaron 20 casos de prueba relacionados con la funcionalidad de inicio de sesión. Resultados: 18 casos aprobados, 2 fallidos. Defectos: Se reportaron 2 defectos críticos. Recomendación: Corregir defectos antes de proceder con más pruebas. 79 | 80 | -------------------------------------------------------------------------------- /Modulo-10-Automatizacion-de-Pruebas-Introduccion-para-QA-Manual/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 10: Automatización de Pruebas - Introducción para QA Manual 2 | 3 | ## Introducción 4 | La automatización de pruebas es el uso de herramientas y scripts para realizar pruebas de software de manera automática, con el objetivo de aumentar la eficiencia y cobertura del proceso de pruebas. En este módulo, exploraremos los fundamentos de la automatización de pruebas, sus ventajas y desventajas, y cuándo es recomendable aplicarla. 5 | 6 | --- 7 | 8 | ## 1. ¿Cuándo automatizar y cuándo no? 9 | ### Casos ideales para automatizar: 10 | - **Pruebas repetitivas**: Aquellas que necesitan ser ejecutadas frecuentemente, como pruebas de regresión. 11 | - **Pruebas de alto riesgo**: Escenarios críticos que requieren validación constante. 12 | - **Pruebas que requieren grandes volúmenes de datos**: Automatizar permite realizar pruebas con diferentes conjuntos de datos rápidamente. 13 | - **Pruebas que necesitan ser ejecutadas en múltiples entornos**: Asegura que la aplicación funcione de manera consistente en diferentes plataformas. 14 | 15 | ### Casos donde NO es ideal automatizar: 16 | - **Pruebas de usabilidad**: Requieren la evaluación subjetiva de un humano. 17 | - **Pruebas ad hoc/exploratorias**: Necesitan de la intuición y análisis humano. 18 | - **Pruebas que se ejecutan solo una vez**: No es eficiente invertir tiempo en automatizar algo que no se repetirá. 19 | 20 | --- 21 | 22 | ## 2. Diferencias entre QA Manual y Automatizado 23 | ### QA Manual: 24 | - **Proceso**: Implica la ejecución manual de casos de prueba por parte de un tester. 25 | - **Flexibilidad**: Permite al tester observar aspectos subjetivos como la experiencia del usuario. 26 | - **Costo**: Generalmente menor al inicio, pero se vuelve más costoso en pruebas repetitivas. 27 | 28 | ### QA Automatizado: 29 | - **Proceso**: Usa scripts y herramientas para ejecutar pruebas sin intervención humana. 30 | - **Eficiencia**: Reduce el tiempo de ejecución de pruebas masivas y repetitivas. 31 | - **Mantenimiento**: Puede requerir un alto costo de mantenimiento de scripts y frameworks. 32 | 33 | **Ejemplo**: 34 | - *QA Manual*: Un tester verifica manualmente que los botones de una aplicación respondan correctamente. 35 | - *QA Automatizado*: Un script de Selenium verifica automáticamente el comportamiento de los botones en múltiples navegadores. 36 | 37 | --- 38 | 39 | ## 3. Ventajas y Desventajas de la Automatización 40 | ### Ventajas: 41 | - **Ahorro de tiempo**: Las pruebas que se ejecutan automáticamente son mucho más rápidas que las manuales. 42 | - **Mayor cobertura de pruebas**: Permite validar más escenarios y casos de prueba. 43 | - **Repetibilidad**: Las pruebas pueden ejecutarse tantas veces como se necesite con los mismos resultados. 44 | - **Detección temprana de defectos**: La ejecución regular de pruebas automatizadas ayuda a identificar problemas en etapas tempranas del desarrollo. 45 | 46 | ### Desventajas: 47 | - **Alto costo inicial**: Se necesita tiempo y recursos para desarrollar scripts y configurar herramientas. 48 | - **Mantenimiento de scripts**: Los cambios en la aplicación pueden requerir actualizaciones frecuentes en los scripts de prueba. 49 | - **No apto para pruebas subjetivas**: La automatización no puede evaluar la experiencia del usuario o aspectos creativos. 50 | 51 | --- 52 | 53 | ## 4. Herramientas Populares de Automatización (Introducción) 54 | ### 1. **Selenium**: 55 | - **Descripción**: Una de las herramientas más populares para la automatización de pruebas web. 56 | - **Características**: Permite escribir scripts en múltiples lenguajes como Java, Python y C#. 57 | - **Uso**: Ideal para pruebas de regresión y pruebas funcionales en aplicaciones web. 58 | 59 | ### 2. **Appium**: 60 | - **Descripción**: Herramienta de código abierto para pruebas de aplicaciones móviles (iOS y Android). 61 | - **Características**: Soporta múltiples lenguajes y plataformas, ideal para proyectos móviles. 62 | - **Ejemplo de uso**: Automatizar la prueba de inicio de sesión en una app móvil. 63 | 64 | ### 3. **Cypress**: 65 | - **Descripción**: Herramienta moderna para la automatización de pruebas web, con enfoque en aplicaciones de una sola página (SPA). 66 | - **Características**: Ofrece una experiencia de prueba rápida y fácil de configurar. 67 | - **Ventajas**: Integración directa con el código y pruebas en tiempo real. 68 | 69 | **Ejemplo de script en Selenium (Java)**: 70 | ```java 71 | import org.openqa.selenium.WebDriver; 72 | import org.openqa.selenium.chrome.ChromeDriver; 73 | 74 | public class TestLogin { 75 | public static void main(String[] args) { 76 | System.setProperty("webdriver.chrome.driver", "ruta/al/driver/chromedriver"); 77 | WebDriver driver = new ChromeDriver(); 78 | driver.get("https://ejemplo.com/login"); 79 | 80 | // Pasos para automatizar la prueba de inicio de sesión 81 | // (Buscar elementos, interactuar y verificar resultados) 82 | 83 | driver.quit(); 84 | } 85 | } 86 | -------------------------------------------------------------------------------- /Modulo-11-Pruebas-en-Entornos-Agiles/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 11: Pruebas en Entornos Ágiles 2 | 3 | ## 1. ¿Qué es Agile y cómo se diferencia de otros enfoques? 4 | **Agile** es un marco de trabajo basado en la colaboración, la flexibilidad y la entrega rápida de valor al cliente. A diferencia de enfoques tradicionales como Waterfall, Agile se centra en: 5 | - **Iteraciones cortas**: Desarrollo y entrega de incrementos de producto en ciclos pequeños (generalmente de 2 a 4 semanas). 6 | - **Adaptabilidad**: Responder rápidamente a cambios en los requisitos. 7 | - **Colaboración constante**: Comunicación cercana entre los equipos y con los clientes. 8 | 9 | **Diferencias clave**: 10 | - **Waterfall**: Proceso lineal y secuencial; las pruebas se realizan después del desarrollo completo. 11 | - **Agile**: Desarrollo y pruebas se realizan de manera iterativa y continua. 12 | 13 | --- 14 | 15 | ## 2. QA en metodologías ágiles: Scrum y Kanban 16 | ### Scrum: 17 | Scrum es un marco de trabajo ágil que organiza el desarrollo en **sprints**. Cada sprint tiene ceremonias específicas donde el QA juega un papel importante. 18 | 19 | - **Rol del QA en Scrum**: 20 | - Participar en la **planificación del sprint** para revisar y entender los requerimientos. 21 | - Colaborar con desarrolladores para crear casos de prueba en paralelo al desarrollo. 22 | - Ejecutar pruebas durante el sprint y validar las historias de usuario antes de que se consideren "completas". 23 | 24 | - **Ejemplo de tareas del QA en un sprint**: 25 | - Revisar criterios de aceptación. 26 | - Diseñar casos de prueba basados en las historias de usuario. 27 | - Probar funcionalidades entregadas y reportar defectos en tiempo real. 28 | 29 | ### Kanban: 30 | Kanban utiliza un tablero visual para gestionar el flujo de trabajo. No tiene sprints definidos, pero el QA asegura la calidad en cada etapa del tablero (p. ej., "En progreso", "En revisión", "Hecho"). 31 | 32 | - **Rol del QA en Kanban**: 33 | - Garantizar que las tareas etiquetadas como "Listas para pruebas" se validen rápidamente. 34 | - Automatizar casos de prueba recurrentes para acelerar el flujo. 35 | 36 | --- 37 | 38 | ## 3. Concepto de pruebas continuas y DevOps 39 | ### Pruebas continuas: 40 | En Agile, las pruebas no se limitan a una fase específica; se ejecutan de manera continua durante todo el ciclo de desarrollo. Esto implica: 41 | - **Automatización de pruebas**: Ayuda a ejecutar rápidamente pruebas de regresión. 42 | - **Validaciones frecuentes**: Los testers trabajan junto con los desarrolladores para validar pequeños cambios constantemente. 43 | 44 | ### DevOps: 45 | DevOps combina desarrollo y operaciones para entregar software de manera más rápida y confiable. 46 | - **Pruebas en DevOps**: 47 | - Se integran en pipelines de CI/CD (Integración y Entrega Continua). 48 | - Aseguran que cada cambio en el código pase por pruebas automatizadas antes de llegar a producción. 49 | 50 | **Ejemplo**: 51 | Un pipeline de CI/CD ejecuta pruebas automatizadas en Selenium cada vez que un desarrollador realiza un commit en Git. 52 | 53 | --- 54 | 55 | ## 4. Reuniones clave en Agile y participación del QA 56 | En un entorno ágil, el equipo participa en varias ceremonias para alinear prioridades y garantizar que el producto cumple con las expectativas. Estas reuniones son esenciales tanto para los desarrolladores como para los QAs. 57 | 58 | ### **Reuniones del marco Scrum** 59 | 1. **Sprint Planning (Planificación del Sprint)**: 60 | - Propósito: Planificar las tareas que se completarán durante el sprint. 61 | - Rol del QA: 62 | - Revisar las historias de usuario y sus criterios de aceptación. 63 | - Aportar información sobre riesgos y dependencias. 64 | - Estimar el esfuerzo requerido para las pruebas. 65 | 66 | 2. **Daily Stand-up (Reunión diaria)**: 67 | - Propósito: Compartir actualizaciones rápidas sobre el progreso del equipo. 68 | - Rol del QA: 69 | - Informar sobre el estado de las pruebas. 70 | - Escalar bloqueos relacionados con defectos o dependencias. 71 | 72 | 3. **Sprint Review (Revisión del Sprint)**: 73 | - Propósito: Demostrar el trabajo completado durante el sprint. 74 | - Rol del QA: 75 | - Presentar resultados de las pruebas realizadas. 76 | - Participar en la validación del producto con el cliente o stakeholders. 77 | 78 | 4. **Sprint Retrospective (Retrospectiva del Sprint)**: 79 | - Propósito: Identificar áreas de mejora en el proceso del equipo. 80 | - Rol del QA: 81 | - Compartir desafíos encontrados durante las pruebas. 82 | - Sugerir cambios para mejorar la calidad en futuros sprints. 83 | 84 | ### **Reuniones adicionales** 85 | - **Backlog Refinement (Refinamiento del Backlog)**: 86 | - Propósito: Detallar y priorizar las historias de usuario. 87 | - Rol del QA: 88 | - Validar que los criterios de aceptación sean claros y probables de probar. 89 | - Identificar posibles escenarios negativos o riesgos. 90 | 91 | --- 92 | 93 | ## 5. ¿Qué es el backlog y cuál es su relación con el QA? 94 | El **backlog** es una lista priorizada de requisitos, historias de usuario y tareas pendientes. Se divide en: 95 | - **Product Backlog**: Contiene todas las funcionalidades que el producto debe tener. 96 | - **Sprint Backlog**: Subconjunto del product backlog seleccionado para el sprint actual. 97 | 98 | **Relación con el QA**: 99 | - El QA revisa las historias de usuario para asegurar que los criterios de aceptación sean claros. 100 | - Ayuda a identificar dependencias o posibles problemas antes de que se planifiquen en un sprint. 101 | 102 | --- 103 | 104 | ## 6. ¿Qué es un Product Owner y cómo interactúa con el Scrum Team? 105 | El **Product Owner (PO)** es responsable de maximizar el valor del producto. Sus funciones incluyen: 106 | - Crear y priorizar el product backlog. 107 | - Definir criterios de aceptación para cada historia de usuario. 108 | - Aclarar dudas del equipo de desarrollo y QA sobre los requisitos. 109 | 110 | **Comunicación con el Scrum Team**: 111 | - El PO trabaja estrechamente con el Scrum Master, desarrolladores y QA para garantizar que el equipo entienda los objetivos del producto. 112 | - El QA consulta al PO para aclarar criterios de aceptación y validar escenarios específicos durante las pruebas. 113 | 114 | --- 115 | 116 | ## Conclusión 117 | El QA desempeña un papel crucial en Agile al garantizar que el producto mantenga su calidad a través de colaboración, pruebas continuas y participación activa en ceremonias clave. Entender cómo se gestionan las reuniones y las responsabilidades del Product Owner mejora significativamente la integración del QA en el proceso ágil. 118 | -------------------------------------------------------------------------------- /Modulo-12-Buenas-Practicas-en-QA-Manual/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 12: Buenas Prácticas en QA Manual 2 | 3 | Las buenas prácticas en QA manual son esenciales para garantizar que el software cumpla con los estándares de calidad, se entregue a tiempo y satisfaga las necesidades del cliente. En este módulo, exploraremos las mejores estrategias para planificar y ejecutar pruebas efectivas, priorizar tareas, y mantener una comunicación clara con los equipos de desarrollo y stakeholders. 4 | 5 | --- 6 | 7 | ## 1. Cómo planificar pruebas efectivas 8 | 9 | ### **¿Por qué es importante planificar las pruebas?** 10 | La planificación adecuada permite detectar defectos de manera eficiente, optimizar recursos y asegurar que el proceso de pruebas cubra todos los aspectos críticos del producto. 11 | 12 | ### **Pasos clave para planificar pruebas efectivas:** 13 | 1. **Entender los requisitos del proyecto:** 14 | - Reunirse con los stakeholders para identificar los objetivos del producto. 15 | - Revisar historias de usuario, criterios de aceptación y documentación técnica. 16 | 17 | **Ejemplo:** 18 | Si el requisito es "El usuario debe poder registrarse con su correo electrónico", define qué datos debe ingresar y qué validaciones son necesarias. 19 | 20 | 2. **Definir un alcance claro:** 21 | - Especificar qué partes del sistema serán probadas. 22 | - Identificar las exclusiones (funcionalidades no probadas en esta etapa). 23 | 24 | **Ejemplo de alcance:** 25 | "Probar el registro de usuarios para los navegadores Chrome y Firefox en escritorio. Excluir pruebas en dispositivos móviles para esta iteración." 26 | 27 | 3. **Seleccionar tipos de pruebas necesarios:** 28 | - Decidir si se realizarán pruebas funcionales, de regresión, exploratorias, etc. 29 | 30 | 4. **Asignar recursos:** 31 | - Determinar quién ejecutará las pruebas y qué herramientas se utilizarán. 32 | 33 | 5. **Crear un cronograma:** 34 | - Establecer plazos para las fases de diseño, ejecución y reporte. 35 | 36 | --- 37 | 38 | ## 2. Estrategias para priorizar casos de prueba 39 | 40 | Cuando los recursos son limitados, es crucial priorizar los casos de prueba para enfocarse en las áreas más críticas del producto. 41 | 42 | ### **Criterios para priorizar:** 43 | 1. **Impacto en el negocio:** 44 | - Prioriza las funcionalidades que afectan directamente al usuario final. 45 | 46 | **Ejemplo:** Probar el flujo de pago antes de probar cambios en el diseño de la interfaz. 47 | 48 | 2. **Probabilidad de defectos:** 49 | - Enfócate en áreas que históricamente han tenido más errores o que son nuevas. 50 | 51 | **Ejemplo:** Validar una nueva API de integración antes de probar funcionalidades existentes. 52 | 53 | 3. **Riesgos asociados:** 54 | - Probar funcionalidades críticas como la seguridad o el manejo de datos sensibles. 55 | 56 | **Ejemplo:** Validar que los usuarios solo puedan acceder a datos autorizados. 57 | 58 | 4. **Frecuencia de uso:** 59 | - Prioriza las funciones que los usuarios utilizan con mayor frecuencia. 60 | 61 | **Ejemplo:** Probar el inicio de sesión en todas las plataformas soportadas. 62 | 63 | --- 64 | 65 | ## 3. Comunicación con desarrolladores y otros stakeholders 66 | 67 | ### **Por qué es importante una comunicación efectiva** 68 | El QA sirve como puente entre el equipo de desarrollo, el Product Owner y otros stakeholders. Una comunicación clara ayuda a resolver problemas rápidamente y asegura que todos trabajen hacia los mismos objetivos. 69 | 70 | ### **Mejores prácticas para la comunicación:** 71 | 1. **Participar activamente en reuniones:** 72 | - Asiste a las ceremonias ágiles (planificación, retrospectivas, etc.). 73 | - Expón los riesgos y problemas encontrados durante las pruebas. 74 | 75 | 2. **Usar herramientas de colaboración:** 76 | - Documenta y comparte hallazgos en herramientas como JIRA, Confluence o Google Docs. 77 | 78 | 3. **Proveer retroalimentación constructiva:** 79 | - Enfócate en describir el problema y sus implicaciones en lugar de culpar. 80 | 81 | **Ejemplo:** 82 | "He encontrado un defecto en la funcionalidad X. Si no se corrige, podría causar problemas en el flujo de Y." 83 | 84 | 4. **Mantener una comunicación constante:** 85 | - Haz seguimiento a los defectos reportados y consulta a los desarrolladores cuando tengas dudas sobre la funcionalidad esperada. 86 | 87 | --- 88 | 89 | ## 4. Mejores prácticas para asegurarse de que el producto cumpla con los estándares de calidad 90 | 91 | ### **Revisión y seguimiento continuo:** 92 | 1. **Revisar criterios de aceptación:** 93 | - Antes de ejecutar las pruebas, asegúrate de que los criterios sean claros y verificables. 94 | 95 | 2. **Automatizar pruebas repetitivas:** 96 | - Implementa pruebas automatizadas para regresión y enfócate en casos más complejos manualmente. 97 | 98 | 3. **Realizar pruebas cruzadas:** 99 | - Ejecuta pruebas en diferentes dispositivos, navegadores y entornos. 100 | 101 | **Ejemplo:** 102 | Probar en Chrome, Firefox y Safari, tanto en sistemas operativos Windows como macOS. 103 | 104 | 4. **Documentar todo:** 105 | - Registra los resultados de las pruebas, defectos encontrados y lecciones aprendidas. 106 | 107 | 5. **Realizar revisiones postmortem:** 108 | - Analiza el proceso de pruebas al final del proyecto para identificar áreas de mejora. 109 | 110 | --- 111 | 112 | ## Ejemplo práctico de planificación y ejecución 113 | **Proyecto: E-commerce con funcionalidad de carrito de compras** 114 | 115 | 1. **Entender requisitos:** 116 | - Funcionalidad principal: El usuario puede añadir productos al carrito y realizar la compra. 117 | - Validaciones: 118 | - ¿El carrito actualiza la cantidad correctamente? 119 | - ¿El sistema calcula el precio total con impuestos? 120 | 121 | 2. **Definir alcance:** 122 | - Navegadores: Chrome y Firefox. 123 | - Funciones probadas: 124 | - Agregar producto. 125 | - Eliminar producto. 126 | - Proceder al pago. 127 | 128 | 3. **Priorizar casos de prueba:** 129 | - Prioridad alta: Flujo de pago. 130 | - Prioridad media: Actualización de cantidad. 131 | - Prioridad baja: Guardar carrito para después. 132 | 133 | 4. **Comunicar hallazgos:** 134 | - Reportar defectos con pasos detallados, severidad y prioridad. 135 | - Documentar los resultados en una herramienta como JIRA. 136 | 137 | --- 138 | 139 | ## Conclusión 140 | Las buenas prácticas en QA manual son fundamentales para entregar un producto de alta calidad. Planificar cuidadosamente, priorizar casos de prueba y mantener una comunicación efectiva con el equipo no solo mejora el proceso, sino que asegura la satisfacción del cliente. 141 | 142 | ¡Con estas estrategias, estarás listo para enfrentar cualquier desafío en QA manual! 143 | -------------------------------------------------------------------------------- /Modulo-13-Preparacion-para-Entrevistas-de-QA-Manual/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 13: Preparación para Entrevistas de QA Manual 2 | 3 | Este módulo está diseñado para ayudarte a destacar en entrevistas de QA manual. Cubriremos las preguntas más comunes, ejercicios prácticos que suelen solicitar, y cómo abordar problemas típicos que se presentan durante estas evaluaciones. 4 | 5 | --- 6 | 7 | ## 1. Preguntas comunes en entrevistas de QA Manual 8 | 9 | Las entrevistas para roles de QA Manual suelen centrarse en evaluar tu conocimiento técnico, tu enfoque para resolver problemas y tu habilidad para comunicarte de manera efectiva. Aquí tienes una lista de preguntas frecuentes y consejos para responderlas: 10 | 11 | ### **Preguntas sobre conceptos básicos de QA:** 12 | 1. **¿Qué es QA y cuál es su importancia?** 13 | - **Respuesta sugerida:** 14 | QA (Quality Assurance) es el proceso de garantizar que un producto cumpla con los estándares de calidad antes de ser lanzado. Es importante porque reduce riesgos, mejora la experiencia del usuario y asegura que el producto cumpla con los requisitos. 15 | 16 | 2. **¿Cuál es la diferencia entre QA, QC y Testing?** 17 | - **QA (Aseguramiento de la calidad):** Se enfoca en prevenir defectos. 18 | - **QC (Control de calidad):** Se enfoca en identificar defectos. 19 | - **Testing:** Es el proceso práctico de encontrar defectos mediante la ejecución de pruebas. 20 | 21 | 3. **¿Qué tipos de pruebas has realizado?** 22 | - Aquí puedes mencionar pruebas funcionales, de regresión, exploratorias, de compatibilidad, entre otras. 23 | 24 | 4. **¿Realizabas pruebas funcionales y no funcionales? Si realizabas no funcionales, ¿qué herramientas utilizabas?** 25 | - **Respuesta:** 26 | - **Pruebas funcionales:** Validar que el sistema cumple con los requisitos funcionales, como la verificación de formularios o botones. 27 | - **Pruebas no funcionales:** Validar aspectos como rendimiento, seguridad y usabilidad. 28 | - Ejemplos de herramientas: 29 | - **Rendimiento:** JMeter, LoadRunner. 30 | - **Seguridad:** OWASP ZAP, Burp Suite. 31 | - **Usabilidad:** Encuestas a usuarios, pruebas A/B. 32 | 33 | ### **Preguntas sobre técnicas de diseño de pruebas:** 34 | 5. **¿Cómo diseñarías casos de prueba para un botón de inicio de sesión?** 35 | - Respuesta sugerida: Diseñaría casos para validar: 36 | - Credenciales válidas e inválidas. 37 | - Campo vacío. 38 | - Límites en el tamaño del texto. 39 | - Seguridad (intentos de fuerza bruta). 40 | - Compatibilidad en distintos navegadores. 41 | 42 | 6. **¿Qué es una prueba de caja negra y cuándo la usarías?** 43 | - **Respuesta:** Es una técnica donde no se considera la lógica interna del código. Se usa para validar funcionalidades basadas en entradas y salidas esperadas. 44 | 45 | ### **Preguntas situacionales:** 46 | 7. **¿Qué harías si encuentras un defecto crítico en la víspera del lanzamiento?** 47 | - **Respuesta:** Informaría de inmediato al equipo, explicando el impacto del defecto y propondría posibles soluciones (como un parche post-lanzamiento o un cambio en la fecha). 48 | 49 | 8. **¿Cómo manejas conflictos con desarrolladores sobre un defecto?** 50 | - **Respuesta:** Me enfocaría en los datos y la evidencia, demostrando el problema con capturas de pantalla, pasos para reproducirlo y su impacto en el sistema. 51 | 52 | --- 53 | 54 | ## 2. Preguntas sobre tu experiencia diaria como QA 55 | 56 | Estas preguntas buscan evaluar cómo gestionas tu tiempo y te relacionas con otros equipos. 57 | 58 | ### **1. ¿Cómo es tu día como QA?** 59 | - **Respuesta sugerida:** 60 | Mi día como QA empieza con la **daily**, donde el equipo discute qué se hizo, qué se hará y si hay problemas o bloqueos. 61 | Luego, dependiendo del día, puedo participar en: 62 | - **Planning:** Ayudamos a definir qué tareas o historias de usuario entrarán en el sprint, revisando criterios de aceptación y posibles riesgos. 63 | - **Ejecución de pruebas:** Diseño, ejecución y documentación de casos de prueba. 64 | - **Revisiones:** Validación de defectos corregidos o revisión de historias de usuario completadas. 65 | - **Retrospectiva:** Analizamos cómo mejorar procesos o identificar áreas de mejora en el equipo. 66 | 67 | --- 68 | 69 | ## 3. Ejercicios prácticos de diseño de casos de prueba 70 | 71 | Es común que durante la entrevista te pidan diseñar casos de prueba para una funcionalidad sencilla. Aquí tienes ejemplos prácticos: 72 | 73 | ### **Ejemplo 1: Diseñar casos de prueba para un campo de búsqueda en una página web.** 74 | 75 | | **ID** | **Caso de prueba** | **Pasos** | **Resultado esperado** | 76 | |--------|----------------------------------------------------------|-----------------------------------------------|-----------------------------------------------| 77 | | 1 | Buscar una palabra válida | 1. Ingresar "QA".
2. Presionar Enter. | Mostrar resultados relevantes con "QA". | 78 | | 2 | Buscar palabra con caracteres especiales | 1. Ingresar "$QA".
2. Presionar Enter. | Mostrar resultados relevantes o mensaje "No hay resultados". | 79 | | 3 | Buscar dejando el campo vacío | 1. Dejar el campo en blanco.
2. Presionar Enter. | Mostrar mensaje "Por favor, ingrese una palabra para buscar". | 80 | | 4 | Probar límite máximo de caracteres en el campo de búsqueda | 1. Ingresar 256 caracteres.
2. Presionar Enter. | Mostrar error o truncar texto al máximo permitido (e.g., 255 caracteres). | 81 | 82 | --- 83 | 84 | ### **Ejemplo 2: Diseñar casos de prueba para un carrito de compras.** 85 | 86 | | **ID** | **Caso de prueba** | **Pasos** | **Resultado esperado** | 87 | |--------|-----------------------------------------------------------|-----------------------------------------------|-----------------------------------------------| 88 | | 1 | Añadir un producto al carrito | 1. Seleccionar un producto.
2. Clic en "Añadir al carrito". | Producto aparece en el carrito con el precio correcto. | 89 | | 2 | Remover un producto del carrito | 1. Añadir un producto.
2. Clic en "Eliminar". | El carrito queda vacío y se muestra mensaje "Tu carrito está vacío". | 90 | | 3 | Validar cantidad máxima de un producto en el carrito | 1. Seleccionar 100 unidades del mismo producto. | Mostrar mensaje de límite si excede (e.g., "Máximo permitido: 50 unidades"). | 91 | | 4 | Probar la funcionalidad de "Pagar ahora" con carrito vacío | 1. No añadir productos.
2. Clic en "Pagar ahora". | Mostrar mensaje "No hay productos en el carrito". | 92 | 93 | --- 94 | 95 | ## Conclusión 96 | 97 | La clave para destacar en una entrevista de QA manual es demostrar tu conocimiento técnico, tu capacidad de análisis y tus habilidades de comunicación. Practica diseñar casos de prueba y resolver problemas típicos para estar preparado. ¡Recuerda que la práctica constante te dará confianza! 98 | -------------------------------------------------------------------------------- /Modulo-14-Talleres-Practicos-y-Ejercicios/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 14: Talleres Prácticos y Ejercicios 2 | 3 | Este módulo está enfocado en ejercicios prácticos que te ayudarán a aplicar los conceptos aprendidos en situaciones reales. Cubriremos cómo diseñar casos de prueba, realizar pruebas exploratorias y reportar defectos, además de crear un plan de pruebas. 4 | 5 | --- 6 | 7 | ## 1. Diseñar casos de prueba para una aplicación web sencilla 8 | 9 | Vamos a diseñar casos de prueba para una funcionalidad básica: un formulario de registro de usuario. Imagina que el formulario tiene los siguientes campos: 10 | - Nombre de usuario (alfanumérico, obligatorio). 11 | - Correo electrónico (obligatorio, con validación de formato). 12 | - Contraseña (mínimo 8 caracteres, obligatorio). 13 | - Botón de registro. 14 | 15 | ### **Casos de prueba sugeridos:** 16 | 17 | | **ID** | **Caso de prueba** | **Pasos** | **Resultado esperado** | 18 | |--------|----------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------| 19 | | 1 | Registrar usuario con datos válidos | 1. Completar todos los campos con datos válidos.
2. Clic en "Registrar". | Registro exitoso. Mostrar mensaje "Registro completado" y redirigir al usuario a la página principal. | 20 | | 2 | Registrar usuario con un correo inválido | 1. Ingresar un correo sin `@` o dominio (e.g., "correo.com").
2. Clic en "Registrar". | Mostrar mensaje de error: "Por favor, ingrese un correo válido". | 21 | | 3 | Dejar el campo de contraseña vacío | 1. Completar todos los campos excepto "Contraseña".
2. Clic en "Registrar". | Mostrar mensaje de error: "La contraseña es obligatoria". | 22 | | 4 | Ingresar una contraseña con menos de 8 caracteres | 1. Ingresar "12345" como contraseña.
2. Clic en "Registrar". | Mostrar mensaje de error: "La contraseña debe tener al menos 8 caracteres". | 23 | | 5 | Probar con un nombre de usuario que contenga caracteres especiales | 1. Ingresar "Usuario@123".
2. Completar el resto de los campos.
3. Clic en "Registrar". | Mostrar mensaje de error: "El nombre de usuario solo puede contener caracteres alfanuméricos". | 24 | 25 | --- 26 | 27 | ## 2. Pruebas exploratorias en una aplicación móvil 28 | 29 | ### **¿Qué son las pruebas exploratorias?** 30 | Son un enfoque dinámico donde el QA explora la aplicación en busca de defectos sin seguir un conjunto estricto de casos de prueba. Este tipo de pruebas es ideal para descubrir problemas inesperados o validar funcionalidades no documentadas. 31 | 32 | ### **Ejercicio práctico: Exploración de una aplicación de notas** 33 | Supongamos que tienes una aplicación de notas con las siguientes funcionalidades: 34 | - Crear una nueva nota. 35 | - Editar una nota existente. 36 | - Eliminar una nota. 37 | - Buscar notas por título. 38 | 39 | ### **Pasos sugeridos para realizar pruebas exploratorias:** 40 | 1. **Navegación básica:** 41 | - Abrir la aplicación y explorar las opciones disponibles en el menú principal. 42 | - Verificar que la interfaz sea intuitiva y que no haya errores de diseño. 43 | 2. **Crear notas:** 44 | - Crear una nota con un título y contenido. 45 | - Probar límites en el tamaño del título (e.g., ingresar más de 100 caracteres). 46 | - Crear una nota sin contenido y verificar el comportamiento. 47 | 3. **Editar y eliminar notas:** 48 | - Modificar el contenido de una nota existente y guardar los cambios. 49 | - Intentar eliminar una nota y confirmar que desaparezca de la lista. 50 | - Verificar si hay opción para recuperar notas eliminadas. 51 | 4. **Buscar notas:** 52 | - Buscar notas con palabras clave exactas y parcialmente coincidentes. 53 | - Probar búsquedas con mayúsculas/minúsculas o caracteres especiales. 54 | 55 | ### **Reporte de resultados exploratorios:** 56 | Registra tus hallazgos de manera clara. Por ejemplo: 57 | - **Problema:** Al intentar buscar notas con caracteres especiales (&, %, $), la aplicación se cierra inesperadamente. 58 | - **Pasos para reproducir:** Abrir la función de búsqueda, ingresar "¬a", presionar "Buscar". 59 | - **Impacto:** La funcionalidad de búsqueda es inusable si el usuario emplea ciertos caracteres. 60 | 61 | --- 62 | 63 | ## 3. Ejercicios de identificación y reporte de defectos en un proyecto de ejemplo 64 | 65 | ### **Ejercicio práctico: Reportar un defecto en un sistema de gestión de tareas** 66 | Imagina que estás probando un sistema de gestión de tareas. Descubres el siguiente problema: **el sistema permite crear tareas duplicadas con el mismo nombre y fecha límite**. 67 | 68 | #### **Pasos para reportar el defecto:** 69 | 1. **Título:** Permite la creación de tareas duplicadas. 70 | 2. **Descripción:** 71 | - El sistema permite al usuario agregar múltiples tareas con el mismo nombre y fecha límite sin ningún mensaje de error. 72 | 3. **Pasos para reproducir:** 73 | 1. Abrir el sistema de gestión de tareas. 74 | 2. Crear una tarea con el nombre "Proyecto A" y fecha límite "2024-11-21". 75 | 3. Crear otra tarea con el mismo nombre y fecha límite. 76 | 4. Observar que ambas tareas son aceptadas. 77 | 4. **Resultado esperado:** Mostrar un mensaje de error como "La tarea ya existe" o permitir duplicados solo si tienen diferentes fechas límite. 78 | 5. **Impacto:** Alta. Puede causar confusión y errores al gestionar tareas. 79 | 80 | --- 81 | 82 | ## 4. Creación de un plan de pruebas para un proyecto real 83 | 84 | ### **¿Qué es un plan de pruebas?** 85 | Un plan de pruebas es un documento que describe el enfoque, el alcance y las actividades necesarias para realizar pruebas en un proyecto. 86 | 87 | ### **Ejercicio práctico: Plan de pruebas para una tienda en línea** 88 | #### **Secciones clave del plan:** 89 | 1. **Objetivo:** 90 | - Garantizar que las funcionalidades principales de la tienda en línea (registro, búsqueda de productos, carrito de compras, pagos) funcionen correctamente. 91 | 2. **Alcance:** 92 | - Funcionalidades incluidas: Registro, inicio de sesión, búsqueda de productos, pago. 93 | - Funcionalidades excluidas: Integración con redes sociales. 94 | 3. **Criterios de aceptación:** 95 | - Todos los casos de prueba funcionales deben pasar. 96 | - No se permiten defectos críticos ni mayores en el lanzamiento. 97 | 4. **Recursos:** 98 | - Herramientas: TestRail para gestión de pruebas, Jira para reporte de defectos. 99 | - Equipo: 2 QA manuales y 1 líder de QA. 100 | 5. **Cronograma:** 101 | - Fase de pruebas: 2 semanas. 102 | 6. **Riesgos:** 103 | - Riesgo de no tener suficiente tiempo para pruebas exploratorias si los casos funcionales toman más de lo esperado. 104 | 105 | --- 106 | 107 | ## Conclusión 108 | 109 | Los talleres prácticos son esenciales para consolidar los conocimientos de QA. Al realizar estos ejercicios, te familiarizarás con los desafíos reales de esta profesión y estarás mejor preparado para resolverlos en un entorno laboral. 110 | 111 | -------------------------------------------------------------------------------- /Modulo-15-Certificaciones-y-Crecimiento-Profesional-en-QA/README.md: -------------------------------------------------------------------------------- 1 | # Módulo 15: Certificaciones y Crecimiento Profesional en QA 2 | 3 | En este módulo aprenderás sobre certificaciones relevantes para QA Manual, cómo avanzar hacia la automatización y las oportunidades de carrera en el área de QA. 4 | 5 | --- 6 | 7 | ## 1. Certificaciones relevantes para QA Manual 8 | 9 | ### **¿Por qué obtener una certificación?** 10 | Una certificación valida tus conocimientos y habilidades en QA. Es un diferenciador en el mercado laboral y demuestra tu compromiso con el aprendizaje continuo. 11 | 12 | ### **Certificaciones principales:** 13 | 14 | #### **ISTQB (International Software Testing Qualifications Board)** 15 | - **Niveles:** 16 | - *Foundation Level:* Ideal para principiantes. Cubre los fundamentos del testing. 17 | - *Advanced Level:* Para testers con experiencia que buscan profundizar en áreas como gestión de pruebas. 18 | - *Expert Level:* Orientado a líderes en testing. 19 | - **Temas clave:** 20 | - Conceptos básicos de testing. 21 | - Diseño de casos de prueba. 22 | - Gestión de defectos y herramientas. 23 | - **Ventajas:** Reconocida globalmente; te prepara para roles de mayor responsabilidad. 24 | 25 | #### **CSTE (Certified Software Tester)** 26 | - **Requisitos:** Experiencia previa en testing (generalmente 2 años). 27 | - **Áreas de enfoque:** 28 | - Procesos de pruebas de software. 29 | - Mejores prácticas en QA. 30 | - Técnicas de diseño de pruebas. 31 | 32 | #### **Certified Agile Tester (CAT)** 33 | - **Enfoque:** Testing en entornos ágiles. 34 | - **Ventajas:** Muy útil si trabajas con Scrum, Kanban u otros marcos ágiles. 35 | 36 | #### **Otras certificaciones útiles:** 37 | - **CP-MAT (Certified Professional for Model-Based Testing):** Ideal para testers interesados en modelos de diseño. 38 | - **Certificaciones en herramientas específicas:** Ejemplo: Selenium, JIRA, o herramientas de automatización como Cypress. 39 | 40 | ### **Consejos para prepararte:** 41 | 1. Estudia los temarios oficiales de las certificaciones. 42 | 2. Practica con simuladores de examen. 43 | 3. Apóyate en comunidades y foros de testers. 44 | 45 | --- 46 | 47 | ## 2. Cómo avanzar de QA Manual a Automatizado 48 | 49 | ### **¿Por qué dar el salto a la automatización?** 50 | - Mayor demanda en el mercado laboral. 51 | - Permite realizar pruebas más rápidas y repetibles. 52 | - Incrementa la eficiencia del equipo de QA. 53 | 54 | ### **Pasos para iniciar en la automatización:** 55 | 1. **Aprende un lenguaje de programación:** 56 | - *Recomendados:* Java, Python, JavaScript. 57 | - Estos lenguajes son ampliamente utilizados en herramientas de automatización. 58 | 2. **Familiarízate con herramientas populares:** 59 | - Selenium: Automación para aplicaciones web. 60 | - Appium: Pruebas para aplicaciones móviles. 61 | - Cypress: Pruebas para interfaces modernas y rápidas. 62 | 3. **Comprende conceptos básicos:** 63 | - Localizadores de elementos (XPath, CSS). 64 | - Frameworks de testing (JUnit, TestNG). 65 | - Ejecución en paralelo y en CI/CD. 66 | 4. **Crea proyectos simples:** 67 | - Automatiza formularios o validaciones básicas. 68 | - Integra tus pruebas en pipelines de CI/CD usando Jenkins o GitHub Actions. 69 | 70 | --- 71 | 72 | ## 3. Oportunidades de carrera en el área de QA 73 | 74 | ### **Carreras relacionadas con QA:** 75 | 1. **QA Analyst (Manual):** 76 | - Enfocado en la creación y ejecución de casos de prueba. 77 | - Identificación y reporte de defectos. 78 | 2. **QA Automatizado:** 79 | - Desarrollo de scripts para automatizar pruebas. 80 | - Integración con pipelines de DevOps. 81 | 3. **QA Lead:** 82 | - Supervisión de equipos de QA. 83 | - Gestión de recursos y planificación de pruebas. 84 | 4. **QA Engineer:** 85 | - Desarrollo de frameworks de testing. 86 | - Testing de rendimiento, seguridad y más. 87 | 5. **Consultor QA:** 88 | - Ayuda a las empresas a definir estrategias de QA. 89 | - Auditorías de calidad en proyectos. 90 | 6. **Especialista en pruebas de rendimiento:** 91 | - Uso de herramientas como JMeter o Gatling para medir el rendimiento de aplicaciones. 92 | 93 | ### **Consejos para avanzar en tu carrera:** 94 | - **Construye una red profesional:** Participa en comunidades de QA (por ejemplo, foros, meetups, LinkedIn). 95 | - **Mantente actualizado:** Aprende nuevas herramientas y tendencias. 96 | - **Desarrolla habilidades blandas:** Comunicación, liderazgo y resolución de problemas son esenciales para roles senior. 97 | -------------------------------------------------------------------------------- /Modulo-16-Conclusion-del-Curso/README.md: -------------------------------------------------------------------------------- 1 | # Conclusión del Curso 2 | 3 | En esta última sección, resumimos los puntos clave del curso, compartimos consejos finales para destacar como QA Manual y proporcionamos recursos adicionales para seguir aprendiendo y creciendo en tu carrera. 4 | 5 | --- 6 | 7 | ## 1. Resumen de los temas clave cubiertos 8 | 9 | A lo largo de este curso, aprendiste: 10 | 11 | 1. **Fundamentos del QA Manual:** Qué es el testing, tipos de pruebas y su importancia en el ciclo de vida del desarrollo de software. 12 | 2. **Documentación y gestión de pruebas:** Cómo diseñar y escribir casos de prueba, reportar defectos y trabajar con herramientas como TestRail, JIRA y Confluence. 13 | 3. **Técnicas de pruebas:** Exploraste pruebas funcionales, no funcionales, exploratorias y más, con ejemplos prácticos. 14 | 4. **Metodologías ágiles:** Comprendiste el rol del QA en Scrum y Kanban, y cómo participar en las ceremonias ágiles. 15 | 5. **Preparación profesional:** Desde certificaciones relevantes hasta cómo afrontar entrevistas de trabajo y avanzar hacia la automatización. 16 | 17 | --- 18 | 19 | ## 2. Consejos finales para ser un QA Manual eficiente 20 | 21 | 1. **Desarrolla una mentalidad crítica:** 22 | - Siempre cuestiona cómo podría fallar el sistema y busca posibles áreas de mejora. 23 | - Piensa desde la perspectiva del usuario final. 24 | 25 | 2. **Comunicación efectiva:** 26 | - Reporta defectos de manera clara y objetiva. 27 | - Colabora estrechamente con desarrolladores, Product Owners y otros stakeholders para garantizar que los requisitos se entiendan y cumplan. 28 | 29 | 3. **Organización y priorización:** 30 | - Planifica tus pruebas en función de los objetivos del sprint o proyecto. 31 | - Prioriza casos de prueba basándote en los riesgos y el impacto en el usuario final. 32 | 33 | 4. **Compromiso con el aprendizaje continuo:** 34 | - QA es un campo dinámico. Mantente actualizado con nuevas herramientas, tendencias y enfoques. 35 | 36 | 5. **Sé proactivo:** 37 | - Participa en todas las reuniones relevantes, como dailies, plannings, revisiones y retrospectivas. Esto asegura que estés alineado con el equipo. 38 | 39 | --- 40 | 41 | ## 3. Recursos adicionales para seguir aprendiendo 42 | 43 | ### **Libros recomendados:** 44 | - *"Foundations of Software Testing"* de Dorothy Graham. 45 | - *"Lessons Learned in Software Testing"* de Cem Kaner. 46 | - *"Agile Testing"* de Lisa Crispin y Janet Gregory. 47 | 48 | ### **Cursos online:** 49 | - **Udemy:** Certificación ISTQB, fundamentos de pruebas de software. 50 | - **Test Automation University:** Introducción a herramientas de automatización. 51 | - **Pluralsight:** Testing en entornos ágiles. 52 | 53 | ### **Comunidades y foros:** 54 | - [Ministry of Testing](https://www.ministryoftesting.com): Comunidad global de testers. 55 | - **Grupos de LinkedIn:** Busca comunidades locales o específicas de QA. 56 | - **Redes sociales:** Sigue cuentas relacionadas con QA en Instagram, Twitter y Discord. 57 | 58 | --- 59 | 60 | ## **¿Quieres más recursos prácticos?** 61 | 62 | Si deseas practicar lo aprendido, ¡puedes escribirme! 63 | 64 | 1. Envíame un correo a **devch.tech@gmail.com** o un DM en Instagram a [@__devch](https://instagram.com/__devch). 65 | 2. Te enviaré: 66 | - Un PDF con 4 historias de usuario listas para resolver. 67 | - Una plantilla en Excel para crear casos de prueba. 68 | 69 | Estos recursos son ideales para reforzar tu aprendizaje y construir tu portafolio profesional. 70 | 71 | --- 72 | 73 | Gracias por confiar en este curso. Espero que te haya ayudado a dar un paso importante en tu carrera como QA Manual. ¡Mucho éxito en todo lo que emprendas! Y recuerda: el aprendizaje nunca termina. 😊 74 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 🎓 **Curso Completo de QA Manual** 🎓 2 | 3 | ¡Bienvenido al **Curso de QA Manual**! 🚀 Aquí aprenderás todo lo que necesitas saber para convertirte en un experto en asegurar la calidad del software, desde los fundamentos básicos hasta técnicas avanzadas y herramientas profesionales. 📋✨ 4 | 5 | Este curso está diseñado para guiarte paso a paso a través de cada aspecto del testing manual, asegurando que comprendas tanto los conceptos teóricos como su aplicación práctica. 6 | 7 | --- 8 | 9 | ## 📚 **Contenido del Curso** 10 | 11 | 1. 🏁 [**Introducción al QA Manual**](./Modulo-01-Introduccion-al-QA-Manual/README.md) 12 | - ¿Qué es el QA (Quality Assurance)? 13 | - Diferencia entre QA, Testing y Control de Calidad (QC) 14 | - Importancia del QA en el ciclo de desarrollo de software 15 | 16 | 2. 🔍 [**Fundamentos de QA**](./Modulo-02-Fundamentos-de-QA/README.md) 17 | - Conceptos clave: defectos, errores, bugs, fallos 18 | - Tipos de pruebas: funcionales, no funcionales, regresión, smoke, sanity, exploratorias 19 | - Principios básicos del testing de software 20 | 21 | 3. 🏗️ [**Ciclo de Vida del Desarrollo de Software (SDLC)**](./Modulo-03-Ciclo-de-Vida-del-Desarrollo-de-Software-SDLC/README.md) 22 | - Modelos de desarrollo de software: Waterfall, Agile, DevOps 23 | - Cómo el QA se integra en cada modelo 24 | - Roles y responsabilidades del QA Manual en cada fase del SDLC 25 | 26 | 4. 🔄 [**Ciclo de Vida del Testing (STLC)**](./Modulo-04-Ciclo-de-Vida-del-Testing-STLC/README.md) 27 | - Fases del STLC: planificación, diseño de casos de prueba, ejecución, reporte y cierre 28 | - Entrada y salida (entry & exit criteria) para cada fase del STLC 29 | - Cómo definir la estrategia de pruebas 30 | 31 | 5. ✍️ [**Diseño de Casos de Prueba**](./Modulo-05-Diseño-de-Casos-de-Prueba/README.md) 32 | - ¿Qué es un caso de prueba? Estructura y elementos 33 | - Técnicas de diseño de pruebas: caja negra, caja blanca, etc. 34 | 35 | 6. 🧪 [**Tipos de Pruebas Manuales**](./Modulo-06-Tipos-de-Pruebas-Manuales/README.md) 36 | - Pruebas funcionales, de regresión, exploratorias, de compatibilidad, de seguridad, etc. 37 | 38 | 7. 🐞 [**Gestión de Defectos**](./Modulo-07-Gestion-de-Defectos/README.md) 39 | - ¿Qué es un defecto/bug? 40 | - Ciclo de vida de un defecto y herramientas para su gestión 41 | 42 | 8. 🔧 [**Herramientas de QA Manual**](./Modulo-08-Herramientas-de-QA-Manual/README.md) 43 | - Introducción a herramientas de gestión de pruebas, gestión de proyectos, y más 44 | 45 | 9. 📄 [**Documentación de Pruebas**](./Modulo-09-Documentacion-de-Pruebas/README.md) 46 | - Plan de pruebas, estrategia, casos de prueba y reportes de ejecución 47 | 48 | 10. 🤖 [**Automatización de Pruebas: Introducción para QA Manual**](./Modulo-10-Automatizacion-de-Pruebas-Introduccion-para-QA-Manual/README.md) 49 | - ¿Cuándo automatizar y cuándo no? 50 | - Diferencias entre QA Manual y Automatizado 51 | 52 | 11. 📦 [**Pruebas en Entornos Ágiles**](./Modulo-11-Pruebas-en-Entornos-Agiles/README.md) 53 | - Cómo se integra el QA en metodologías ágiles como Scrum y Kanban 54 | 55 | 12. ✅ [**Buenas Prácticas en QA Manual**](./Modulo-12-Buenas-Practicas-en-QA-Manual/README.md) 56 | - Estrategias para planificar y priorizar casos de prueba, comunicación con equipos 57 | 58 | 13. 🎤 [**Preparación para Entrevistas de QA Manual**](./Modulo-13-Preparacion-para-Entrevistas-de-QA-Manual/README.md) 59 | - Preguntas comunes, ejercicios prácticos, y consejos para entrevistas 60 | 61 | 14. 🧑‍🏫 [**Talleres Prácticos y Ejercicios**](./Modulo-14-Talleres-Practicos-y-Ejercicios/README.md) 62 | - Ejercicios de diseño de casos de prueba, exploratorios, reportes de defectos, etc. 63 | 64 | 15. 🎓 [**Certificaciones y Crecimiento Profesional en QA**](./Modulo-15-Certificaciones-y-Crecimiento-Profesional-en-QA/README.md) 65 | - Certificaciones relevantes, cómo avanzar de QA Manual a Automatizado 66 | 67 | 16. 🏁 [**Conclusión del Curso**](./Modulo-16-Conclusion-del-Curso/README.md) 68 | - Resumen de los temas clave y recursos adicionales 69 | 70 | --- 71 | 72 | ## 📘 **Recursos Adicionales** 73 | 74 | ### 1. Herramientas útiles para QA 75 | - **[Selenium](https://www.selenium.dev/)**: Herramienta de automatización de pruebas para aplicaciones web. 76 | - **[JIRA](https://www.atlassian.com/software/jira)**: Herramienta de gestión de proyectos que permite el seguimiento de bugs y tareas. 77 | - **[Postman](https://www.postman.com/)**: Herramienta para probar APIs. 78 | - **[TestRail](https://www.gurock.com/testrail/)**: Herramienta para la gestión de pruebas. 79 | - **[TestLink](http://testlink.sourceforge.net/)**: Herramienta de gestión de pruebas de código abierto que permite crear y gestionar casos de prueba. 80 | - **[Mantis](https://www.mantisbt.org/)**: Sistema de seguimiento de bugs y gestión de proyectos. 81 | - **[Confluence](https://www.atlassian.com/software/confluence)**: Herramienta de colaboración que permite documentar y compartir información del proyecto. 82 | 83 | ### 2. Libros recomendados 84 | - **[Lessons Learned in Software Testing](https://www.amazon.com/Lessons-Learned-Software-Testing-Complete/dp/0471081128)** de Cem Kaner, James Bach y Bret Pettichord. 85 | - **[Agile Testing: A Practical Guide for Testers and Agile Teams](https://www.amazon.com/Agile-Testing-Practical-Testers-Teams/dp/0321683687)** de Lisa Crispin y Janet Gregory. 86 | - **[The Art of Software Testing](https://www.amazon.com/Art-Software-Testing-Third-Edition/dp/1119472008)** de Glenford Myers. 87 | 88 | ### 3. Enlaces a comunidades y sitios de interés 89 | - **[Ministry of Testing](https://www.ministryoftesting.com/)**: Comunidad de testers con recursos, foros y eventos. 90 | - **[Reddit - Software Testing](https://www.reddit.com/r/softwaretesting/)**: Comunidad en Reddit dedicada a discutir temas de testing y QA. 91 | - **[Software Testing Help](https://www.softwaretestinghelp.com/)**: Sitio web que ofrece tutoriales, guías y artículos sobre testing de software. 92 | 93 | ¡Espero que disfrutes del curso y te conviertas en un excelente QA Manual! 🏆💻 94 | --------------------------------------------------------------------------------