pruebas de software

pruebas de software

1. Principios de pruebas

   • 1. Las pruebas demuestran la presencia de defectos, no su ausencia: Las pruebas pueden mostrar que hay defectos en un software, pero no pueden garantizar que esté completamente libre de errores. El objetivo es reducir el riesgo de fallos, no eliminarlos por completo
     • 2. La prueba exhaustiva es imposible: Probar todas las combinaciones posibles de entradas, condiciones y rutas es inviable, excepto en sistemas muy simples. Por eso, se priorizan las pruebas basándose en el análisis de riesgos y en la criticidad de las funcionalidades.
       • 3. Las pruebas tempranas ahorran tiempo y dinero: Detectar errores en las primeras etapas del ciclo de vida del desarrollo es más económico que corregirlos más tarde.
         • 4. La agrupación de defectos: Los defectos tienden a agruparse en ciertas áreas o módulos del software. Identificar estas áreas problemáticas permite enfocar los esfuerzos de prueba de manera más efectiva.
           • 5. La paradoja del pesticida: Si se repiten las mismas pruebas una y otra vez, eventualmente dejarán de encontrar nuevos defectos. Es necesario revisar y actualizar regularmente los casos de prueba para cubrir nuevas áreas y encontrar más problemas.
             • 6. Las pruebas dependen del contexto: Los enfoques y métodos de prueba varían dependiendo del tipo de software. Por ejemplo, las pruebas para una aplicación móvil son diferentes a las pruebas de un sistema bancario crítico o de un videojuego.
               • 7.La falacia de la ausencia de errores: La ausencia de defectos detectados en las pruebas no implica que el software sea perfecto. Es importante reconocer que siempre existe la posibilidad de errores residuales y que la calidad del software se mide por la gestión efectiva de los defectos

2. Framework de automatizacion

   • Un framework de automatización es una estructura estandarizada que proporciona herramientas, buenas prácticas y guías para crear, ejecutar y mantener pruebas automatizadas de manera eficiente.
     • Ejemplos de Frameworks: Selenium WebDriver: Puede integrarse con frameworks como TestNG, JUnit, Cucumber o Robot Framework. Appium: Para pruebas de aplicaciones móviles. Cypress: Ideal para aplicaciones web modernas.

3. Selenium

   • Selenium es una herramienta que se usa para automatizar pruebas de aplicaciones web. En lugar de probar manualmente si un sitio funciona correctamente en diferentes navegadores o escenarios, con Selenium puedes escribir scripts que realicen estas pruebas automáticamente.
     • ¿Cómo funciona? Automatiza navegadores: Ejecuta las pruebas como si fueras un usuario real interactuando con la página, Soporte multiplataforma y navegador: Funciona en Chrome, Firefox, Edge, Puedes usar varios lenguajes para escribir los scripts, como Java, Python, C#, JavaScript, entre otros.
       • Componentes de selenium
         • Selenium WebDriver, . Selenium IDE
           • Cómo interactúan los componentes: WebDriver es la base para la ejecución de pruebas en navegadores. Grid se utiliza para ejecutar estas pruebas en paralelo y en diferentes entornos. IDE puede ser usado para crear pruebas rápidamente y luego exportarlas para ser usadas con WebDriver en proyectos más avanzados.

4. Bug

   • New, asignado, en proceso, resuelto, verificado y cerrado. otros como reabierto, rechazado

5. Falla, Defecto Y error

   • Error: Es una equivocación o malentendido cometido por un ser humano, como un desarrollador o analista, al interpretar o implementar un requisito. Por ejemplo, un programador puede escribir un cálculo incorrecto debido a que entendió mal la fórmula que debía usar.
   • Defecto (o bug): Es el resultado de un error. Representa una discrepancia en el software, entre lo que hace y lo que debería hacer según los requisitos. Por ejemplo, debido al error en el cálculo, la funcionalidad que calcula un descuento muestra un monto equivocado.
   • Falla (o fallo): Es el comportamiento incorrecto del sistema cuando se ejecuta, causado por un defecto. Es algo que se puede observar, ya sea por el tester o el usuario final. Por ejemplo, al probar la funcionalidad, el sistema calcula un precio erróneo, lo que impacta al cliente que intenta realizar una compra.
   • En resumen, el error humano conduce a un defecto en el software, y cuando este defecto se activa, se manifiesta como una falla observable

6. Metodologia Scrum

   • La metodología Scrum organiza el trabajo en ciclos iterativos llamados sprints, permitiendo una entrega incremental y constante de valor al cliente
     • Inicio y planificación del sprint (Sprint Planning) Objetivo: Planificar qué trabajo se realizará en el sprint y cómo se completará.
       • Ejecución del sprint (Sprint Execution) Objetivo: Completar las tareas planificadas del Sprint Backlog. Actividades: El equipo de desarrollo trabaja en los elementos seleccionados. Las tareas se desglosan en unidades más pequeñas para facilitar su progreso. La colaboración y la autoorganización son clave.
         • Scrum diario (Daily Scrum) Objetivo: Coordinar y sincronizar al equipo diariamente. Duración: 15 minutos. Actividades: Cada miembro responde a tres preguntas clave: ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué impedimentos tengo?
           • Revisión del sprint (Sprint Review) Objetivo: Presentar el trabajo completado y recopilar retroalimentación. Actividades: El equipo muestra el incremento del producto terminado al Product Owner y a otros interesados. Se discuten ajustes, necesidades adicionales o prioridades futuras.
             • Retrospectiva del sprint (Sprint Retrospective) Objetivo: Identificar qué funcionó bien, qué no funcionó y cómo mejorar. Actividades: Reflexión del equipo sobre el sprint. Identificación de prácticas efectivas y áreas de mejora. Implementación de acciones para mejorar en futuros sprints.

