Ejecución de Pruebas _ Pruebas de Software

7/26/2019 Ejecucin de Pruebas _ Pruebas de Software

1/3

15/6/2016 Ejecucin de Pruebas | PRUEBAS DE SOFTWARE

https://pruebasdelsoftware.wordpress.com/tag/ejecucion-de-pruebas/

PRUEBAS DE SOFTWARE

Ingenieria de Software con nfasis en pruebas.

Archivo de la etiqueta: Ejecucin de Pruebas

13 enero, 2013

Metodologa de Pruebas

Por Javier Zapata SnchezLos procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo querespecta a su componente analtico en pruebas estticas y dinmicas. La diferencia fundamental entreestos tipos de pruebas, radica en quelas pruebas estticas se centran en evaluar la calidad con la que seest generando la documentacin del proyecto, por medio de revisiones peridicas, mientras que laspruebas dinmicas, requieren de la ejecucin del software con el fin de medir el nivel de calidad con laque este fue codificado y el nivel de cumplimiento en relacin con la especificacin del sistema.

Realizar pruebas dinmicas a un producto de software, suele en la mayora de los casos confundirse conuna simple actividad de ejecucin de pruebas y reporte de incidencias, sin embargo, para productos decomplejidad media en adelante, lo recomendable es implementar de manera formal una metodologa dpruebas que se ajuste y acople uniformemente con la metodologa de desarrollo seleccionada por lafirma desarrolladora.

Paraprocesos de desarrollo basados en la metodologa RUP o mtodos tradicionales, implementar unametodologa de pruebas es totalmente viable, teniendo en cuenta que estas metodologas estnorientadas a la documentacin y a la formalizacin de todas las actividades ejecuta das. Si por elcontrario, la firma desarrolladora gua su proceso bajo lineamientos basados en metodologas giles,

ser necesario reevaluar la conveniencia de ejecutar todas las actividades que implica un proceso depruebas formal, lo que en la mayora de los casos, conlleva a reducir al mnimo las actividadesrelacionadas con un proceso de pruebas, circunstancia que naturalmente puede desencadenar en laliberacin de productos con bajos niveles de calidad.

Un proceso de pruebas formal, est compuesto, cuando menos por las siguientes 5 tpicas etapas:

1. Planeacin de pruebas.2. Diseo de pruebas.3. implementacin de pruebas.4. Evaluacin de criterios de salida.
https://pruebasdelsoftware.wordpress.com/author/javierzapatasanchez/https://pruebasdelsoftware.wordpress.com/2013/01/13/metodologia-de-pruebas/https://pruebasdelsoftware.wordpress.com/2013/01/13/metodologia-de-pruebas/https://pruebasdelsoftware.wordpress.com/https://pruebasdelsoftware.wordpress.com/https://pruebasdelsoftware.wordpress.com/https://pruebasdelsoftware.wordpress.com/https://pruebasdelsoftware.wordpress.com/https://pruebasdelsoftware.wordpress.com/author/javierzapatasanchez/https://pruebasdelsoftware.wordpress.com/2013/01/13/metodologia-de-pruebas/https://pruebasdelsoftware.wordpress.com/2013/01/13/metodologia-de-pruebas/https://pruebasdelsoftware.wordpress.com/


2/3



5. Cierre del proceso.

Planeacin de Pruebas.

Es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas y tiencomo resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuandomenos por aspectos tales como:

Alcance de la prueba: determina que funcionalidades del producto y/o software sern probadasdurante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con base a unanlisis de riesgos realizado de manera previa, que tienen en cuenta variables tales como el impactoque podra ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad.Producto de este anlisis, se cuenta con informacin adicional que permite determinar adems delalcance detallado del proceso de pruebas, la prioridad con la que las funcionalidades deben probarsy la profundidad de las pruebas.Tipos de Prueba: en este punto se debe determinar qu tipos de pruebas requerira el producto. Notodos los productos de software requieren la aplicacin de todos los tipos de pruebas que existen, poesta razn, es estrictamente necesario que el lder de pruebas se plantee preguntas que le permitandeterminar qu tipos de prueba son aplicables al proyecto en evaluacin. Los posibles tipos deprueba a aplicar son: pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebasfuncionales, pruebas de usabilidad, pruebas de regresin, entre otros.Estrategia de Pruebas:teniendo en cuenta que no es viable probar con base a todas las posiblescombinaciones de datos, es necesario determinar a travs de un anlisis de riesgos sobre quefuncionalidades debemos centrar nuestra atencin. Adicionalmente, una buena estrategia de pruebadebe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicarpara cada nivel de pruebas definido. En este punto tambin es importante definir los criterios deentrada y salida para cada ciclo de pruebas a ejecutar.Criterios de Salida:entre las partes involucradas en el proceso, se define de manera formal, bajo qucondiciones se puede considerar que una actividad de pruebas fue finalizada. Los criterios de salid

