Sem título

•Porque son necesarias?

•1-Economica: cuando el funcionamiento de x depende de un software.

•2-Calidad de software: Es parte determinante del exito de los sistemas y productos

•3-Mejora de calidad: las pruebas aseguran la calidad del producto

•4-Causas o fallos: por errores humanos(fallos) o condiciones ambientales

Capitulo 1

••Objetivos de las pruebas

••1-Adquirir conocimiento: Detectar y corregir defectos

••2-Confirmar funcionalidad: para implementar tal y como se especifica

••3-Generar Informacion: informar posibles riesgos antes dela entrega

••4-Ganar confianza: un software aprobado cumple con la funcionalidad y calidad

•QA en Proceso de desarrollo-mantemiento-operaciones

•-Mejora la calidad, retira defectos que produzcan fallos y aportan atributos deseados.

•-Reduccion de riesgos, se reduce el riesgo de encontrar errores en la fase de operaciones del software.

•-Satisfacer compromisos, cumpla con los estandares propios de la industria.

•-Costos de los defectos, reduccion temprana permite la correccion y reduce costos.

•

••Conceptos

••Error: IEEE610-Accion humana

••Defecto(bug): componente o sistema que causa el fallo del desempeño

••Fallo: Manifestacion fisica o funcional de un defecto, los defectos causan fallos

••Software(IEEE610): Programas de ordernador procedimientos y/o documentacion y datos de una operacion de un sistema

•Conceptos

•Calidad de software(IEEE9126): total funcionalidad de un producto que contribuyen con su capacidad de satisfacer necesidades explicitas o implicitas

•Calidad(IEEE610): Grado de un componente, sistema o proceso que satisface requisitos, necesidades y expectativas de un cliente/usuario

​​​​​

•Los 6 atributos

•Funcional: Satisface el cumplimiento de capacidades requeridos: adecuación, exactitud, etc.

•No FUNCIONALES:

•2. Fiabilidad: Tolerancia al defecto.

•3. Usabilidad: Fácil de usar.

•4. Eficiencia: Requiere la utilización mínima de recursos para ejecutar una tarea.

•5. Mantenibilidad: Analizabilidad, modificabilidad, medida del esfuerzo requerido para realizar cambios en los componentes del sistema.

•6. Portabilidad: Capacidad del software de ser transferido a un nuevo

entorno, fácil de instalar y desinstalar

•El 25010 tiene 8 atributos en los no funcionales:

•7.Seguridad.

•8.Compatibilidad: se mantienen funcionando Calidad /tiempo

•Cuantas pruebas son suficientes?

•-Criterios de salida: se aborda los casos necesarios

•-Pruebas basadas en riesgos:los niveles de riesgos determinan el grado en el cual se ha aprobado

•-Pruebas basadas en plazos y presupuestos: la disponibilidad de recursos puede determinar la medida del esfuerzo del proceso de prueba

•Tipos de Aseguramiento:

•Constructiva: Previene defectos

•1-Defecto evitado no requiere ser reparado

•2-Los defectos pasados no deben ser repetidos

•3-Prevenir defectos

•Procesos:

•-Tecnicos: Metodos, herramientas, lenguajes, listas, IDE.

•-Organizacion: Guias, estandares, listas de comprobacion, reglas de procesos y normas, requisitos legales.

•Tipos de Aseguramiento:

•Analitica: Detectar defectos.

•1-Los defectos deben ser detectados tan pronto como sea posible.

•2- Pruebas estaticas evaluan sin la ejecucion del software.

•3-Pruebas dinamicas incluyen la ejecucion del programa

•Procesos:

•-Estaticos: Revisiones guiadas, anlisis de flujos de control, analisis de flujos de datos, analizador.

•Dinamica:

•1-Caja blanca: cobertura de sistema, cobertura de rama, cobertura de decision/camino, cobertura de condicion y multicondicion (valores logicas del software).

•2-Caja negra: particion de equivalencia, analisis valores limite, pruebas de transicion de estado, tablas de decision, pruebas de caso de uso

•3-Tecnicas basadas en experiencia: exploratorias, prediccion de estados.

•Conceptos:

•Casos de prueba (IEEE829). Documentación para el proceso de prueba,

•que incluye la siguiente información del IEEE610:

•Pre condición.

•Conjunto de valores.

•Conjunto de resultados esperados.

•Post condiciones esperados.

•Identificador único.

•Dependencia de otros casos de prueba.

•Referencia al requisito que será probado.

•Forma a ejecutar el caso de prueba y verificar resultado (opcional).

•Prioridad (opcional).

•Conceptos:

•Base de prueba. Documentación que definen los requisitos de un componente o sistema.

•Código/código fuente: Programa de ordenador escrito en un lenguaje de programación que puede ser leido por una persona.

•Depuración. Localización y corrección de defectos en el código fuente.

•Desarrollo de software. Proceso, secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un ordenador.

•Requisito. Este describe a un atributo deseado u obligatorio.

