Los objetivos típicos de las pruebas son:

• Para verificar si se han cumplido todos los requisitos
• Para generar confianza en el nivel de calidad del objeto de prueba
• Para reducir el nivel de riesgo de software inadecuado
• Para comprobar si el objeto de prueba está completo
• Para cumplir con requisitos contractuales o legales
• Para prevenir defectos mediante la evaluación de productos de trabajo: Estos incluyen requisitos, historias de usuario, diseño y código.

Las pruebas pueden mostrar fallas causadas por defectos en el software. La depuración es una actividad de desarrollo que encuentra, analiza y corrige los defectos.

• Probar historias de usuario puede detectar defectos en productos de trabajo de alto nivel.
• El diseño del sistema de pruebas puede reducir el riesgo de defectos fundamentales de diseño.
• Las pruebas de desarrollo pueden aumentar la comprensión del código y reducir el riesgo de código defectuoso.
• Probar el software compilado puede detectar características que pueden haber pasado inadvertidas y aumenta la probabilidad de que el software cumpla con los estándares de las partes interesadas.

El control de calidad y las pruebas no son lo mismo, pero están relacionados. La gestión de la calidad los vincula. El control de calidad se centra en el cumplimiento de los procesos adecuados, lo que aumenta la confianza en la calidad del producto. Las pruebas son parte del control de calidad y respaldan el logro de los niveles de calidad.

• Errores: Un error cometido por una persona.
• Defecto: Una falla en el sistema que provoca que falle una función requerida.
• Fallo: Evento del sistema desencadenado por un defecto específico (no todos los defectos pueden causar siempre un fallo).

• Efectos: quejas de clientes, problemas en el código base, historia de usuario ambigua
• Causa raíz: el propietario del producto no comprende una parte de la solución, el desarrollador tiene experiencia.
• Solución: capacitar a la persona en cuestión.

1. Las pruebas muestran la presencia de defectos, no su ausencia
2. No es posible realizar pruebas exhaustivas
3. Las pruebas tempranas ahorran tiempo y dinero
4. Los defectos se agrupan Un pequeño número de módulos, normalmente módulos de integración, son responsables de muchos errores.
5. La paradoja de los pesticidas
6. Las pruebas dependen del contexto. El software de control industrial crítico para la seguridad se prueba de manera diferente a una aplicación móvil de comercio electrónico. Las pruebas ágiles se realizan de manera diferente al desarrollo de software secuencial.
7. La ausencia de errores es una falacia.

Un proceso de prueba es un conjunto de actividades, que dependen de factores como:

• Metodología SDLC
• Riesgos del producto/proyecto
• Costos operacionales
  • Presupuesto
  • Escala de tiempo
  • Complejidad
  • Cumplimiento contractual y normativo

Proceso de prueba: conjunto de actividades interrelacionadas que comprenden la planificación de pruebas, la supervisión de pruebas, el análisis de pruebas, el diseño de pruebas, la implementación de pruebas, la ejecución de pruebas y la finalización de pruebas. Nota: el programa de estudios incluye muchos más detalles sobre estos procesos.

• Planificación de pruebas: definir los objetivos de las pruebas y el enfoque para alcanzarlos. Puede revisarse a partir del seguimiento y control de las pruebas.
• Monitoreo y control de pruebas: proceso continuo de comparación del progreso real con el progreso planificado. El control de pruebas implica tomar las medidas necesarias para cumplir los objetivos del plan de pruebas.
• Análisis de pruebas: se analiza la base de pruebas para identificar las características que se pueden probar y definir las condiciones de prueba asociadas. Decide qué probar.
• Diseño de pruebas: las condiciones de prueba se detallan en casos de prueba de alto nivel. Decide cómo realizar la prueba.
• Implementación de pruebas: se crea o completa el software de prueba necesario para la ejecución de las pruebas. Decide si todo está en su lugar para ejecutar las pruebas.
• Ejecución de pruebas: los conjuntos de pruebas se ejecutan de acuerdo con el cronograma de ejecución de pruebas.
• Finalización de la prueba: recopilar datos de las actividades de prueba y consolidar la información. Esto ocurre en hitos como el lanzamiento de un parche de software o una iteración de un proyecto ágil.

Los productos del trabajo dependen del contexto, pero normalmente son documentación u otros entregables creados en cada paso del proceso de prueba.

• La planificación de pruebas proporciona planes de pruebas
• La monitorización de pruebas proporciona informes de pruebas
• El análisis de pruebas proporciona condiciones de prueba definidas y priorizadas
• El diseño de pruebas proporciona casos de prueba
• La implementación de pruebas proporciona conjuntos de pruebas y cronogramas
• La ejecución de pruebas proporciona documentación de casos de prueba e informes de defectos.

