Resumen ISTQB
CAPITULO 1 Capítulo 1.1 - ¿Por qué son necesarias las pruebas? Error: acción humana que produce un resultado incorrecto Defecto: desperfecto de un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas
Fallo: manifestación física o funcional de un producto Principal papel del proceso de pruebas: I) II) III)
Mejora de la calidad de un producto de sw Reducción del riesgo de detectar errores Satisfacer compromisos
Costo de los defectos: I) II)
Costo de eliminar defectos se incrementa i ncrementa con el tiempo de permanencia del defecto en el sistema La detección temprana de defectos en etapas tempranas permite la corrección de los l os mismos a costes reducidos
Atributos funcionales I) II) III) IV) V)
Adecuación Exactitud Interoperabilidad Seguridad Cumplimiento de funcionalidades
Atributos no funcionales: I)
Fiabilidad: -
II)
Usabilidad -
III)
Características: sistema requiere la utilización de un mínimo de recursos
Mantenibilidad -
V)
Características: fácil de usar, fácil de aprender, conforme a normas y uso intuitivo
Eficiencia -
IV)
Características: en determinadas condiciones el software/sistema mantendrá su capacidad/funcionalidad a lo largo de un periodo de tiempo Fiabilidad = calidad/tiempo
Características: medida del esfuerzo requerido para realizar cabios en los componentes de un sistema
Portabilidad -
Capacidad del sw de ser transferido t ransferido a un nuevo entorno ( sw, hw, organización) Caracteristicas: fácil de instalar y desinstalar parametros
Tipos de Aseguramiento de calidad – Actividades constructivas: prevenir el defecto, por ej. a través de la aplicación de módulos apropiados de la Ing. de sw Organización: Guía, estándares, listas de comprobación, reglas de procesos y normas, requisitos legales Técnicos: Métodos, herramientas, lenguajes, listas / plantillas, IDES Consignas: I) II) III)
Los defectos evitados no requieren ser rearados Los defectos introducidos en el pasado no deben ser repetidos Prevenir defectos
Tipos de Aseguramiento de calidad – Actividades analíticas: detectar defectos I)
DINAMICOS 1) Caja Negra A) B) C) D) E)
Partición de equivalencias Análisis de valores limite Prueba de transición de estados Tablas de decisión Pruebas de caso de uso
2) Técnicas basadas en la experiencia 3) Caja Blanca A) B) C) D)
Cobertura de sentencia Cobertura de rama Cobertura de condición Cobertura de caminos
Consigna 1: los defectos deben ser detectados tan pronto como sea posible respecto del proceso Consigna 2: Incluye la ejecución del programa II)
Estático 1) Revisiones / revisiones guiadas 2) Análisis de flujo de control 3) Análisis de flujo de datos 4) Métricas del compilador / Analizador Consigna: evaluación sin la ejecución del programa
Objetivos de las pruebas: 1) Adquirir conocimientos sobre defectos en un objeto de pruebas Los defectos contenidos en un objeto de pruebas deben ser detectados y descritos de tal forma que se facilite su corrección.
2) Confirmación de la funcionalidad La funcionalidad del sistema debe ser implementada tal y como ha sido e specificada.
3) Generar Información Se debe proporcionar información relativa a los posibles riesgos o a un sistema de software antes de su entrega a los usuarios. La obtención de esta información puede ser uno de los objetivos de
las pruebas 4) Generar Confianza Un sistema que ha sido probado de forma adecuada se considera que cumple con la funcionalidad esperada y cuenta con un alto nivel de calidad
¿Cuantas pruebas son suficientes? NOTA: Por lo visto en las evaluaciones realizadas el mejor motivo para determinar las pruebas son las pruebas basadas en riesgos I)
Criterios de salida
No encontrar más defectos, es un criterio apropiado para finalizar las actividades de pruebas, sin
embargo, son necesarias otras mercas para reflejar de forma adecuada el nivel de calidad alcanzado II)
Pruebas basadas en riesgos
Los niveles de riesgos determinan el grado en el cual se ha probado, es decir, responsabilidad en caso de fallos, probalidad de la ocurrencia de fallo, respecto a factores económicos propios del proyecto
III)
Pruebas basadas en plazos y presupuestos
Disponibilidad de los recursos: (persona, tiempo y presupuesto) pueden determinar la medida del esfuerzo del proceso de prueba
Casos de prueba NOTA: según la IEE 829 los casos de prueba deben contener la siguiente información: OBLIGATRORIO: 1) 2) 3) 4) 5) 6) 7)
Precondiciiones Conjuntos de valores de entrada Conjunto de resultados esperados (valores de salida) Postcondiciones esperadas Identificador único Dependencia de otros casos de preba Referencia al requisito que será probado
OPCIONALES: 8) Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados 9) Prioridad
Bases de Pruebas: Conjunto de documentos que definen los requisitos de un componente o sistema, se utiliza como fundamento para el desarrollo de casos de prueba
RESUMEN CAPITULO 1.1: Los fallos del software pueden causar importantes daños La calidad del software es la suma de los atributos que se refieren a la capadidad del software de satisfacer un conjunto de requisitos dados El aseguramiento de la calidad constructiva se ocupa de la prevención de defectos El aseguramiento de la calidad analítico se ocupa de la detección y corrección de defectos Los atributos funcionales y no funcionales de la calidad, definen la calidad total del sistema Cada prueba debe contar con criterios de salida, al alcanzar los criterios de salida conluiran las actividades de prueba Los probadores, buscan fallos en el sistema e informan sobre los valores mismos, los desarrolladores buscan defectos y los corrigen
CAPITULO 1.2 - ¿Qué son las pruebas? CONSIGNA: la ejecución de pruebas es solo una parte de las pruebas El proceso de pruebas debe incluye: 1) 2) 3) 4) 5) 6)
Planificación y control Selección de condiciones de prueba Diseño y ejecución de pruebas Comprobación de resultados Generación de informes respecto del proceso de purebas y el sistema sujeto a pruebas Finalización y completar actividades de cierre
NOTA: la revisión de documentos, código fuente y la realización de análisis estatico también ayudan a prevenir la aparición de defectos en el código.
Objetivos de las pruebas 1) Detección de defectos
A) Pruebas de desarrollo: causar tantos fallos como sea posible B) Pruebas de aceptación: Confirmar que el sistema funciona como se espera 2) Generación de confianza respecto al nivel de c alidad 3) Aportación de información para la toma de decisiones 4) Prevención de defectos
Términos - desarrollo de SW I)
Depuración:
Proceso de encontrar, analizar y eliminar las causas de los fallos de SW Prueba -> Detección – Identificación de defectos ->Corrección de defectos - > Repetición de pruebas
Probar y repetir la prueba son actividades propias del proceso de pruebas: - Las pruebas muestran los fallos - Repetición de pruebas: verifica que el defecto ha sido corregido LA DEPURACIÓN Y CORRECCIÓN DE DEFECTOS SON ACTIVIDADES PROPIAS DEL DESARROLLADOR II)
Requisitos
Condición o capacidad necesario para un usuario con el objetivo de solucionar un problema o lograr un objetivo que debe ser alcanzado o poseído por un sistema o componente de un sistema, para satisfacer un contrato, estándar, especificación u otro documento impuesto formalmente
III)
Revisión
Evaluación de un producto o del estado de un proyecto para detectar discrepancias con los resultados planificados y para recomendar mejoras. EJ; revisión de gestión, revisión informal, revisión técnica, inspección y revisión guiada
Resumen capitulo. I) II)
Pruebas dinámicas: ejecución del software / muestran fallos que ha sido causados por defectos, la depuración detecta, analiza y elimina la causa de estos fallos Pruebas estáticas: revisión de la documentación
Capítulo 1.3 – Los 7 Principios del proceso de pruebas. 1) 2) 3) 4) 5)
El proceso de pruebas demuestra la presencia de defectos No es posible realizar pruebas exhaustivas Pruebas Tempranas Agrupación de defectos Paradoja del pesticida (Repetir pruebas no es efectivo / las pruebas deben ser revisadas/modificadas regularmente para los distintos modulos de código) 6) Las pruebas dependen del contexto 7) Falacia de la ausencia de fallos
Resumen Capitulo 1.3 -
-
-
Las pruebas pueden ayudar a detectar defectos en el software, sin embargo, las mismas no pueden demostrar la ausencia de defectos Para casos no triviales las pruebas exhaustivas son imposibles, la prueba de muestras son necesarias
Las pruebas tempranas ayudan a reducir costos, dados que los defectos descubiertos en fases tempranas del proceso de SW son c orregidos con menor esfuerzo Los defectos se presentan agrupados. Al encontrar un defecto en una ubicación determinada significa que probablemente se encontraran otros defectos a su alrededor Las repeticiones de pruebas idénticas no generan nueva información Cada entorno particular determina la forma en la cual se ejecutan/desarrollaran las pruebas Un software libre de errores nno implica su adecuación al uso
Capitulo 1.4 – Proceso de pruebas básico
Proceso de control de pruebas: actividad continua que influye en la planificación de las pruebas, el plan maestro de pruebas puede ser modificado en función de la información adquirida a partir del control de pruebas.
Plan maestro de pruebas: documento en el que se describen el alcance, enfoque, recursos y calendarios de las actividades de pruebas previstas, incluye, pero no e stá limitado a los elementos de pruebas y características que ser án probadas, recursos.
Estrategia de prueba: Descripción a alto nivel de los niveles de prueba a llevar a cabo y las pruebas asociadas a ellos para una organización o programa.
Enfoque de pruebas: Implementación de la estrategia de prueba para un proyecto en especifico. Normalmente incluye las deciciones tomadas con el objeto de lograr los obje tivos del proyecto y el análisis de riesgos, puntos de inicio respecto al proceso de pruebas, técnicas de diseño de pruebas a aplicar, criterio de salida y tipos de prueba a ejecutar.
Criterios de salida: Conjunto de condiciones genéricas y especificas, acordadas con los involucrados, para que un proceso sea considerado formalmente de forma conlcuida.
Datos de prueba: Datos que existen en el sistema antes que la prueba sea ejecutada y que afecta o es afectado por el componente o sistema sujeto a pruebas
Datos de entrada: Variable que es leida por un co mponente (que es almacenada tanto dentro como fuera del sistema).
Cobertura de pruebas: Grado en el que un requerimiento espec ifico ha sido practicado por un jueg de pruebas utilizado con mayor frequencia en pruebas de caja blanca con el objeto de determinar la cobertura del código.
Oraculo de pruebas: Fuente que permite determinar los resultados esperados de un sw sujeto a pruebas comparativas, manuales de usuario o conocimiento especializado. No debe ser el código Juego de pruebas: conjunto de casos de prueba para un componente o sistema en prueba, donde la postcondicion de una prueba es utilizada como precondición de la siguiente.
Especificaciones de procedimiento de pruebas: documento que especifica la secuencia de acciones para la ejecución de una prueba. Conocido como script de prueba o prueba manual
Ejecución de pruebas: proceso de practicar una prueba produciendo resultados reales Fases del proceso de prueba 1) Planificación e pruebas y control Abarca actividades como la definición del enfoque de pruebas para todas las fases asi como la planificación de los recursos.
2) Análisis de pruebas y diseño de pruebas Abarca el diseño de casos de prueba y sus resultados esperados.
3) Implementación de pruebas y ejecución de pruebas Abarca la definición de datos de prueba, la e jecución de pruebas y la comparación de resultados.
4) Evaluación de criterios de salidas de pruebas y generación de informe de pruebas Abarca la evalación de los criterios de salida y el registro de los resultados de purebas e n forma escrita.
5) Actividades de cierre Consiste en el control de las actividades que cubren todas las fases del proceso de prueba.
Nota1: las pruebas incluyen superposición y vuelta atrás Nota2: cada fase del proceso de pruebas tiene lugar de frma concurrente con las fases del proceso de desarrollo de software
