You are on page 1of 33

 MAMANI YANA, Franklin Ronald  RIVERA PIO, Russ Roy

 VILLANUEVA LAU,LEN, Bruce Stuard

El objetivo del tema es lograr un entendimiento general del porque establecer un proceso de pruebas y los principales aspectos para establecerlo y mantenerlo. Los fundamentos del testing comprende en analizar los elementos clave para ser un tester efectivo y como el testing le agrega valor al proceso de desarrollo de software. Para competir en el mercado actual en donde un defecto en nuestras aplicaciones informáticas se traducen en pérdidas de clientes, y por consiguiente de dinero, es esencial conocer los altos estándares de calidad, funcionalidad y usabilidad del software .

ÍNDICE DE CONTENIDOS .

1 ¿QUÉ ES CALIDAD? .1.

y cumplir con las especificaciones con la que fue diseñado. .Es la totalidad de los rasgos y características de un producto o servicio que se sustenta en su habilidad para satisfacer las necesidades y expectativas del cliente.

producto.Grado en que un conjunto de características inherentes cumple con los requisitos ISO 9000: 2000 El grado en que un sistema.12 ISO 8402 . componente o proceso cumple (1) requerimientos especificados y (2) necesidades o expectativas del cliente o usuario. organización) que le confieren la aptitud para satisfacer las necesidades explícitas e implícitas de sus clientes IEEE 610. persona. Totalidad de características de una entidad (actividad.

confiabilidad.Calidad Cumplir requerimientos Propiedades (facilidad de mantenimiento. rendimiento.) Producto libre de defectos Actitud para el uso genera valor agregado . etc.

pruebas ejecutadas y cobertura lograda con las pruebas. La calidad se puede medir a través de características funcionales (ejemplo: imprimir un reporte correctamente) y no funcionales (ejemplo. impresión rápida del reporte) cubiertas por el software (ISO 9126).Las pruebas ayudan a medir la calidad del software en términos de: cantidad de defectos encontrados. .

. Se realizarán distintos tipos de pruebas con el objeto de medir cada tipo de atributo.Algunos atributos de la calidad de un producto software se influyen mutuamente.

La calidad de un proceso contribuye a la calidad de un producto. . La calidad de un producto contribuye a la calidad en uso del producto.

1.2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? .

” IEEE Estándar Glossary of Software Enginerineering Terminology “Las pruebas muestran la presencia de errores pero nunca la ausencia de ellos” . observando o registrando los resultados.Conceptos Generales de Pruebas ¿Qué son las Pruebas? “El proceso de operar un sistema o un componente bajo condiciones especificadas. y de hacer una evaluación de un cierto aspecto del sistema o del componente.

Otras Definiciones • Verificar. • Fallo. La definición Correcta •Probar es el proceso ejecución de un programa con el fin de encontrar errores. • Caso de Prueba. . •El propósito de probar es mostrar que el programa realiza correctamente las funciones esperadas.1.2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? ¿Qué es probar software? Algunas definiciones incorrectas: •Probar es demostrar que no hay errores presentes en un programa. • Pruebas. • Validar. • Defecto. • Error.

defecto y fallo .Relación entre error.

interfaces electrónicas.) para probar su funcionamiento conjunto . . etc. elementos mecánicos. seguridad.  Prueba de aceptación: el producto final se comprueba por el usuario final en su propio entorno de explotación para determinar si lo acepta como está o no.  Prueba funcional o de integración: el software totalmente ensamblado se prueba como un conjunto. etc.El proceso de prueba  Pruebas de unidad: se prueba cada módulo individualmente. para comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimiento.  Prueba del sistema: el software ya validado se integra con el resto del sistema (por ejemplo.

y lógica de módulo Código Pruebas de unidad . de requisitos VERIFICACIÓN Pruebas de sistema Diseño modular Pruebas de integración Especific.El proceso de prueba Requisitos de usuario VALIDACIÓN Pruebas de aceptación Especificac.

Diseño de casos de Prueba 1. PRUEBAS DE CAJA BLANCA Conociendo el funcionamiento del producto. PRUEBAS DE CAJA NEGRA Conociendo la función para la que fue diseñado. que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado adecuadamente. se desarrollan pruebas que aseguren “que todas las piezas encajan”. Examen minucioso de detalles procedimentales 2. se hacen pruebas que demuestren que cada función es operativa y al mismo tiempo se buscan errorres en cada una. Pruebas sobre la interfaz del software Caja blanca Entrada Salida Caja negra Entrada Funciones Salida .

Flujo de Información de la Prueba Informe de la prueba Casos de prueba Datos de prueba Resultado de la prueba Diseñar los casos de prueba Preparar los datos de prueba Ejecutar el programa con los datos de prueba Comparar los resultados con los casos de prueba Especificación del programa .

 Pruebas de Arquitectura Cliente/Servidor.Otras Pruebas  Pruebas de GUI (Interfaces  Pruebas de Documentación Gráficas de Usuario). Servidor . y Ayudas.

Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como referencia para el desarrollo de casos de prueba.1.2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE?  DEFINICIONES: TEST CASE / TEST BASE Test Case (Caso de Prueba) La definición de un caso de prueba incluye la siguiente información : • • • • Test Base o Test Basis (Fundamentos de pruebas)  • Precondiciones Conjunto de valores de entrada Conjunto de resultados esperados Forma en la cual se debe ejecutar el caso de prueba y verificación de resultados. . Postcondiciones.

. • Software Development (Desarrollo de Software) Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un computador (ordenador).1.2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? • DEFINICIONES: CODE/ DEBUGGING/ SOFTWARE DEVELOPMENT • Code o Source Code (código fuente) Programa de computadora escrito en un lenguaje de programación que puede ser leído por una persona. • Debugging (Depuración) Localización y corrección de defectos en el código fuente.

• Review (Revisión) Evaluación de un producto o estado de un proyecto con el objeto de detectar discrepancias con respecto a los resultados esperados (planificados) y para recomendar mejoras (lEEEStd 1028).2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? • DEFINICIONES: REQUIREMENT/ REVIEW • Requirement (Requisito) Un requisito describe un atributo funcional o no funcional deseado o considerado obligatorio. .1.

 Determinar que el producto de software cumple su propósito  Confirma que el producto.1. Confirmación.  Detectar Defectos  Para descubrir fallas o defectos en el software donde su comportamiento no está en conformidad con su especificación. En otras palabras validación asegura que “se construye el producto correcto”. En otras palabras verificación asegura que “se construye el producto correctamente”.2 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE?  OBJETIVOS DE LAS PRUEBAS  Determinar que el producto requerimientos especificados  software satisface los  Confirma que los productos trabajados apropiadamente reflejan los requerimientos especificados. como condición rutinaria. a través de la provisión de objetivos evidenciables. que los requerimientos especificados han sido cumplidos a cabalidad. cumplirá a cabalidad con su uso propuesto. .

3 PRINCIPIOS GENERALES DE LAS PRUEBAS .1.

 El mismo proceso de pruebas puede contener errores.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 1: LAS PRUEBAS MUESTRA LA PRESENCIA DE DEFECTOS  La prueba puede mostrar que los defectos están presentes.  La prueba reduce la probabilidad de existencia de defectos no descubiertos pero eso no demuestra su ausencia. pero no pueden probar que no existen defectos. incluso cuando los defectos no son encontrados.1. .

 Pruebas exhaustivas ("exhaustive testing”). utilizamos técnicas basadas en riesgos y prioridades para enfocar los esfuerzos de pruebas. Enfoque del proceso de pruebas en el cual el juego de pruebas abarca todas las combinaciones de valores de entrada y precondiciones. .1. En lugar de test exhaustivos.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 2: LA PRUEBA EXHAUSTIVA ES IMPOSIBLE  Probar todo (todas las combinaciones de entrada y precondiciones) no es factible excepto para casos triviales.

 Las actividades de pruebas deben comenzar tan pronto como sea posible en el ciclo de vida del desarrollo del software o sistema y deben ser enfocados sobre objetivos definidos.  El proceso de pruebas implica más que sólo la ejecución de pruebas.1.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 3: PROBAR LO MÁS TEMPRANAMENTE POSIBLE  La corrección de un defecto es menos costosa en la medida en la cual su detección se realiza en fases más tempranas del proceso software. .

Cuando se detecta un defecto es conveniente investigar el mismo módulo en el que ha sido detectado. o muestran la mayoría de los fallos operacionales.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 4: AGRUPAMIENTO DE DEFECTOS  Un número pequeño de módulos contienen la mayoría de los defectos descubiertos durante la prueba.    ¡Encuentre un defecto y encontrará más defectos "cerca"! Los defectos aparecen agrupados. .1.

Para vencer esta “paradoja del pesticida”. y se necesitan escribir nuevos casos de prueba para ejercitar diferentes partes del software o sistema para encontrar mas defectos potenciales. los casos de prueba necesitan ser regularmente revisados y estudiados.  Repetir pruebas en las mismas condiciones no es efectivo.1. eventualmente el mismo grupo de casos de prueba ya no encontrará nuevos errores.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 5: LA PARADOJA DEL PESTICIDA  Si el mismo test se repite una y otra vez. .  Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos (código).

entorno de producción. el software de seguridad crítico se prueba de forma diferente a la de un sitio de comercio electrónico.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 6: LA PRUEBA DEPENDE DEL CONTEXTO  La prueba se realiza de manera diferente en diferentes contextos. Estas diferencias introducen incertidumbre con respecto a las conclusiones que se pudieran obtener tras las pruebas. .   Las pruebas tienen lugar en un entorno distinto del entorno de producción. Siempre habrá diferencias entre el entorno de pruebas y el entorno de producción. Por ejemplo.1.  Entorno de pruebas vs. El entorno de pruebas debe ser similar entorno de producción.

1. ella tiene que construirse desde el principio.3 PRINCIPIOS GENERALES DE LAS PRUEBAS  PRINCIPIO 7: LA FALACIA DE LA AUSENCIA DE ERRORES  Encontrar y solventar defectos no ayuda si el sistema construido está inutilizado y no satisface las necesidades y expectativas de los usuarios. .  No se puede introducir la calidad a través de las pruebas.