Trazabilidad: Grado en el que se puede establecer una relación entre dos o más productos de trabajo. Una buena trazabilidad ayuda a analizar el impacto de los cambios, permite auditar las pruebas y mejora la comprensión del producto.

• Buena comunicación en equipo
• Evaluación del nivel de independencia del evaluador
• Adherirse a un código de ética

Un desarrollador:

• Es optimista sobre el software desarrollado
• Espera que las cosas funcionen hasta que se demuestre que no es así
• Tiene una visión a corto plazo

Un probador:

• Es pesimista sobre el software desarrollado
• Espera que las cosas no funcionen hasta que se demuestre que sí funcionan.
• Tiene una visión a largo plazo

• Actividades de desarrollo de software:
  • Actividades realizadas en un proyecto de desarrollo de software
  • Estos dependen del método SDLC elegido.
• Actividades de prueba de software:
  • Para cada actividad de desarrollo, existe una actividad de prueba correspondiente.
  • Cada nivel de prueba tiene objetivos específicos para ese nivel.
  • El análisis y diseño de pruebas comienzan en correspondencia con la actividad de desarrollo.
  • Los evaluadores participan en discusiones para definir y refinar los requisitos y el diseño.

• Diferencias en los riesgos de los productos de los sistemas
• Muchas unidades de negocio pueden ser parte de un proyecto o programa
• Plazo corto para entregar un producto al mercado

Niveles de prueba: Grupos de actividades de prueba que se organizan y gestionan en conjunto. Niveles de prueba utilizados en el programa de estudios:

• Pruebas de componentes Concéntrese en los componentes que se pueden probar por separado.
  • Base de prueba: Código, diseño detallado
  • Objetos de prueba: Componentes, unidades, clases
  • Defectos típicos: Funcionalidad incorrecta, problemas de flujo de datos.
  • Responsabilidades: Generalmente probadas por el desarrollador que escribió el código, la automatización puede ser priorizada en el desarrollo basado en pruebas.
• Pruebas de integración Se centran en la integración entre componentes o sistemas.
  • Base de prueba: Diseño de software, casos de uso, diagramas de secuencia.
  • Objetos de prueba: subsistemas, bases de datos, infraestructura, API
  • Defectos típicos: Datos incorrectos, falta de coincidencia de la interfaz
  • Responsabilidades: a menudo responsabilidad del desarrollador o del evaluador. El enfoque debe estar en la comunicación entre sujetos, no en la funcionalidad de cada sujeto individual.
• Pruebas del sistema Capacidades de un sistema o producto completo, a menudo pruebas de extremo a extremo
  • Base de prueba: Especificaciones de requisitos: funcionales/no funcionales, informes de análisis de riesgos, epopeyas e historias de usuario, manuales de usuario.
  • Objetos de prueba: Aplicaciones, sistemas operativos, sistema bajo prueba,
  • Defectos típicos: cálculos incorrectos, comportamiento incorrecto o inesperado del sistema, incumplimiento de las tareas funcionales de principio a fin.
  • Responsabilidades: Generalmente las realizan evaluadores independientes y dependen en gran medida de las especificaciones.
• Prueba de aceptación
  • Base de prueba: requisitos del usuario o del negocio, regulaciones, contrato, requisitos del sistema, procedimientos de instalación, análisis de riesgos
  • Objetos de prueba: Copia de seguridad y restauración, recuperación ante desastres, requisitos no funcionales, objetivos de rendimiento, estándares de seguridad
  • Defectos típicos: El flujo de trabajo del sistema no cumple con los requisitos del negocio, reglas de negocio incorrectas, el sistema no satisface la regulación, rendimiento inadecuado bajo cargas elevadas.
  • Responsabilidades: Responsabilidad del cliente/parte interesada.

• Funcional: Pruebas que evalúan las funciones que los sistemas deben realizar. Prueba lo que el sistema debe hacer.
• No funcional: evalúa la usabilidad, el rendimiento y la seguridad. Prueba cómo funciona el sistema.
• Pruebas de caja blanca: evalúan el código, la arquitectura, los flujos de trabajo y los flujos de datos dentro del sistema. Proporcionan un porcentaje de cobertura.

Así es. Debería hacerse lo antes posible.

Las pruebas de regresión consisten en volver a probar las pruebas aprobadas anteriormente al implementar un código nuevo para garantizar que no haya efectos secundarios no deseados. Las pruebas de confirmación consisten en verificar si una prueba que falló anteriormente pasó la prueba cuando se implementaron las correcciones.