•Revisión (IEEE 1028). Evaluación de un producto o del estado de un proyecto para detectar discrepancias respecto al resultado planificado y recomendar mejoras.

•Prueba y depuración (proceso)

•Prueba-> Depuración (Detección, identificación y corrección de defectos) -> repetir pruebas.

•7 principios del proceso de prueba.

•El proceso de prueba demuestra la presencia de defectos, nunca la ausencia.

•No es posible realizar pruebas exhaustivas.

•*Pruebas exhautivas: abarca todas las combinaciones de valores de entrada y precondiciones.

•*Explosion de casos de prueba: incremento del costo y esfuerzo en una prueba exhaustiva.

•*Prueba maestra: Incluye un subconjunto de todas los posibles valores de entrada.

•3. Pruebas tempranas: Entre más temprana la detección de defectos, menos el costo de corrección. El proceso de preparación de prueba consume tiempo, actividades de pruebas y/o especificación y diseño.

•4. Agrupamiento de defectos: Defectos aparecen agrupados, investigar un mismo módulo donde hubo un defecto.

•5. Paradoja del pesticida: Si se ejecutan las mismas pruebas no se encontrarán nuevos defectos.

•6. Las pruebas dependen del contexto: Objetos de prueba diferentes son probados de forma diferente.

•7. Falacia de ausencia de errores: Un proceso de prueba detectará los fallos más importantes. No se introduce la calidad a través de las pruebas. La calidad se construye desde el principio.

•Proceso de prueba (ver también cap 5)

•Fases:

•Planificación y control:

•-Determina el alcance de riesgos.

•-Identificador de objetivos.

•-Determinar técnicas.

•-Cobertura y equipo de pruebas.

•-Implementar método y planificación de tiempo.

•-Adquirir y programar recursos y presupuesto.

Conceptos:

Plan maestro de pruebas (IEEE829): Documento que describe el alcance, enfoque, recursos y calendario de las actividades de prueba.

Estrategia de prueba: Descripción del 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 prueba: Implementación de la estrategia de prueba para un

proyecto en específico. Incluye decisiones tomadas para lograr objetivos.

Criterios de salida: El propósito es evitar que una tarea se considere

concluida habiendo partes destacadas de la misma sin completar.

Los criterios de salida son utilizados como una referencia para

elaborar informes y planificar cuando se deben finalizar

las pruebas.

Proceso de prueba (ver también cap 5)

Fases:

2. Análisis y diseño:

-Revisar bases de prueba.

-Analizar la testabilidad.

-Identificar y priorizar condiciones de prueba.

-Diseñar pruebas-casos de prueba.

-Identificar condiciones de prueba específicas y datos de prueba necesaria.

-Diseñar el entorno de prueba (cama de prueba,ambiente de prueba).

-Probar infraestructura y herramientas de prueba.

-Crear trazabilidad bidimencional entre las bases de prueba y

casos de prueba (pre y post de la creación).

Conceptos:

Datos de prueba: Datos que existen en el sistema antes de que una prueba sea

ejecutada y que afecta o es afectada por el componente o sistema sujeto a prueba.

Datos de entrada: Variable que es leida por un componente.

Cobertura de pruebas: Grado en el que un elemento ha sido practicado

por un juego de pruebas. Se usa caja blanca con el objetivo de determinar

la cobertura de un código.

Oráculo de prueba (Doc. De casos de prueba como un check list).

Fuente que permite determinar los resultados esperados de un

software sujeto a pruebas.

Proceso de prueba (ver también cap 5)

Fases:

3. Implementación y ejecución de pruebas:

- Finalizar, implementar y priorizar casos de prueba.

-Desarrollar, priorizar procedimientos de prueba. Crear datos, preparar arnéces de

prueba, redactar guines de pruebas automatizados, crear juegos de prueba.

-Verificar el entorno de prueba.

-Verificar y actualizar la trazabilidad (bases de prueba-casos de prueba).

-Ejecutar prueba, seguir la secuencia de pruebas establecidas en el plan

de prueba.

-Registrar los resultados de prueba y análisis.

- Comparar resultados reales con los esperados.

-Informar y analizar incidencias para saber sus causas.

-Repetir actividades de prueba para confirmar su corrección:

Re test, para la revisar la corrección del defecto. Regresión:

una actualización o modificación.

Conceptos:

Juegos de prueba: Conjunto de casos de prueba para un componente o sistema

donde la post condición de una prueba es utilizada como una precondición de la siguiente.

Especificación de procedimiento de prueba (test script): Documento que

especifica la secuencia de acciones para la ejecución de una prueba (IEEE829).

Ejecución de prueba: Proceso de practicar una prueba produciendo resultados

reales.

Registro de prueba (protocolo de prueba). Registro cronológico de los detalles

relevantes respecto a la ejecución de prueba. IEEE829 cuando se desarrollan

las pruebas qué resultados fueron generados.

