testing-120413131346-phpapp02

Testing de Software

Abril 2012

Cátedra: ProyectoProfesor: Mario BressanoUniversidad Tecnológica Nacional - FRRO

Confidential // Neoris 2

Agenda

Lunes 9 de AbrilTestingFundamentos del TestingProceso Fundamental de TestingModelo de Desarrollo de Software: Modelo VNiveles de PruebaTipos de Prueba

Martes 10 de AbrilConceptos Teóricos finalizaciónEn la Practica


¿Testing?


Pruebas de Software - Testing

Las pruebas de software, en inglés “Testing” son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

“El testing puede probar la presencia de errores pero no la ausencia de ellos”. Edsger Wybe Dijkstra

Definición


¿Por qué es necesario el Testing?


Fundamentos del Testing

La importancia económica del software

Calidad del Software

Pruebas para la mejora de la calidad

El funcionamiento de maquinaria y equipamiento depende en gran medida del software.No es posible imaginar grandes sistemas, en el ámbito de las finanzas ni el control del tráfico automotor, entre otros, funcionando sin software.

Cada vez más, la calidad software se ha convertido en un factor determinante del éxito de sistemas y productos técnicos o comerciales.

Las pruebas y revisiones aseguran la mejora de la calidad de productos de software así como de la calidad del proceso de desarrollo en sí.


Terminología


Error Defecto Falla


Definición

Error

Acción humana que produce un resultado incorrecto. Ej. Un error de programación.

Defecto

Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas. Ej: una sentencia o una definición de datos incorrecta.

Falla

Manifestación física o funcional de un defecto. Si un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo.Desvío de un componente o sistema respecto del resultado esperado.



Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas del usuario/cliente.

Calidad


Calidad de Software

Atributos funcionales de calidad:

Funcionalidad: correctitud y completitud de los requisitos del usuario.

Atributos NO funcionales de calidad:

Fiabilidad: el sistema mantendrá su capacidad y funcionalidad a lo largo de un período de tiempo.

Usabilidad: fácil de usar, fácil de aprender, conforme a normas y uso intuitivo.

Portabilidad: fácil de instalar y desinstalar, y configurar parámetros.


¿Cuánto Testing es necesario?



El testing exhaustivo es imposible.

Testear todas las combinaciones de entradas y precondiciones no es factible.

Para enfocar el testing nos debemos basar en Riesgos y Prioridades.


¿Qué es testing?


Consiste solamente en realizar pruebas.

Es ejecutar la aplicación.

Percepción común

Es fácil y cualquiera lo puede hacer.


Las actividades de la prueba existen antes y después de la ejecución de la prueba.

Puede haber diferentes objetivos de prueba:

Realidad

Encontrar defectos. Ganar confianza sobre el nivel de calidad y proporcionar información. Prevenir defectos


Proceso Fundamental de Testing

El proceso fundamental del Testing

Planificación y Control

Análisis y Diseño

Aplicación y Ejecución

Evaluación de los criterios de salida y Reportes

Actividades de cierre de

Pruebas

El proceso de prueba fundamental consiste de las siguientes actividades principales:




Determinar el alcance y los riesgos, e identificar los objetivos de la prueba.

Implementar la estrategia de prueba.

Programar los análisis de prueba y las tareas de diseño.

Nos aseguramos de haber entendido las metas y objetivos del cliente, el proyecto y los riesgos de las tareas de testing.


Análisis y Diseño

Análisis y DiseñoRevisión de los elementos básicos para las

pruebas (tales como los requerimientos, arquitectura de la aplicación, diseño, interfaces).

Identificar y priorizar las condiciones de las pruebas y datos de pruebas basado en el análisis anterior.

Actividad donde los objetivos generales de las pruebas se transforman en condiciones de prueba tangibles y casos de prueba.

Puesta a punto del entorno de pruebas y se determinan las herramientas necesarias


Ejecución

Aplicación y Ejecución

Evaluación de los criterios de salida

y Reportes

Ejecutar las pruebas.