• Modificación
  • Mejoras planificadas
  • Cambios correctivos y de emergencia
• Migración

El análisis de impacto evalúa los cambios que se realizaron para una versión de mantenimiento a fin de identificar los resultados previstos y los posibles efectos secundarios. Los efectos secundarios identificados deben analizarse para determinar su regresión.

• Presupuesto
• Código
• Épicas, historias de usuarios, criterios de aceptación
• Arquitectura, especificaciones de diseño
• Software de prueba
• Guías de usuario
• Páginas web
• Contratos
• Configuración de configuración
• Modelos, por ejemplo diagramas de actividades

Puede detectar defectos tempranos antes de realizar pruebas dinámicas. Los defectos tempranos son mucho más económicos de eliminar. Además:

• La detección y corrección se realiza de forma más eficiente
• Descubre inconsistencias, ambigüedades y redundancias.
• Reduce el coste y el tiempo de desarrollo
• Mejora la comunicación entre los miembros del equipo durante las revisiones.

Las pruebas estáticas detectan defectos en el trabajo directamente, en lugar de identificar fallas. Las pruebas estáticas se pueden utilizar para mejorar la consistencia de la calidad interna del trabajo; las pruebas dinámicas generalmente se centran en factores visibles externamente.

• Planificación
  • Definir alcance
  • Estimar el esfuerzo y el tiempo
  • Seleccionar participantes
  • Definir criterios de entrada y salida (para revisiones formales)
  • Comprobar que se cumplen los criterios de entrada (para revisiones formales)
• Iniciar revisión
  • Distribuir el producto del trabajo y otros materiales a los participantes.
  • Explicar el alcance y los objetivos a los participantes.
  • Responda cualquier pregunta que puedan tener los participantes
• Preparación individual
  • Revisar toda o parte del producto del trabajo.
  • Anotar posibles defectos, recomendaciones, preguntas.
• Comunicación y análisis de problemas
  • Comunicar los defectos identificados (en una reunión)
  • Asignar propiedad y estado a los defectos
  • Evaluar y documentar la calidad
  • Evaluar los hallazgos, tomar una decisión de revisión (rechazar; se necesitan cambios importantes, aceptar; posiblemente con cambios menores)
• Reparación y reporte
  • Crear informes de defectos
  • Corregir los defectos encontrados
  • Estado actualizado del registro (formal)
  • Recopilar métricas (formales)
  • Comprobar que se cumplen los criterios de salida (formal)
  • Aceptar el producto del trabajo

En algunos tipos de revisión, una persona puede desempeñar más de un rol.

• Autor
  • Crea un producto de trabajo
• Gestión
  • Revisar la planificación, asignar personal y presupuesto.
• Facilitador/Moderador
  • Garantiza el funcionamiento eficaz de la reunión de revisión.
• Líder de la revisión
  • Asume la responsabilidad general de la revisión.
• Revisores
  • Pueden ser expertos en la materia, personal, partes interesadas.
• Escriba
  • Recopila posibles defectos
  • Puntos de discusión sobre los registros

• Revisión informal: por ejemplo, verificación entre compañeros, solución rápida de problemas menores.
• Tutorial: Busque defectos, mejore el producto de software, intercambie ideas y considere alternativas. El uso de un escriba es obligatorio, las listas de verificación son opcionales
• Revisión técnica: se logra consenso, se evalúa la calidad y se genera confianza. Se requiere preparación individual. Es obligatorio que haya un redactor, idealmente no un autor.
• Inspección: Motivar y permitir a los autores mejorar su trabajo futuro. Sigue un proceso definido, utiliza roles claramente definidos. El líder de la revisión es un facilitador. Se especifican los criterios de entrada y salida. Se recopilan métricas.

• Revisión ad hoc
• Basado en listas de verificación
• Escenarios y simulacros
• Basado en la perspectiva
• Basado en roles

Los factores organizacionales y relacionados con las personas contribuyen al éxito. Organizacional:

• Cada revisión tiene objetivos claros
• Se aplican los tipos de revisión adecuados
• Las listas de verificación están actualizadas
• Los documentos grandes se escriben y revisan en fragmentos pequeños.
• Las revisiones tienen un aviso adecuado

Relacionado con las personas:

• En cada revisión están involucrados ricos
• Los probadores son vistos como revisores valiosos
• Los participantes dedican el tiempo y la atención adecuados a los detalles.
• Se proporciona una formación adecuada
• Se promueve una cultura de aprendizaje

