Testing de Software - Fundamentos y Procesos

Testing de Software
Abril 2012
Cátedra: Proyecto
Profesor: Mario Bressano
Universidad Tecnológica Nacional - FRRO

Confidential // Neoris 2
Agenda
Lunes 9 de Abril
Testing
Fundamentos del Testing
Proceso Fundamental de Testing
Modelo de Desarrollo de Software: Modelo V
Niveles de Prueba
Tipos de Prueba
Martes 10 de Abril
Conceptos Teóricos finalización
En 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:

Planificación y Control
Planificación
y Control
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ño
Revisió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
Reportes
Evaluar 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 Prueba
El 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
software
La 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

Testing de Componentes
Testing de
Componentes
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.

Testing de Integración
Testing de
Componentes
Testing de
Integración
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.

Testing de
Componentes
Testing de
Integración
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, que
deben codificarse.
El programa, como entidad, sólo
aparece cuando se agrega el último
mó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
Componentes
Testing de
Integración
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ón
Tiene que ver con el comportamiento de todo un sistema/producto, definida
por el alcance de un proyecto de desarrollo o programa.

Testing de Aceptación
Testing de
Componentes
Testing de
Integración
Testing del
Sistema
Testing de
Aceptación
Definició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
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 Funcional
Testing No Funcional: carga, stress, volumen, etc.
Testing Estructural: caja blanca
Testing Relacionado a Cambios: confirmacion/regresión.
Pruebas en el Mantenimiento.

Preguntas?

Martes 10 de Abril
 Diseño de Pruebas
 Técnicas
 Caja Negra
 Caja Blanca
 En la Práctica
 Ciclo de Vida y Testing
 Niveles de Prueba
 Servicios de Testing
 Consultoría de pruebas
 Automatización
 Herramientas
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 pruebas
Los métodos más utilizados son:
Particiones de equivalencias
Es 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 fronteras
Es 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.

Resumen
Caso 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
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
Ahorrar tiempo y costo en las pruebas,
mediante el diseño, construcción y
ejecución de pruebas automatizadas
Testing
Methodology

En la Practica - Ciclo de Vida
Análisis Diseño
Desarrollo
y Testing
Implementación
Propuesta

Testing a través del ciclo de desarrollo del software
Nivel de Testing Tipo de Testing Breve Descripción
Testing de Unidad
Testing de Unidad
Verifica 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.
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.
Consiste 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.
Testing de
Aceptación
Testing de Aceptación
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.
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.
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.
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 Pruebas
Proceso
El 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
procedimient
o 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ón
Selenium 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 de Software - Fundamentos y Procesos

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Testing de Software - Fundamentos y Procesos

Ähnlich wie Testing de Software - Fundamentos y Procesos (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Testing de Software - Fundamentos y Procesos

Hinweis der Redaktion