se deben definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de salida quepueden ser utilizados son: porcentaje de funcionalidades de alto riesgo probadas con xito, nmerodefectos crticos y/o mayores aceptados, etc.Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una estimacin dtiempos, los roles y/o recursos que harn parte del proceso, la preparacin del entorno de pruebas,cronograma base, etc.

Diseo de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciael anlisis de toda la documentacin existente con respecto al sistema, con el objeto de iniciar el diseode los casos de prueba. Los entregables claves para iniciar este diseo pueden ser: casos de uso,

historias de usuario, arquitectura del sistema, diseos, manuales de usuario (si existen), manualestcnicos (si existen). El diseo de los casos, debe considerar la elaboracin de casos positivos ynegativos. Los casos de prueba negativos permiten validar cmo se comporta el sistema ante situacioneatpicas y permite verificar la robustez del sistema, atributo que constituye unos de los requerimientosno funcionales indispensable para cualquier software. Por ltimo, es necesario definir cules son losdatos de prueba necesarios para la ejecucin de los casos de prueba diseados.

Implementacin y Ejecucin de Pruebas: la ejecucin de pruebas debe iniciar con la creacin de losdatos de prueba necesarios para ejecutar los casos de prueba diseados. La ejecucin de estos casos,puede realizarse de manera manual o automatizada; en cualquiera de los casos, cuando se detecte unfallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestionar


3/3



los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la firma desarrolladora en surespectivo proceso de depuracin, es necesario realizar un retest que permita confirmar que el defectofue solucionado de manera exitosa. Por ltimo, es indispensable ejecutar un ciclo de regresin que nospermita garantizar, que los defectos corregidos en el proceso de depuracin de la firma, no hayandesencadenado otros tipos de defectos en el sistema.

Evaluacin de Criterios de Salida: los criterios de salida son necesarios para determinar si es posible dapor finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de mtricas que permitir

al finalizar un proceso de pruebas, comparar los resultados obtenidos contra las mtricas definidas, s loresultados obtenidos no superan la mtricas definidas, no es posible continuar con el siguiente ciclo depruebas.

Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar: cubrimiento defuncionalidades en general, cubrimiento de funcionalidades crticas para el sistema, Nmero dedefectos crticos y mayores detectados, etc. Tambin es importante aclarar que el proceso de pruebaspuede ser suspendido y/o paralizado, debido entre otros, a aspectos relacionados con el presupuesto y lcalidad mnima del sistema requerida para el inicio formal de pruebas.

Cierre del proceso: durante este periodo de cierre el cual histricamente se ha comprobado que se ledestina muy poco tiempo en la planeacin, se deben cerrar las incidencias reportadas, se debe verificarsi los entregables planeados han sido entregados y aprobados, se deben finalizar y aprobar losdocumentos de soporte de prueba, analizar las lecciones aprendidas para aplicar en futuros proyectos,etc.

4 comentarios | Etiquetas: Criterios de Salida, Diseo de Pruebas, Ejecucin de Pruebas,Implementacin de Pruebas, Metodologa de Pruebas, Planeacin de Pruebas, Pruebas, Pruebas del

Software | Publicado en Introduccin a las Pruebas., Planeacin de Pruebas

Suscribirse al RSSBlog de WordPress.com. El Tema Elegant Grunge.
https://wordpress.com/themes/elegant-grunge/https://wordpress.com/?ref=footer_bloghttps://pruebasdelsoftware.wordpress.com/feed/https://pruebasdelsoftware.wordpress.com/category/planeacion-de-pruebas/https://pruebasdelsoftware.wordpress.com/category/introduccion-a-las-pruebas/https://pruebasdelsoftware.wordpress.com/tag/pruebas-del-software/https://pruebasdelsoftware.wordpress.com/tag/pruebas/https://pruebasdelsoftware.wordpress.com/tag/planeacion-de-pruebas/https://pruebasdelsoftware.wordpress.com/tag/metodologia-de-pruebas/https://pruebasdelsoftware.wordpress.com/tag/implementacion-de-pruebas/https://pruebasdelsoftware.wordpress.com/tag/ejecucion-de-pruebas/https://pruebasdelsoftware.wordpress.com/tag/diseno-de-pruebas/https://pruebasdelsoftware.wordpress.com/tag/criterios-de-salida/https://pruebasdelsoftware.wordpress.com/2013/01/13/metodologia-de-pruebas/#comments

Ejecución de Pruebas _ Pruebas de Software

Documents

Transcript of Ejecución de Pruebas _ Pruebas de Software