1. Métodos estáticos (verificación)
1.1. Walkthrough
1.1.1. **Propósito** Se trata de una reunión en la que el autor del documento o código explica su trabajo a un grupo de revisores.
1.1.2. **Aplicación en el CVDS** Utilizado en etapas tempranas, especialmente en análisis y diseño.
1.1.3. **Recomendaciones** ***** Realizar recorridos en cada fase clave del CVDS, como revisión de requisitos, diseño y código. ***** Asegurarse de incluir al menos a un experto externo para obtener una perspectiva imparcial.
1.1.4. **Fortalezas** Fomenta la colaboración y la comprensión compartida entre desarrolladores y otros roles técnicos.
1.1.5. **Debilidades** ***** Depende de la experiencia y atención del equipo. ***** La falta de formalidad puede hacer que ciertos problemas pasen desapercibidos.
1.2. Code Inspections
1.2.1. **Propósito** Realizar una revisión estructurada y formal del código fuente para identificar defectos, siguiendo un proceso documentado
1.2.2. **Aplicación en el CVDS** Es útil en la fase de codificación
1.2.3. **Recomendaciones** ***** Hacer revisiones periódicas en cada módulo de desarrollo. ***** Utilizar herramientas de apoyo, como checklists, para mejorar la cobertura de la inspección.
1.2.4. **Fortalezas** ***** Eficaz para identificar errores críticos de diseño y lógica. ***** Mejora la calidad del código y facilita el mantenimiento.
1.2.5. **Debilidades** ***** Consume tiempo y puede ser costoso si no se realiza eficientemente. ***** Requiere que los participantes tengan habilidades técnicas avanzadas.
1.3. Reviews
1.3.1. **Propósito** Evaluar formalmente documentos del proyecto para asegurar que cumplen con los estándares.
1.3.2. **Aplicación en el CVDS** Aplicadas en análisis y diseño
1.3.3. **Recomendaciones** ***** Documentar adecuadamente cualquier hallazgo. ***** Asignar roles específicos (moderador, autor, revisor) para asegurar que cada participante se enfoque en su tarea.
1.3.4. **Fortalezas** ***** Identificación temprana de problemas en los requisitos y diseño. ***** Evita la propagación de errores en etapas posteriores.
1.3.5. **Debilidades** ***** No detecta errores de implementación. ***** Requiere coordinación y tiempo, especialmente en equipos grandes.
1.4. Formal Proofs
1.4.1. **Propósito** Validar la lógica del software mediante demostraciones para asegurar su funcionamiento.
1.4.2. **Aplicación en el CVDS** Utilizada en la etapa de codificación.
1.4.3. **Recomendaciones** Utilizar en proyectos donde la alta precisión es fundamental y contar con personal especializado en matemáticas.
1.4.4. **Fortalezas** ***** Ofrece una alta garantía de corrección. ***** Es la técnica más rigurosa para verificar sistemas críticos.
1.4.5. **Debilidades** ***** Muy costosa y compleja de implementar. ***** Requiere experiencia en métodos matemáticos y puede no ser viable para proyectos comerciales estándar.
1.5. ... Adicionales
1.5.1. Model Checking
1.5.1.1. **Propósito** Verificar formalmente que el modelo de un sistema cumple con ciertas especificaciones o propiedades lógicas
1.5.1.2. **Aplicación en el CVDS** Utilizado en etapas tempranas, especialmente en diseño.
1.5.1.3. **Recomendaciones** Usar herramientas de verificación de modelos, como SPIN, UPPAAL o NuSMV, que permiten analizar modelos complejos.
1.5.1.4. **Fortalezas** Proporciona una garantía formal de que el modelo cumple con especificaciones clave.
1.5.1.5. **Debilidades** Complejo y requiere conocimientos avanzados en lógica formal y herramientas de modelado.
1.5.2. Property-Based Testing
1.5.2.1. **Propósito** Verificar que el código cumple con ciertas propiedades definidas, generando entradas aleatorias para probar el sistema exhaustivamente.
1.5.2.2. **Aplicación en el CVDS** Aplicadas en fase de pruebas
1.5.2.3. **Recomendaciones** Definir propiedades que representen las condiciones más críticas y comunes de los componentes a probar.
1.5.2.4. **Fortalezas** Permite descubrir casos de borde y fallos no anticipados al generar automáticamente muchos casos de prueba.
1.5.2.5. **Debilidades** Puede ser menos útil para interfaces de usuario o sistemas basados en interacciones.
1.5.3. Linting
1.5.3.1. **Propósito** Verificar el estilo y la coherencia del código, asegurándose de que sigue las convenciones y estándares de codificación de la organización.
1.5.3.2. **Aplicación en el CVDS** Utilizada en la etapa de codificación.
1.5.3.3. **Recomendaciones** Integrar el análisis de estilo en el flujo de trabajo de CI para asegurar que se mantenga el estándar de codificación.
1.5.3.4. **Fortalezas** ***** Mejora la calidad del código y hace que sea más fácil de mantener y leer. ***** Detecta problemas de estilo y errores menores que pueden causar problemas en el futuro.
1.5.3.5. **Debilidades** ***** No verifica la lógica del programa, solo su estilo y consistencia. ***** Puede generar advertencias innecesarias que no afectan el funcionamiento del código.
2. Métodos Dinámicos (Validación)
2.1. Black Box Testing
2.1.1. Técnicas asociadas
2.1.1.1. **Boundary Value Analysis (BVA)** Prueba los valores en los límites de las entradas.
2.1.1.2. **Equivalence Class Partitioning** Divide las entradas en clases de equivalencia que generen resultados similares.
2.1.1.3. **Decision Table Testing** Evalúa combinaciones de condiciones en una tabla para asegurar una cobertura completa.
2.1.2. Información
2.1.2.1. **Propósito** Evaluar el comportamiento del software sin considerar su estructura interna. Solo se analizan las entradas y salidas.
2.1.2.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas
2.1.2.3. **Recomendaciones** Usar técnicas de caja negra para cubrir los requerimientos del usuario y asegurarse de probar todas las funciones principales.
2.1.2.4. **Fortalezas** ***** Permite verificar la funcionalidad general sin necesidad de conocer la lógica interna. ***** Ideal para realizar pruebas desde la perspectiva del usuario final.
2.1.2.5. **Debilidades** ***** No permite descubrir defectos en la estructura interna del código. ***** Puede requerir una gran cantidad de casos de prueba para lograr una buena cobertura.
2.2. White Box Testing
2.2.1. Técnicas asociadas
2.2.1.1. **Cause Effect Graphing** Mapeo de relaciones de causa y efecto en el sistema para identificar problemas lógicos
2.2.1.2. **DD Path Testing** Evalúa todos los caminos posibles en el programa para asegurar que cada ruta lógica es funcional.
2.2.1.3. **Data Flow Testing** Analiza el flujo de datos y cómo se usan las variables.
2.2.2. Información
2.2.2.1. **Propósito** Validar la estructura y flujo interno del código, asegurándose de que todas las rutas y condiciones se evalúen adecuadamente.
2.2.2.2. **Aplicación en el CVDS** Utilizada en la fase de codificación
2.2.2.3. **Recomendaciones** Usar pruebas de caja blanca en combinación con pruebas de caja negra para una cobertura completa del sistema.
2.2.2.4. **Fortalezas** ***** Identifica problemas de lógica interna, como errores de flujo y asignación de variables. ***** Permite una alta cobertura de código.
2.2.2.5. **Debilidades** ***** Compleja y requiere acceso y conocimiento detallado del código. ***** Es difícil cubrir completamente todos los caminos en sistemas grandes.
2.3. Heuristic Testing
2.3.1. Información
2.3.1.1. **Propósito** Usar el conocimiento previo y la intuición del tester para adivinar posibles defectos comunes.
2.3.1.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas
2.3.1.3. **Recomendaciones** Utilizar en conjunto con pruebas estructuradas para cubrir errores comunes y errores específicos en áreas de riesgo.
2.3.1.4. **Fortalezas** Es rápido y útil para detectar problemas en áreas problemáticas conocidas.
2.3.1.5. **Debilidades** Depende en gran medida de la experiencia y habilidades del tester; no es sistemático.
2.3.2. Técnicas asociadas
2.3.2.1. **Error Guessing** Consiste en intentar adivinar ubicaciones de errores basándose en experiencia previa.
2.4. Interface Testing
2.4.1. **Propósito** Verificar que los módulos se comunican e interactúan correctamente entre sí.
2.4.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas
2.4.3. **Recomendaciones** ***** Implementar herramientas de simulación para probar interfaces en situaciones límite. ***** Realizar pruebas tanto en interfaces internas como externas.
2.4.4. **Fortalezas** Asegura la funcionalidad de los módulos cuando trabajan juntos.
2.4.5. **Debilidades** No evalúa la funcionalidad de los módulos de manera individual.
2.5. Adicionales ...
2.5.1. Regression Testing
2.5.1.1. **Propósito** Asegurarse de que las nuevas modificaciones o mejoras en el sistema no introduzcan nuevos errores ni afecten el funcionamiento de las funcionalidades previas.
2.5.1.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas y mantenimiento.
2.5.1.3. **Recomendaciones** Automatizar las pruebas de regresión, especialmente en sistemas grandes, para ahorrar tiempo y garantizar una cobertura exhaustiva.
2.5.1.4. **Fortalezas** ***** Asegura que las funciones previamente correctas sigan funcionando tras cambios o mejoras. ***** La automatización facilita su ejecución rápida y continua, lo que es fundamental en entornos de desarrollo ágil.
2.5.1.5. **Debilidades** ***** Puede ser costoso en términos de tiempo y recursos si no se automatiza adecuadamente. ***** Si las pruebas no se actualizan, pueden volverse obsoletas y no detectar errores nuevos.
2.5.2. Stress Testing
2.5.2.1. **Propósito** Evaluar la resistencia del sistema bajo condiciones extremas de carga.
2.5.2.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas.
2.5.2.3. **Recomendaciones** Utilizar herramientas de simulación para reproducir las condiciones de estrés de forma controlada.
2.5.2.4. **Fortalezas** Permite prever problemas de rendimiento antes de que el sistema entre en producción.
2.5.2.5. **Debilidades** Puede ser difícil y costoso simular escenarios de estrés reales de forma precisa.
2.5.3. Usability Testing
2.5.3.1. **Propósito** Evaluar la facilidad de uso del software desde la perspectiva del usuario final.
2.5.3.2. **Aplicación en el CVDS** Utilizada en la fase de pruebas
2.5.3.3. **Recomendaciones** Realizar pruebas de usabilidad con usuarios reales que representen al grupo objetivo.
2.5.3.4. **Fortalezas** Reduce la necesidad de capacitación y soporte técnico al hacer el sistema más intuitivo.
2.5.3.5. **Debilidades** Puede ser subjetivo y depender de la experiencia de los usuarios.