Registrar resultados, Comparar e Informar.

Repetir las pruebas.


Implementación y ejecución de prueba La implementación y ejecución de prueba tienen las siguientes tareas principales:

Ejecutar los casos de prueba ya sea manualmente o mediante el uso de herramientas de ejecución de prueba, de acuerdo con la secuencia planeada.

Registrar el resultado de la ejecución de prueba y la versión del software bajo prueba, en una herramientas de prueba.

Comparar los resultados reales con los resultados esperados.

Informar discrepancias como incidentes.

Repetir las actividades de prueba después de las correcciones. Por ejemplo, la re-ejecución de una prueba que falló previamente para confirmar un arreglo (pruebas de confirmación), ejecución de pruebas para asegurarse que los defectos no han sido introducidos en áreas no cambiadas del software o que el arreglo del defecto no reveló otros defectos (pruebas de regresión).


Evaluación de los criterios de salida y ReportesEvaluar los criterios de salida es la actividad donde la ejecución de prueba es evaluada contra los objetivos definidos. Esto debe hacerse para cada nivel de prueba.

Evaluar los criterios de prueba tiene las siguientes tareas principales: Comparar los registros de prueba contra los criterios de salida especificados en la

planificación de prueba.

Evaluar si se necesitan más pruebas.

Escribir un reporte de resumen de prueba para las partes interesadas.


Actividades de cierre de Pruebas

Actividades de cierre de

Pruebas

Se recolecta la información de las actividades de prueba completadas para consolidar.

Verificar el entregable y que los defectos hayan sido corregidos.

Archivar todo el material generado en las pruebas para un futuro uso.

Evaluar como resultaron las actividades de testing y analizar las lecciones aprendidas.


Psicología de PruebaEl modo de pensar a ser usado mientras se prueba y revisa es diferente al usado mientras se analiza o desarrolla.

La separación de esta responsabilidad hacia un probador es realizada típicamente para ayudar a enfocar el esfuerzo y para proporcionar beneficios adicionales, tales como una visión independiente.

Varios niveles de independencia pueden ser definidos:

Pruebas diseñadas por la(s) persona(s) que escribió (escribieron) el software bajo prueba.

Pruebas diseñadas por otra(s) persona(s) del equipo de desarrollo. (bajo nivel de independencia).

