Diferencia entre revisiones de «Automatizacion De Pruebas De Aceptacion»

De Dos Ideas.
Saltar a: navegación, buscar
(Página nueva: ==Contexto== Un proyecto de desarrollo de software que pecisa mejorar la calidad y reducir el número de defectos. ==Problema== Mejorar la calidad de software como un todo y hacer ...)
 
 
(No se muestra una edición intermedia de otro usuario)
Línea 43: Línea 43:
  
 
==Ver también==
 
==Ver también==
[[HerramientasParaPruebasDeAceptacion]]
+
[[Herramientas Para Pruebas De Aceptacion]]
  
 
==Reconocimientos==
 
==Reconocimientos==
Línea 52: Línea 52:
 
* (MUGRIDGE e CUNNINGHAM, 2005)
 
* (MUGRIDGE e CUNNINGHAM, 2005)
 
* (TATE, 2005)
 
* (TATE, 2005)
 +
 +
[[Category:ATDD]]

Revisión actual del 01:36 8 sep 2009

Contexto

Un proyecto de desarrollo de software que pecisa mejorar la calidad y reducir el número de defectos.

Problema

Mejorar la calidad de software como un todo y hacer su validación, desde el punto de vista de los clientes y usuarios, siendo un aspecto fundamental en el proceso de desarrollo de software. Cuando se utiliza el desarrollo iterativo e incremental o cuando lidiamos con software con un largo tiempo de vida, es todavía mas importante validar el producto de forma ágil y con un mínimo de etapas repetitivas manuales.

Fuerzas

  • Defectos que aumenta cuando la interdependencia entre módulos individuales crece.
  • Las pruebas unitarias pueden detectar y eliminar defectos en clases individuales, pero ellos no detectan defectos de dependencia entre módulos.
  • Los problemas de entendimiento de requisitos dificultan el lanzamiento de versiones de software.
  • Las pruebas manuales tienden a estar cada vez mas demoradas, debido al aumento del número de funcionalidades del producto. Por lo tanto, los ciclos de pruebas manuales se alargan y corren riesgo de tornarse los caminos críticos de los proyectos de desarrollo.

Solución

Utilice herramientas para la construcción de pruebas automatizadas regresivas de aceptación. Las pruebas regresivas se tornan mas veloces y los analistas de pruebas se pueden concentrar en mejorar y aumentar el conjunto de pruebas, en cambio de apenas rehacer las pruebas existentes en referencia a las pruebas anteriores.

Raciocinio

Las pruebas de aceptación automatizadas que describen los procesos de negocio pueden ser tratados como requisitos ejecutables. Estas pruebas dan escenarios de uso del software de la misma forma en que un usuario lo haría.

Cuando son automatizados a través de scripts, la ejecución de una batería de centenas de pruebas puede ser realizada en minutos. Cada ejecución de una batería de pruebas automatizados de aceptación genera un documento detallado de las pruebas que funcionaron correctamente y las que fallaron.

En un proceso de desarrollo iterativo la existencia de una estrategia de pruebas de aceptación automatizada es todavía mas importante. Esto ocurre porque a cada iteración es necesario probar las funcionalidades creadas en la iteración actual y también todas las funcionalidades construídas el las iteraciones anteriores.

Contexto Resultante

El proyecto posee un conjunto de pruebas de aceptación automatizadas que es ejecutada al final de cada iteración y siempre que sea necesaria la ejecución de pruebas de regresión.

Los códigos de las pruebas generadas por la Automatizacion De Pruebas De Aceptacion deben ser almacenados en la herramienta de control de versiones, junto con el código fuente del software.

Patrones Relacionados

Ver también

Herramientas Para Pruebas De Aceptacion

Reconocimientos

  • (BECK, 2004)
  • (COCKBURN, 2001)
  • (MCCONNELL, 2004)
  • (MUGRIDGE e CUNNINGHAM, 2005)
  • (TATE, 2005)