Pruebas de regresión: Pruebas que se realizan cuando el software

o su entorno ha sido modificado.

Repetición de pruebas (re test). Tras la corrección de un defecto

para confirmar que el defecto ha sido eliminado.

Proceso de prueba (ver también cap 5)

Fases:

4. Evaluación de criterios de salida y generación de informes:

-Evaluar la ejecución de pruebas con respecto a los objetivos definidos.

-Evaluar los registros de prueba (resumen de actividades).

-Proporcionar información con el objetivo de dar lugar a la decisión

de llevar a cabo pruebas adicionales.

Proceso de prueba (ver también cap 5)

Fases:

5. Actividades de cierre:

-Recopilar datos de las actividades de proceso de prueba finalizadas, consolidar experiencia,

producto del soporte de prueba.

-Cerrar informes de incidencia o generación de solicitudes de cambio para cualquier punto que

quedara abierto.

-Comprobar qué entregables planificados han sido enttregados y aprobados.

-Documentar la aceptación del sistema.

-Finalizar y archivar los productos de soporte de prueba, el entorno de prueba y

la infraestructura de prueba para un uso posterior.

-Analizar las lecciones aprendidas para futuros proyectos.

-Utilizar la información recopilada para mejorar la madurez del proceso de

prueba.

Devs

-Implementa requisitos

-Desarrolla estructuras

-Diseña y programa el software

-Su éxito consiste en la creación del producto.

La actividad de un dev es Constructiva

QA

-Planifica actividades de prueba.

-diseña casos de prueba.

-Su única preocupación es encontrar defectos.

-Encontrar errores producidos por el dev es su éxito.

Las pruebas son constructivas para eliminar defectos

Características de un probador.

- Curioso, perceptivo, atento a los detalles. Objetivo es comprender los escenarios prácticos del cliente, analizar la estructura de prueba, descubrir detalles donde están los fallos.

-Escéptico y con actitud crítica. Los objetos de pruebas tienen defectos, solo hay que encontrarlos, no creer todo lo dicho por los devs, un defecto deimportancia puede tener impacto en la evolución del proyecto.

-Aptitudes para la comunicación. Para llevar malas noticias a los devs, hacer preguntas técnicas y prácticas sobre el uso del sistema. Evitar situaciones difíciles, establecer una relación de trabajo.

-Experiencia. Ayuda a identificar donde se pueda acumular los errores.

Pruebas independientes

La separación de responsabilidaddes en el proceso de prueba apoya-promueve la evaluación independiente de los resultados de las pruebas.

Importante: En lugar de equipos de desarrolladores utilice equipos de prueba o

equipo con personal externo para pruebas.

1.Pruebas de desarrollador (devs):

-No analizarán su creación de forma parcial.

-Él conoce el objeto de prueba mejor que nadie.

-Tienden a pasar por alto sus defectos.

-Riesgo de no reconocer defectos evidentes.

-Errores cometidos por la interpretación de los requisitos se mantendrán sin ser detectados.

-Pueden hacer un grupo de prueba donde los devs prueben los productos de otros.

2. Equipos de desarrollo(otros devs):

-Los devs hablan el mismo lenguaje.

-Peligro de generación de conflictos entre equipos de desarrollo (un dev que encuentra un defecto no será el mejor amigo del autor).

-Mezcla de actividades de devs y pruebas. Cambios en la forma de pensar, dificultad en el control de presupuesto del proyecto.

3. Equipos de prueba(QA):

-La creación de equipos de prueba que den servicio a diferentes areas de proyecto

mejoran la calidad de las pruebas.

-Importante que los equipos de prueba de diferentes areas en el proyecto trabajen de forma independiente.

4. Organización de pruebas (offshore)

-Subcontratación de pruebas (externalización): la separación de actividades de

prueba y desarrollo aportan máxima independencia entre los objetos de prueba y

el probador.

-Los expertos externos cuentan con alto nivel de conocimiento.

-Diseño de casos de prueba de forma automática.

Dificultades:

•Incapacidad de comprehensión mutua. Los devs deben contar con conocimiento básico

de las pruebas y los probadores con conocimiento básico del desarrollo.

•La detección de errores conduce a conflictos. La descripción del defecto

debe ayudar al dev a encontrar el defecto.

•La comunicación entre tester y dev es importante.

Código de ética

Asegura que la información es utilizada de forma apropiada.

•Público: el tester debe actuar conforme con el interés del cliente y empleador con el interés público.

•Cliente y empleador: El tester no debe filtrar a internet información interna o privada del cliente o empleador.

•Producto: los testers aseguran que los entregables que suministran alcazan los estándares altos profesionales.

•Juicio. Mantener integridad, juicio profesional.

•Gestión. Los gestores de prueba (lider) promueven un enfoque ético en la gestión de pruebas.

•Profesión: Los tester promueven integridad y reputación de la profesión.

•Compañeros de profesión: juntos, solidarios y cooperar.

•Individualmente: participar en procesos de formación.