7. Estimacion de tiempos

   • entender los requisitos Revisa las historias de usuario, casos de uso o requisitos funcionales y no funcionales. Comprende claramente qué se espera validar: flujo de negocio, funcionalidad, integración, rendimiento,
     • Dividir las actividades Divide el trabajo en tareas específicas relacionadas con el ciclo de pruebas. Por ejemplo: Análisis de requisitos: Revisar y entender los casos de prueba necesarios. Diseño de casos de prueba: Escribir y preparar los casos de prueba basados en los requisitos. Configuración del entorno de pruebas: Asegurar que el entorno esté listo y configurado. Ejecución de pruebas: Realizar pruebas funcionales, de regresión, de integración, etc. Registro y gestión de defectos: Reportar y verificar los errores encontrados. Automatización de pruebas (si aplica): Crear y ejecutar scripts automatizados. Pruebas de regresión: Validar que los defectos corregidos no afecten otras áreas. Documentación: Registrar resultados, métricas y reportes.
       • Seleccionar una técnica de estimación Por analogía: Basarse en tareas similares realizadas en proyectos anteriores. Por ejemplo: "Diseñar 10 casos de prueba funcionales tomó 5 horas en un proyecto previo similar." Por descomposición: Desglosa cada tarea en unidades más pequeñas y estima cada una individualmente. Suma los tiempos estimados para obtener un total. Técnicas ágiles: Asignar puntos de historia o niveles de esfuerzo relativo a cada tarea. Delphi o consenso grupal: Estimaciones en colaboración con otros QAs o miembros del equipo.
         • Considerar factores adicionales Complejidad de la funcionalidad: Flujos simples tomarán menos tiempo que los complejos con múltiples validaciones. Tamaño del equipo: Si el trabajo será compartido entre varios QAs, ajusta las estimaciones. Ambigüedad de los requisitos: Si los requisitos son poco claros, agrega un margen adicional para cubrir posibles ajustes. Entorno de pruebas: Asegúrate de contar con tiempo para resolver problemas técnicos en el entorno, como configuraciones o accesos. Pruebas manuales vs. automatización: Las pruebas automatizadas pueden requerir más tiempo inicialmente para crear los scripts, pero menos para la ejecución.

8. Pruebas estaticas

   • Las pruebas estáticas son un tipo de prueba de software que se realiza sin ejecutar el código. Su objetivo es detectar defectos en las primeras etapas del ciclo de vida del desarrollo, revisando documentos, código fuente y artefactos relacionados
     • Examinan los documentos del proyecto (requisitos, especificaciones, diseños) para identificar errores, omisiones o inconsistencias. Tipos de revisiones: Revisión informal: Sin procedimientos definidos, como revisiones entre compañeros. Revisión técnica: Evaluación formal de documentos o código por expertos técnicos. Inspección: Proceso sistemático y formal con roles definidos para identificar defectos.

9. Pruebas Funcionales

   • se enfocan en qué debe hacer el sistema, no en cómo lo hace (sin preocuparse por la lógica interna o la estructura del código). Se basan en las especificaciones funcionales o requerimientos del software. Se ejecutan desde la perspectiva del usuario final.
     • Tipos de pruebas funcionales: Pruebas de unidad: Verifican la funcionalidad de componentes individuales o unidades del sistema (generalmente realizadas por desarrolladores). Pruebas de integración: Validan la interacción entre diferentes módulos o sistemas para garantizar que trabajen correctamente juntos. Pruebas del sistema: Evalúan el sistema completo como un todo para garantizar que cumple con los requisitos funcionales. Pruebas de aceptación: Validan que el sistema cumpla con los criterios de aceptación definidos por el cliente o los usuarios.
       • Técnicas utilizadas en las pruebas funcionales: Pruebas basadas en casos de uso: Se crean casos de prueba que cubran escenarios reales de uso de la aplicación. Pruebas de entrada y salida: Verifican que para cada entrada válida o inválida, el sistema produce la salida esperada. Pruebas de interfaz: Validan que las interfaces de usuario y las API funcionen como se espera. Pruebas de regresión: Se aseguran de que las funcionalidades existentes no se vean afectadas por cambios o actualizaciones.
         • Pasos para realizar pruebas funcionales: Identificar requisitos funcionales: Revisar documentos como especificaciones, historias de usuario y casos de uso. Diseñar casos de prueba: Crear casos que cubran todas las funcionalidades, considerando entradas válidas e inválidas. Configurar el entorno de pruebas: Asegurar que el entorno sea representativo del sistema real (servidores, bases de datos, etc.). Ejecutar las pruebas: Realizar las pruebas manualmente o mediante herramientas de automatización, como Selenium, UFT, etc. Comparar resultados: Verificar que los resultados reales coincidan con los resultados esperados. Registrar defectos: Reportar cualquier discrepancia encontrada durante las pruebas.