Modelos de desarrollo y Testing

Existen varios modelos de desarrollo de software. En cada modelo de desarrollo se incluye el testing, que no esta aislado, sino que forma parte del mismo. Algunos de estos modelos son los siguientes.

## Modelo en Cascada

De los primeros modelos, principal característica es que las tareas se ejecutan una después de la otra. Esta característica es una desventaja a la hora de hacer testing, ya que se necesita que el software esté completo.

Se tarda mucho en comenzar y los defectos encontrados en esta etapa son muy costosos de corregir.

## Modelo en V

Similar al modelo en cascada, se diferencia en que intenta que el testing se realice lo antes posible en el ciclo de vida de software.

Se le dice modelo en V por su forma, en el lado izquierdo se encuentra la especificaciones y necesidades, hasta llegar a la implementación. Al lado derecho se encuentra la integración de las partes y su verificación.

Al profundizar en el lado, el testing va comprendiendo el sistema y elaborando pruebas, de esta manera al no iniciarse una vez que el software está terminado se pueden encontrar defectos antes, lo que evita costos altos de corrección.

## Modelos iterativos

Diferentes a los anteriores (secuenciales). Se utilizan ciclos de vida del software de menor tiempo, de esta manera se puede obtener una mejora o incremento en menor tiempo. En cada incremento se encuentra el testing que se encarga de probar la nueva funcionalidad, corrección o mejora, así como también su integración.

## Dirigido por pruebas (Test-Driven-Development TDD)

Es un enfoque al diseño de programas donde se entrelazan el desarrollo de pruebas y el de código, se introdujo como parte de los métodos ágiles. El código se desarrolla incrementalmente en conjunto con la prueba para ese incremento. No se avanza hacia el siguiente incremento sino hasta que el código diseñado pasa la prueba.

### Proceso de TDD

1. Se identifica el incremento de funcionalidad requerido (usualmente pequeño y aplicable en pocas líneas de código).
2. Se escribe la prueba para la funcionalidad y se implementa de forma automatizada (de forma que pueda ejecutarse y reportar).
3. Se corre la prueba en conjunto con las otras ya implementadas (sin aplicar la funcionalidad). De esta manera muestra que la prueba aporta al conjunto de pruebas.
4. Se implementa la funcionalidad y se realiza nuevamente la prueba. Puede incluir refactorización de código para poder agregarlo al ya existente.
5. Una vez funcionando con éxito todas las pruebas se avanza a la siguiente implementación.

### Ventajas

* Mejor comprensión del sistema. Al diseñar la prueba previo al código el programador ya tiene una idea clara de lo que debe hacer la funcionalidad a implementar.
* Cobertura de código. Cada segmento de código debe tener una prueba asociada.
* Pruebas de regresión. El conjunto de pruebas se desarrolla incrementalmente conforme se desarrolla el programa (reduce costos de pruebas de regresión).
* Depuración simplificada. Cuando falla una prueba queda en evidencia donde se encuentra el problema
* Documentación del sistema. Las pruebas en sí actúan como una forma de documentación.

TDD es muy utilizado en el diseño de software nuevo, donde la funcionalidad se implementa en código nuevo o con librerías perfectamente probadas. Al reutilizar grandes componentes de código o sistemas heredados, se necesitará escribir pruebas para dichos sistemas como un todo.