Page 1

Patricia Coronel

Software Quality Control Manager ISTQB Certified Software Tester


Las actividades dentro del proceso fundamental de pruebas se dividen en: Planificación y Control Análisis y Diseño Implementación y Ejecución Evaluación de los criterios de Salida y Reporte Actividades del cierre de las pruebas


Planificaci贸n


Planificación Determinar el alcance y los riesgos: •Software, componente, sistema u otro producto que se probará •Negocio, Producto, Proyecto y Riesgo técnico que debe tratarse

Identificar los objetivos de las pruebas •Prevenir defectos •Verificar que el software cumple con los requerimientos •Demostrar que el sistema cumple con el propósito •Medir la calidad y los atributos del software


Planificación

Determinar el enfoque: •Cómo se ejecutarán las pruebas •Técnicas que se utilizarán •Qué se probará y cuán extensamente. •Quiénes y cuando

Implementar la política o estrategia de las pruebas Si existe una política o estrategia de pruebas debemos: •Asegurar que planeamos adherir a ellas •Acordar y documentar con el cliente o interesado cuando no adheriremos a ellas


Planificación Determinar la cantidad de recursos necesarios: •Gente •Entorno de Pruebas •Computadoras •Software

Establecer fechas •Análisis de las pruebas •Tareas de Diseño •Implementación de las pruebas •Ejecución y Evaluación


Planificación Determinar los criterios de entrada: • Los tests unitarios del área de desarrollo han sido ejecutados y sus resultados documentados y aprobados. Entre dichos resultados no hay bugs bloqueantes o de alta prioridad que invaliden las pruebas de software desde un comienzo. • El Entorno de Testing está listo y estable (para comprobar su estabilidad se debe correr un Smoke test)


Planificación Determinar los criterios de entrada: • Las herramientas y la información necesaria para la ejecución del testing se encuentran instaladas y funcionando correctamente. • Todos los documentos de test se encuentran actualizados y aprobados: STP, Casos de Prueba. • El equipo de testing necesario para la ejecución de las pruebas ya se encuentra asignado y listo para dar comienzo con las tareas.


Planificación Determinar los criterios de salida: •

Todos los casos de prueba diseñados han sido ejecutados en forma exitosa o cancelados.

Se ha ejecutado y finalizado el test de regresión.

Todas las pruebas de aceptación se han ejecutado sin errores, en forma exitosa y cuentan con la aprobación correspondiente.


Planificación Determinar los criterios de salida: •

No existen bugs bloqueantes o de alta criticidad. Los bugs de mediana criticidad no superan un nro. de X y los de menor criticidad no superan un total de X.

•

Todos los documentos de testing se encuentran actualizados, revisados y aprobados.


Control


Control Medir y analizar los resultados de las pruebas: •Cuantas pruebas pasaron y cuantas fallaron. •Cantidad, tipo e importancia de los errores detectados.

Monitorear y documentar el progreso, cobertura de las pruebas y criterios de salida: •Cuantas pruebas se completaron •Cuales fueron los resultados •Conclusiones •Evaluación de riesgos que se llevaron a cabo.


Control

Proveer información de las pruebas: • Reportes al Project Manager, Sponsor, Cliente y demás interesados que ayuden a tomar decisiones informadas sobre el estado del proyecto. • Cantidad, tipo e importancia de los errores detectados.

Iniciar acciones correctivas: • Ajustar los criterios de salida para los defectos reparados. • Enfocar los esfuerzos en el debugging • Prioritizar los defectos para solucionar los bloqueantes en primera instancia.


Control Tomar decisiones: • Continuar o detener las pruebas • Poner el software en producción • Continuar con el desarrollo.


Análisis y Diseño Revisar la base de las pruebas: • Análisis de riesgo del producto • Requerimientos • Arquitectura • Especificaciones de diseño • Interfaces • Utilizar estas bases para comenzar con el diseño de ciertos tipos de casos de prueba: casos de caja negra.


Análisis y Diseño Identificar las condiciones de las pruebas • Brinda una lista a alto nivel de lo que interesa probar. • Usar las técnicas de prueba para definir la condición de las pruebas

Diseñar los casos de prueba • Utilizar la técnica para seleccionar casos de prueba del software que representen un riesgo o interés particular.


Análisis y Diseño Evaluar si los requerimientos y el sistema se pueden probar. • Verificar que los requerimientos estén escritos de tal forma que se puedan diseñar los casos de prueba

Diseñar la instalación del entorno de pruebas • Planificar como se instalará todo el entorno de pruebas


Análisis y Diseño Identificar las necesidades de infraestructura y herramientas. • Herramientas para las pruebas • Herramientas de soporte:  Hojas de calculo  Procesadores de texto  Herramientas de planificación de proyecto.


Implementaci贸n


