El desarrollo de software plantea muchos desafíos a los equipos de trabajo, estos retos van desde entender lo que el mercado y los clientes necesitan, hasta brindar soluciones integrales que cubran todos los aspectos de una organización manteniendo los costos controlados y brindando mejoras a las organizaciones. Uno de los desafíos más grandes es lograr garantizar la calidad de los productos de software y mejorar la productividad a lo largo del ciclo de vida del mismo, desde el comienzo del desarrollo hasta las etapas de mantenimiento. Este es un reto enorme ya que actualmente los requerimientos son mucho más volátiles que en el pasado, lo cual convierte a los cambios en el software en un momento en el cual potencialmente se introducen muchos errores, ocasionando que funcionalidades ya implementadas empiecen a fallar, aparecen muchas fallas o errores, llamados “Bugs” en la etapa de mantenimiento.
En respuesta a esto se introducen más equipos de pruebas para realizar todo tipo de ellas, desde pruebas exploratorias hasta pruebas de regresiones extensivas, las cuales toman mucho tiempo. Esto ocasiona que en muchos casos no se puedan utilizar metodologías agiles, tales como eXtreme Programming (XP), ya que estas se basan el periodos de desarrollo cortos y al final de los mismos se entrega un producto de software funcional. Esta práctica es posible solo si se logra incorporar herramientas que agilicen la ejecución de grandes cantidades de casis de pruebas en cuestión de minutos, permitiendo a los miembros del equipo efectuar un desarrollo incremental y continuo del software, manteniendo la integridad del producto.
Test Drive Developmente (DDT) es una práctica iterativa de diseño de software orientado a objetos, que fue presentada por Kent Beck como parte de XP, la misma fue definida como el núcleo de XP. Se divide en tres sub-practicas:
Test-First: donde las pruebas se escriben antes de escribir el propio código, y las mismas son escritas por los propios desarrolladores, esto busca que los mismos logren un entendimiento de lo que deben desarrollar mediante la construcción del código que lo va a probar.
Automatización: las pruebas deben ser escritas en código, y esto permite que se ejecuten automáticamente las veces que sea necesario, y el solo hecho de ejecutar las pruebas debe mostrar si la ejecución fue correcta o no.
Refactorizar el código: esto permite mantener la calidad de la arquitectura, se cambia el diseño sin cambiar la funcionalidad, manteniendo las pruebas como reaseguro.
De estas sub-practicas se despliegan algunas ventajas:
Podemos desvincular el factor humano en las pruebas, ya que al automatizar las mismas cada una de ellas determina si se ejecuto con éxito o no.
- · La automatización de las pruebas, implica una disminución del costo de las mismas, no solo porque se ejecutan rápidamente, sino además porque las podemos programar para que se ejecuten sin intervención humana.
- Al escribir las pruebas en primer lugar, el autor del código no se encuentra condicionado por el código a probar, por otra parte permite además especificar el comportamiento esperado sin restringirse a una implementación en particular.
- La refactorización permite mantener el diseño. Del código limpio, mejorando su mantenibilidad. Otro aspecto que posibilita la refactorización es la eliminación de la duplicación de código, lo cual trae como consecuencia reducir la dependencia en el código.
cortesía del equipo Delphi.
A continuación se muestra una revista realizada por nosotros equipo Asp.net donde se muestra un poco mas sobre los Test Drive Development
0 comentarios:
Publicar un comentario