Pruebas diseñadas por una(s) persona(s) de un grupo organizacional diferente (por ejemplo, un grupo de prueba independiente.

Pruebas diseñadas por una(s) persona(s) de una organización o compañía diferente (es decir subcontratación o certificación por un organismo externo).


Psicología de Prueba – continuación

Identificar fallas durante la prueba puede ser percibido como una crítica contra el producto y contra el autor. La prueba es, por lo tanto, a menudo vista como una actividad destructiva, aunque es muy constructiva en la gestión de riesgos del producto.

Buscar fallas en un sistema requiere curiosidad, pesimismo profesional, un ojo crítico, atención al detalle, buena comunicación con los pares de desarrollo y experiencia en que basar la conjetura de error.

Si los errores, defectos o fallas son comunicados en una forma constructiva, malos sentimientos entre los probadores y los analistas, diseñadores y desarrolladores pueden ser evitados.


Modelos de desarrollo de Software


Testing a través del ciclo de desarrollo del softwareLa prueba no existe en forma aislada; las actividades de prueba están relacionadas con las actividades de desarrollo de software. Los diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques hacia la prueba. Modelo-V Aunque existen variantes del Modelo-V, un tipo común de Modelo-V usa 4 niveles de prueba, correspondientes a 4 niveles de desarrollo. Los cuatro niveles usados en este programa son: Prueba de componente (unidad). Prueba de integración. Prueba de sistema. Prueba de aceptación.

En la práctica, un Modelo-V puede tener diferentes niveles de desarrollo y prueba, dependiendo del proyecto y del producto de software. Por ejemplo, puede existir prueba de integración de componentes después de las pruebas de componente y prueba de integración del sistema después de la prueba del sistema.


Modelo V

Diseño Funcional del Sistema

Diseño Técnico del Sistema

Especif. de Componentes

Definición de Requisitos Pruebas de Aceptación

Pruebas de Sistema

Pruebas de Integración

Pruebas de Componentes

Programación


Testing a través del ciclo de desarrollo del software

Niveles de Pruebas

Testing de Componentes

Testing de Integración

Testing del Sistema

Testing de Aceptación




Definición

Prueba de cada componente tras su realización/construcción

Los componentes son referidos como módulos, clases o unidades

También denominadas pruebas de Desarrollador (developer’s test)

Alcance

Cada componente es probado de forma independiente

Descubrir fallos producidos por defectos internos

Los casos de prueba tienen 3 fuentes: especificaciones de componente, diseño, modelo de datos.





Definición

Comprueba la interacción entre elementos de software (componentes) tras la integración del sistema.

Comprueban las funciones externas.

Pueden ser ejecutadas por desarrolladores, testers o

ambos.





Estrategias

Incremental

Descendente

Ascendente

Ad-Hoc

No Incremental


Estrategias – Tipos fundamentales de Integración Integración incremental. Se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya han sido probados.

Ascendente.

Se combinan los módulos de bajo nivel en grupos que realicen una función o subfunción específica (o quizás si no es necesario, individualmente) -> de este modo reducimos el número de pasos de integración.

Se escribe para cada grupo un módulo impulsor o conductor -> de este modo permitimos simular la llamada a los módulos, introducir datos de prueba y recolectamos resultados.

Se prueba cada grupo mediante su impulsor. Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel

superior en la jerarquía.


Estrategias – Tipos fundamentales de Integración

Integración incremental.

Descendente. Se comienza por el módulo raíz.

Comienza por el módulo de control principal y va incorporando módulos subordinados progresivamente.

No hay un orden adecuado de integración, pero se recomienda lo siguiente:Si hay secciones críticas (especialmente complejas) se deben integrar lo antes posible.El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de pruebas.

Integración NO incremental. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo.

Ad-hoc: Los componentes serán probados, si fuera posible, inmediatamente después de haber sido finalizada su construcción y se hayan finalizado las pruebas de componente.


COMPARACION DE LOS DISTINTOS TIPOS DE INTEGRACION PRUEBAS DEL SOFTWARE

Ventajas de la No incremental:

Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una sola vez la combinación de los módulos.

Existen más oportunidades de probar módulos en paralelo.

Ventajas de la incremental:

Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los módulos.

La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un paso de la integración hay que atribuirlo muy probablemente al último módulo incorporado.

Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco.


ASCENDENTES DESCENDENTES

VENTAJAS VENTAJAS

Es un método ventajoso si aparecen grandes fallos en la parte inferior del programa, ya que se prueba antes.La entradas para las pruebas son más módulos inferiores.Es más fácil observar los resultados de la prueba, ya que es en los módulos inferiores donde se elaboran los datos (los superiores suelen ser módulos de control).

Es ventajosa si aparecen grandes defectos en los niveles superiores del programa, ya que se prueban antes.Permite ver antes una estructura previa del programa, lo que facilita el hacer demostraciones.

DESVENTAJAS DESVENTAJAS

Se requieren módulos impulsores, quedeben codificarse.El programa, como entidad, sóloaparece cuando se agrega el últimomódulo.

Las entradas para las pruebas pueden ser difíciles o imposibles de crear, puesto que, a menudo, se carece de los módulos inferiores que proporcionan los detalles de operación.Es más difícil observar la salida, ya que los resultados surgen de los módulos inferiores.

INCREMENTAL


Testing de Sistema



Testing de Sistema

Enfoques para las pruebas funcionales:

Basadas en Requisitos.

Basadas en Procesos de Negocio.

Basadas en Casos de Uso.

Los casos de prueba se derivan de la especificación de requisitos.El número de casos de prueba variará en función del tipo/profundidad de las pruebas basadas en la especificación de requisitos.

Cada proceso de negocio sirve como fuente para derivar/generar pruebas.El orden de relevancia de los procesos de negocio puede ser aplicado para asignar prioridades a los casos de prueba.

Los casos de prueba se derivan/generan a partir de las secuencias de usos esperados o razonables.Las secuencias utilizadas con mayor frecuencia reciben una prioridad más alta.

DefiniciónTiene que ver con el comportamiento de todo un sistema/producto, definida por el alcance de un proyecto de desarrollo o programa.





Testing del Sistema

Testing de AceptaciónDefinición

Pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los requisitos.

El Objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.


Tipos de Pruebas

Testing relacionado a cambios

Testing Estructural

Tipos de pruebas: Objetivos del proceso de Pruebas

Testing Funcional

Testing No Funcional


Tipos de Pruebas – Testing Funcional

Testing Funcional

Objetivo: La función del objeto de prueba.Las funciones, que un sistema, un subsistema o un componente realizará, pueden estar descritas en productos de trabajo tales como una especificación de requisitos, casos de uso o una especificación funcional, o podrían estar no documentados. Las funciones son “lo que” el sistema hace.

Las pruebas funcionales consideran el comportamiento externo del software (pruebas de caja negra).

Se pueden llevar a cabo en todos los niveles de pruebas


Tipos de Pruebas – Testing No Funcional

Testing No Funcional

Pruebas de Performance

Pruebas de Volumen

Pruebas de Concurrencia

Objetivo: La finalidad de la prueba es saber “como” funciona el sistema.

El termino pruebas no funcionales describe las pruebas necesarias para medir las características de los sistemas y software que se puede cuantificar en una escala variable, tales como tiempos de respuesta para las pruebas de rendimiento.


Tipos de Pruebas – Testing Estructural

Testing Estructural

Objetivo: La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba.Las pruebas estructurales (de caja blanca) pueden ser realizadas en todos los niveles de prueba, pero sobre todo en las pruebas de componentes (unit testing) y las pruebas de integración de componentes.

Las técnicas estructuradas son las mejores usadas después de las técnicas basadas en especificaciones.


Tipos de Pruebas – Testing relacionado a cambios

Testing de confirmación/regresión

Objetivo: Repetir una prueba de funcionalidad que ha sido verificada previamente.

Confirmación: Cuando un defecto es detectado y arreglado, entonces el software debe ser probado de nuevo para confirmar que el defecto original ha sido retirado

exitosamente.

Regresión: son las pruebas repetidas de un programa ya testeado, después de una modificación, para descubrir cualquier error introducido o no descubierto como resultado del cambio(s). Estos errores pueden ser ya sea en el software que se está testeando, o en otro componente del software relacionado o no. Se lleva a cabo cuando el software, o su entorno, sufren cambios. El alcance de las pruebas de regresión esta basado en el riesgo de no encontrar errores en el software que estaba funcionando anteriormente.


Pruebas de Mantenimiento

Las pruebas de mantenimiento se realizan en un sistema operativo existente, y es provocada por modificaciones, migración de datos, o la jubilación del software o sistema.

Las modificaciones incluyen cambios planificados, correctivos y cambios de emergencia, y cambios de ambiente, como el sistema operativo o base de datos prevista, actualizaciones o parches.

Además de verificar lo que se ha cambiado, las pruebas de mantenimiento incluyen extensivas pruebas de regresión a las partes del sistema que no han sido cambiadas.

La determinación de cómo el sistema actual puede verse afectado por los cambios se llama análisis de impacto, y es utilizado para ayudar a decidir la cantidad de pruebas de regresión a hacer.

Testing durante el mantenimiento


Recapitulación

Error, defecto y falla.Proceso fundamental de testing.Ciclo de desarrollo de software: modelo V.

Niveles de pruebas: • Componente. • Integración.

• Incremental (asc o desc), No Incremental, Ad hoc.• Sistema. • Aceptación.

Tipos de Pruebas (a través de los distintos niveles)Testing FuncionalTesting No Funcional: carga, stress, volumen, etc.Testing Estructural: caja blancaTesting Relacionado a Cambios: confirmacion/regresión.Pruebas en el Mantenimiento.


Preguntas?


Martes 10 de AbrilDiseño de Pruebas

TécnicasCaja NegraCaja Blanca

En la PrácticaCiclo de Vida y TestingNiveles de PruebaServicios de TestingConsultoría de pruebasAutomatizaciónHerramientas

Agenda


Diseño de Pruebas


Terminología


Caso de Prueba

Definición

Son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.

Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Debe haber al menos un caso de prueba para cada requisito.

Algunas metodologías como RUP recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa.

Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada. La entrada conocida debe probar una precondición y la salida esperada debe probar una postcondición.


Casos de Prueba - continuación

Objetivo

Descripción

Información general acerca de los Casos de Prueba:

Resultado Esperado

Creador

Versión

Identificador


Caso de Prueba - continuación

Objetivo: Es el fin que se quiere alcanzar y al cual se dirige la acción. El objetivo debe estar alineado con el resultado esperado.

Ejemplo:

• Verificar que el sistema solicita confirmación para la eliminación.

Descripción: los pasos que debe seguir el tester para realizar la prueba y alcanzar el objetivo expuesto.

Ejemplo:

• Realizar una búsqueda que arroje resultados, seleccionar un elemento de la lista y seleccionar la opción “Eliminar”.

Resultado Esperado: Es la respuesta que esperamos de la aplicación testeada luego de ejecutar los pasos detallados en la descripción con el fin de alcanzar el objetivo.

Ejemplo:

• El sistema muestra un mensaje de confirmación.


Técnicas de diseño de pruebas


Representación Gráfica

CAJA BLANCA

El tester observa el objeto de pruebas como una caja negra.

Los casos de prueba se obtienen a partir del análisis de la especificación de un componente o sistema.

La funcionalidad es el foco de la atención.

Se realiza sobre las funciones internas de un módulo.

Los casos de prueba son seleccionados en base a la estructura interna del programa/código.

La estructura del programa es el foco de la atención.

CAJA NEGRA


Técnicas de Caja Blanca


Caja Blanca

Utiliza la estructura de control de diseño procedural para derivar casos de

pruebas que:

Garanticen que todos los caminos independientes dentro de un módulo han sido ejercitados por lo menos una vez.

Ejerciten todas las decisiones lógicas en sus lados verdaderos y falsos.Ejerciten estructuras de datos internas para asegurar su validez.

Distintos Métodos:

Cobertura de Camino Básico

Cobertura de Condición

Cobertura de Bucles


Técnicas de caja negra


Técnicas de diseño de pruebasLos métodos más utilizados son: Particiones de equivalenciasEs un proceso sistemático que identifica un conjunto de clases de prueba representativas de un conjunto de pruebas posibles, la idea es que el producto se comportará de la misma manera para todos los miembros de una clase. Consta de los siguientes pasos:

1. Identificar las clases de equivalencias: Por ejemplo: (si un contador puede ir de 1 a 999). Entonces tendríamos:Clases Válidas: (1 <= contador <= 999). Clases Inválidas: (contador < 1), (contador > 999)

2. Identificar los casos de pruebas: asignar un nro. único a cada clase, diseñar casos de pruebas hasta cubrir todas las clases válidas y clases inválidas.

Análisis de valores fronterasEs una variante del particiones de equivalencias, se seleccionan los bordes de una clase. Por cada clase válida hay que definir pruebas para las fronteras. Por ejemplo: número entre 3 y 8, probar para 2, 3, 8 y 9.


ResumenCaso de Prueba: identificador, objetivo, descripción, resultado esperado,

etc.Técnicas

Caja Negra: Particiones de Equivalencias, Análisis de valores frontera.

Caja Blanca: Cobertura de camino Básico, de condición, de bucle.

Los métodos de caja negra y caja blanca son métodos dinámicos.

Solo se puede probar código existente.

Detecta el código muerto, pero no funciones faltantes.

Los métodos de caja blanca son utilizados en pruebas de bajo nivel como prueba de componente o pruebas de integración de componentes.


EN LA PRACTICA


Servicios de Testing

Permite evaluar y conocer los procesos y

actividades de testing que se realizan y

proponer una solución metodológica y

operativa de acuerdo a las oportunidades

identificadas.

Asegurar que el usuario final obtiene la

funcionalidad requerida a través de un

software bien construido

Pruebas Funcionales

Garantizar la máxima productividad del usuario final, evitando retrasos y otros impactos negativos en los negocios, a través de un buen tiempo de respuesta de las aplicaciones, validando su infraestructura y arquitectura

Automatización de Pruebas

Ahorrar tiempo y costo en las pruebas,

mediante el diseño, construcción y

ejecución de pruebas automatizadas

Pruebas de Stress

Testing Methodology

Consultoría de Testing


En la Practica - Ciclo de VidaAnálisis Diseño

Desarrolloy Testing

ImplementaciónPropuesta


Testing a través del ciclo de desarrollo del software

Nivel de Testing Tipo de Testing Breve Descripción

Testing de Unidad

Testing de UnidadVerifica que el código de cada componente trabaja de acuerdo a sus especificaciones y valida la lógica del programa. Se utiliza la estrategia de caja blanca


Testing de Integración de primer nivel

Verifica que las interfaces entre las componentes, entidades externas y la aplicación funcionan correctamente. Se pueden aplicar diferentes estrategias.

Testing de Integración de segundo nivel Verifica la integración funcional entre los diferentes casos de usos del sistema.

Testing de Sistema

Testing Funcional

Consiste en probar la funcionalidad del sistema, a partir de cumplir con los requerimientos, sin tener en cuenta la forma en cómo éste resuelve internamente las especificaciones. Se utiliza la estrategia de caja negra.

Testing No FuncionalConsiste en verificar el cumplimiento de los requerimientos no funcionales, por ejemplo: capacidad de instalación, usabilidad.

Testing de Regresión

Valida, ante un cambio en el sistema, que las partes del mismo, que no hayan cambiado continúen funcionando correctamente, luego de implementada la modificación. Se ejecutan casos de prueba seleccionados de entre los que se definieron para Testing Funcional y Testing No Funcional.



Valida el cumplimiento de los requerimientos a partir del punto de vista del usuario. Se ejecutan casos de prueba seleccionados de entre los que se definieron para Testing de Sistema.

Ejecutados por el Desarrollador

Ejecutados por el Tester

Ejecutado por el Cliente (opcional junto al tester)


Preparación del Testing – Actividades


Estimación del Testing

Tarea % tiempo insumido Detalle de Operaciones

Definición de casos 35% Lectura y análisis de documentación.Escritura de casos de Prueba.

Ejecución: 1er pasada 40% Ejecución de Casos de Prueba.Reporte de Errores.

Retesting 15% Reejecución de Casos.Actualización de Estados.

Otras tareas 10% Generación de Informes.Problemas con entornos.

Otros tiempos a tener en cuenta

Una vez que se tienen definidos los tiempos para los módulos, entran otras variables en juego, las cuales aumentan el volumen de horas:

• Distintos Navegadores y/o resoluciones de pantalla.• Cantidad de Idiomas.• Lugar donde se testea (Staging, Producción)

Consideraciones Generales


Comunicación durante las pruebas

El testing se realizará en base a la documentación recibida y cualquier diferencia entre la Aplicación y la documentación será considerada una falla y reportado como tal.

El testing se realizará en base a la documentación recibida y cualquier diferencia entre la Aplicación y la documentación será considerada una falla y reportado como tal.

Asignación de Incidencias en la Herramienta.

Corrección de Incidencias y Registro en la Herramienta.

Actualización del Entorno de Testing.

Aviso Formal de la Liberación del Módulo para el Re-testing.

Asignación de Incidencias en la Herramienta.

Corrección de Incidencias y Registro en la Herramienta.

Actualización del Entorno de Testing.

Aviso Formal de la Liberación del Módulo para el Re-testing.

Tareas a Realizar

Consideraciones a Tener en Cuenta

Aviso Formal de la liberación de un Módulo al entorno de Testing.Aviso Formal de la liberación de un Módulo al entorno de Testing.

Documentación de Entrada

BD

Ejecución de los Casos de Prueba y Registración de Incidencias en la Herramienta.

Aviso Formal de Fin de Testing del Módulo.

Ejecución del Re-testing, y pruebas de Regresión.

Elaboración de Informe Final.

Ejecución de los Casos de Prueba y Registración de Incidencias en la Herramienta.

Aviso Formal de Fin de Testing del Módulo.

Ejecución del Re-testing, y pruebas de Regresión.

Elaboración de Informe Final.

Salida Generada

BD


Consultoría de Testing

La consultoría consiste en conocer los procesos y actividades de testing que realiza la compañía internamente y/o a través de sus proveedores.

Y así poder detectar fortalezas y debilidades de dichos procesos y actividades.

Luego, en función de este trabajo, proponer una solución metodológica y operativa para mejorar las actividades de testing aplicables a los proyectos de software que lleve adelante la compañía.

Permite mejorar:• Gestión y mitigación de riesgos• Aplican mejores prácticas en la gestión de procesos de testing• Diseño y Mejoras en el proceso de Testing • Soporte de expertos de testing durante el período necesario• Trasferencia de conocimientos de testing a la organización


Automatización de PruebasProcesoEl proceso general de automatización comienza por la evaluación de factibilidad de automatizar

los casos de prueba, posterior confección del plan de automatización, desarrollo de los scripts y validaciones, y por último, la ejecución de los mismos y generación de reportes. Dado que no todos los casos de prueba definidos para una solución pueden automatizarse, este proceso transcurre como un subproceso de testing dentro del ciclo de proyecto.

Como Optimización de muchos proyectos: Tareas repetitivas Generación de datos Múltiples regresiones Errores que se repiten demasiado Workflows largos necesarios para llegar a la funcionalidad a testear

Repetitividad

Impacto en el negocio

Complejidad

Qué debería ser automatizado primero?Test core del negocio / Test del mismo caso con diferentes datos

Test ejecutados con mucha frecuencia


Herramientas utilizadas

QA Process Management permite a un usuario final realizar un procedimiento de Test sobre un Sistema

Team Foundation Server (TFS). Es un producto de Microsoft de control de versión, recolección de datos, informes y seguimiento de proyectos. V2008 y Beta 2010.


Herramientas Utilizadas


Comparación Herramientas AutomatizaciónSelenium 2 (Webdriver) QTP 11(última versión)

Open Source y gratuito. Herramienta paga, cada licencia cuesta 9000 mil dólares más 25% del costo por año en mantenimiento.

Funciona en todos los Sistemas Operativos. Funciona sólo en Windows.

Sólo para pruebas en aplicaciones Web. Pruebas en aplicaciones Web y Escritorio (Windows).

Funciona en todos los browsers. Funciona sólo con Firefox 3.5 e Internet Explorer (gran limitación para el testing Web).

Se codifica en cualquier lenguaje (C#, Java, Ruby, Python, PHP, Pearl, etc).

Sólo Visual Basic.

Record and Play no es 100% confiable, pero es útil (sólo se utiliza para quienes no sepan codificar y quieren automatizar).

Record and Play tiende a ser más sólido que en Selenium.

Selenium no se integra nativamente con QC, necesita algunas configuraciones, pero no de forma nativa. Existen múltiples formatos y herramientas de reporte que puede generar Selenium.

QTP se integra muy bien con Quality Center y TD.

Selenium tiene una gran comunidad online de soporte, pero no oficial. Hay empresas que cobran por dar soporte.

QTP tiene soporte telefónico, mail, y Web.


Preguntas?


A.U.S Gabriela Muñoz

MUCHAS GRACIAS!

testing-120413131346-phpapp02

Documents

Transcript of testing-120413131346-phpapp02