Implementación

Desarrollar y establecer prioridad en los casos de prueba • Crear los datos de prueba • Escribir las instrucciones de las pruebas: Procedimientos de prueba

Crear una “suite” de pruebas para una ejecución eficiente • Una test suite es una colección lógica de casos de prueba que trabajan en conjunto • Con frecuencia comparten datos y un conjunto de objetivos a alto nivel.


Implementación Implementar y Verificar el entorno • Asegurar que el entorno de pruebas se ha instalado correctamente • Correr algunas pruebas para la verificación


Ejecuci贸n


Ejecución Ejecutar la suite de pruebas y los casos de prueba individual. • Seguir los procedimientos de prueba. • La ejecución puede ser manual o automatizada.

Grabar los resultados de la ejecución de las pruebas. • Registrar la versión del software que se probó. • Herramientas de prueba utilizadas. • Infraestructura


Ejecución Comparar los resultados actuales con los esperados. • Resultado actual: resultado obtenido luego de la ejecución de la prueba. • Resultado esperado: resultado anticipado de lo que debía suceder.

Reportar las discrepancias como incidentes. • Reunir detalles del defecto • Reportar información adicional del problema • Identificar las causas del defecto


Ejecución Repetir las actividades de prueba como resultado de acción tomado para cada discrepancia • Re ejecutar las pruebas que fallaron para confirmar su solución: Confirmation testing o Re-Testing • Re ejecutar las pruebas luego del Confirmation testing y verificar que no se introdujeron nuevas fallas luego de la solución de los anteriores. Regression testing


Evaluación de los criterios de salida y Reporte Revisar los resultados de las pruebas contra los criterios de salida especificados en el plan de test. • Evaluar la evidencia que se tiene de las pruebas que se ejecutaron, fallas reportadas, solucionadas o pendientes y confirmar si se completaron los criterios de salida para dar final a las pruebas.


Evaluación de los criterios de salida y Reporte Evaluar si se necesitan mas pruebas o si el criterio de salida debería cambiarse. • Ejecutar mas pruebas si no se ejecutaron todos los casos de prueba diseñados • Continuar con la ejecución de las pruebas si no se alcanzó la cobertura esperada. • Diseñar y ejecutar nuevas pruebas si han surgido nuevos riesgos en el producto.


Evaluaciรณn de los criterios de salida y Reporte Escribir un reporte con los resultados de las pruebas para todos los interesados. โ€ข Todos los interesados necesitan saber que se ha probado, resultados de la ejecuciรณn para poder tomar decisiones informadas acerca del producto.


Actividades del cierre de las Pruebas Revisar que entregables se entregaron actualmente. • Verificar que las pruebas y documentación acordadas se han entregado según lo definido en el plan de pruebas

Asegurar que todos los reportes de incidentes han sido resueltos. • Si existen reportes de fallas aun sin cerrar, errores sin resolver, documentar los mismos y solicitar el cambio en futuras releases


Actividades del cierre de las Pruebas Finalizar y archivar toda la infraestructura de las pruebas. • Scripts • Entorno de pruebas • Reutilizar lo que se pueda de ellos ya que se ahorra tiempo y esfuerzo, sobre todo en la etapa de mantenimiento del producto.

Entregar toda la infraestructura de las pruebas a la organización de mantenimiento. • Permite la re utilización de la infraestructura en pruebas del tipo Confirmation o Regression


Actividades del cierre de las Pruebas

Analizar las lecciones aprendidas para futuras releases y proyectos. • Mejoras a los procesos del ciclo de desarrollo de software como un todo, incluyendo al ciclo de pruebas. • Utilizar el resultado de las pruebas para fijar puntos de mejora en las revisiones . • Ejecutar las pruebas con el objetivo de oro de reducir las fallas del producto una vez puesto en producción. • Verificar dónde hubo problemas y el número de fallas, con el objetivo de mejorar el diseño, la ejecución y revisión de nuestras pruebas. • Documentar las lecciones aprendidas


Muchas Gracias a todos por su presencia y participaci贸n!


Huddle Group S.A. Enterprise Technologies | Products & Services info@huddle.com.ar · www.huddle.com.ar Buenos Aires Pasaje Carabelas 344 · 5th and 7th Floor · C1009AAD Buenos Aires · Argentina Tel.Fax.: (54.11) 5648.1300 Bahía Blanca Donado 74· 3rd Florr · B8000IYB · Bahía Blanca Buenos Aires · Argentina Tel.Fax.: (54.0291) 400.7070

Proceso Fundamental de las Pruebas de Software  

Presentacion que describe las diferentes etapas que componen el proceso de Testing de Software

Proceso Fundamental de las Pruebas de Software  

Presentacion que describe las diferentes etapas que componen el proceso de Testing de Software

Advertisement