Todas las técnicas de prueba se sustentan en la identificación de condiciones de prueba, casos de prueba y datos de prueba. Algunas técnicas son aplicables a situaciones y niveles de prueba específicos, mientras que otras son aplicables a todos los niveles de prueba.

Los casos de uso son una forma específica de diseñar interacciones con elementos de software. Los casos de uso están asociados con actores (por ejemplo, usuario humano, sistema externo) y sujetos (por ejemplo, el componente o sistema al que se aplica el caso de uso). Los casos de uso están diseñados para ejercitar comportamientos específicos:

• Básico
• Excepcional
• Alternativa
• Manejo de errores

Las pruebas están diseñadas para ejercitar estos comportamientos.

La cobertura de declaraciones es el número de declaraciones ejecutadas por pruebas dividido por el total de declaraciones:

• Cobertura de declaraciones = número de declaraciones ejecutadas / total de declaraciones.

La cobertura de decisiones cubre cada decisión en el código y prueba el código ejecutado en función de esa decisión.

• Cobertura de decisiones = número de resultados de decisiones ejecutados / número total de resultados de decisiones

La cobertura de sentencias del 100 % garantiza que todas las sentencias ejecutables del código se hayan probado al menos una vez. No garantiza que se haya probado toda la lógica de decisión. Cuando se logra una cobertura de decisiones del 100 %, se ejecutan todos los resultados de decisión (verdaderos y falsos) incluso cuando no hay una sentencia falsa explícita. Alcanzar una cobertura de decisiones del 100 % garantiza una cobertura de sentencias del 100 % (pero no al revés).

Estas pruebas se derivan de la habilidad y la intuición del desarrollador. La cobertura que se obtiene con estas pruebas puede resultar difícil de evaluar.

La estimación de errores se utiliza para anticipar la aparición de errores, defectos y fallos, basándose en el conocimiento del evaluador. Esto incluye:

• Cómo ha funcionado la aplicación en el pasado
• ¿Qué tipo de errores se suelen cometer?
• Fallos que han ocurrido en otras aplicaciones

Las pruebas exploratorias diseñan pruebas informales que se ejecutan y registran de forma dinámica. Los resultados de las pruebas exploratorias se pueden utilizar para obtener más información sobre el sistema y descubrir otras posibles pruebas dentro de estas áreas. Resultan útiles cuando hay pocas especificaciones, mucha presión de tiempo y para complementar técnicas de prueba más formales.

Los evaluadores diseñan, implementan y ejecutan pruebas para cubrir las condiciones de prueba que se encuentran en una lista de verificación. Luego, se analizan los resultados para crear nuevas listas de verificación o ampliar una existente. Las listas de verificación se crean en función de la experiencia previa. Estas listas de verificación suelen ser de alto nivel, lo que permite una mayor cobertura pero una menor reproducibilidad.

Los evaluadores independientes son más eficaces a la hora de encontrar defectos. Sin embargo, esto no exime a los desarrolladores. Los desarrolladores independientes podrían ser:

• Ninguno, todos los desarrolladores prueban su propio código.
• Los desarrolladores prueban el código dentro de su equipo
• Los desarrolladores prueban el código dentro de su organización
• Desarrolladores especializados dentro de la organización
• Probadores independientes fuera de la organización.

Pruebas independientes:

• Beneficios: Suele ser más completo, ya que no lo prueban las personas que lo construyeron.
• Desventajas: Mayor coste, retrasos en la retroalimentación, falta de colaboración.

Las tareas específicas de cada uno dependen del proyecto. El gerente de pruebas tiene la responsabilidad general del proceso de pruebas. Varios equipos pueden rendir cuentas a un gerente de pruebas. Los gerentes de pruebas:

• Desarrollar una política/estrategia de pruebas
• Considere el contexto y el riesgo
  • Seleccione ‘enfoque de prueba’
  • Estimar el tiempo y el costo de la prueba
  • Adquirir recursos
• Escribe el plan de pruebas
• Informes de progreso, resúmenes
• Decidir sobre la implementación de entornos de prueba.

Las tareas típicas del evaluador pueden incluir:

• Revisar/contribuir a los planes de prueba
• Evaluar requisitos, historias de usuarios y bases de prueba.
• Condiciones de prueba del documento
• Ejecutar pruebas, evaluar pruebas, documentar desviaciones
• Automatice las pruebas según sea necesario
• Revise las pruebas desarrolladas por otros

A nivel de componentes, el rol de probador lo cumplen los desarrolladores. A nivel de pruebas de aceptación, el rol de probador lo suelen desempeñar los analistas de negocios, los expertos y los usuarios. Consulte las notas a continuación sobre los objetivos de aprendizaje.

Un plan de pruebas describe las actividades de prueba para el desarrollo y mantenimiento de proyectos. La planificación está influenciada por la política y la estrategia de pruebas de la organización (SDLC). El contenido incluye:

• Alcance
• Acercarse
• Integración SDLC
• Selección de métricas
• Presupuesto

• Analítico: Análisis de algún factor. Por ejemplo, análisis basado en riesgos.
• Basado en modelos: un modelo de un aspecto requerido del producto
• Metódico: Uso sistemático de pruebas predefinidas. Por ejemplo, Taxonomía.
• Cumple con las normas
• De consultación
• Aversión a la regresión: evita romper cosas viejas
• Reactivo: Las pruebas se diseñan y (a menudo de inmediato) se ejecutan en función del conocimiento adquirido en pruebas anteriores.

es Definición de Listo y Definición de Hecho

• Porcentaje del trabajo planificado realizado en entornos de prueba
• Cobertura de prueba de
  • Requisitos
  • Historias de usuarios
  • Código
• Costo vs beneficio de las pruebas

El objetivo de un informe de prueba es comunicar información sobre la actividad de prueba. Contiene un resumen de las pruebas realizadas, las desviaciones del plan, los obstáculos y las métricas. Su contenido está adaptado a un público técnico o ejecutivo.

Los informes de pruebas se pueden realizar durante y al final de una actividad de prueba. El informe de prueba realizado durante una actividad de prueba puede denominarse informe de progreso de la prueba.

Gestiona el control de versiones de pruebas, software de pruebas (testware) y documentación.

• Nivel de riesgo = Probabilidad * Impacto

o

• Nivel de riesgo = Probabilidad + Impacto

Los riesgos del proyecto son situaciones que frenan el progreso del proyecto. Entre ellos se incluyen retrasos en el proyecto, requisitos ambiguos y problemas políticos. Los riesgos del producto implican que un producto de trabajo puede no satisfacer a las partes interesadas. Se trata de problemas de calidad como errores y problemas de experiencia del usuario.

Riesgos del producto

• Software no conforme a las especificaciones
• La arquitectura del sistema no es adecuada
• Los tiempos de respuesta son inadecuados

Riesgos del proyecto

• Problemas del proyecto
• Cuestiones organizativas
• Cuestiones políticas
• Problemas técnicos

El análisis de riesgos puede influir en las técnicas de prueba utilizadas y en la priorización de las pruebas. Un caso con un nivel de riesgo alto se analizaría con mayor profundidad y en un ámbito más amplio.

Los defectos deben registrarse y se debe hacer un seguimiento de los defectos desde su descubrimiento hasta su resolución. Algunos informes pueden ser falsos positivos, lo que debe minimizarse. Los defectos pueden informarse durante todo el ciclo de vida del desarrollo de software. Los informes de defectos deben contener información sobre eventos adversos y deben proporcionar un medio para realizar un seguimiento de la calidad del trabajo. Pueden proporcionar ideas para mejorar el proceso de desarrollo y prueba.

• Automatización de pruebas (ejecución de pruebas, regresión)
• Pruebas manuales de soporte
• Mejorar la reproducibilidad de las pruebas
• Aumentar la confiabilidad

• Reducción del trabajo manual
• Mayor consistencia
• Medidas estáticas, cobertura
• El tiempo y el costo pueden subestimarse
• Dependencia excesiva
• El control de versiones puede descuidarse
• El proveedor podría cesar su actividad

• Captura de la entrada del probador: no siempre es reproducible, puede ser una mala idea
• Pruebas basadas en datos: separa la entrada y los resultados, puede ejecutar el mismo script con diferentes datos
• Prueba basada en palabras clave: invoca secuencias de comandos de prueba basadas en palabras de acción

Estos enfoques requieren conocimientos de lenguajes de programación. Estas pruebas aún deben compararse con resultados dinámicos en algún momento.

• Madurez de la organización
• Oportunidades de mejora mediante el uso de la herramienta
• Comprensión de la tecnología
• Evaluación de riesgos y costos

• Adquiere conocimientos sobre la herramienta.
• Evalúa cómo la herramienta encaja en la organización
• Evalúa si el coste es razonable

• Despliegue gradual
• Adaptación del proceso para ajustar la herramienta
• Proporcionar formación y apoyo
• Monitorizar el uso de herramientas
• Recopilar lecciones aprendidas

¿Te ha resultado útil??

SiNo

0 / 0

#resumen; istqb