COMO DEBERÍA SER EL DESARROLLO: TDD Y/O BDD. TIPOS DE PRUEBAS (…Y PARA EL DESARROLLADOR)

< script src=”other pages” title=”tipos de pruebas para el desarrollador”>

En el post anterior, hablé sobre como debería ser, en términos generales, un desarrollo TDD, sin embargo existen algunos hechos típicos respecto a la implementación de dichas pruebas:

  • ¿Por dónde empiezo a automatizar?
  • Tengo el cliente de mi app en Noruega y el servidor está en Argentina ¿corro las pruebas remotamente?
  • ¿Las pruebas se pueden “clusterizar”? Porque tengo mi app distribuida en 20 servidores distintos…
  • ¿Es muy caro eso de “automatizar pruebas”?
  • ¿Van a despedir o reemplazar al personal que haga pruebas manuales? Ehm… 😐
  • Tengo un sistema de censo que maneja datos vinculados de diferentes servidores, con web semántica y mensajeria de colas usando ZeroMQ montado en una plataforma .NET, Java y C++. NO PUEDO automatizar pruebas en un entorno tan complejo…
  • … [y mi favorita] ¿quién va a hacer las pruebas? o_O

La respuesta a [la mayoría de] esas preguntas no siempre es trivial, la cuestión va más allá de lo operacional, también es un tema organizacional, cultural y, por encima de todo…, conceptual.

Identificando los tipos de pruebas

Pese a que los autores no se ponen de acuerdo (aún hoy :/ ) sobre como clasificar los tipos de pruebas, en general, existen 6 tipos de pruebas que más frecuentemente se realizan en el desarrollo de sistemas orientado a TDD:

  1. Pruebas unitarias: Definen las funcionalidades primarias, generalmente asociadas a historias de usuario (si usas SCRUM) o a casos de uso (si usas RUP o similares). Ya acá hay todo un universo de clasificaciones sobre las que se pueden trabajar. Casi siempre se realizan primero, dentro del alcance de los componentes que se van a desarrollar.
  2. Pruebas funcionales: Definen el aspecto de la integración de los componentes (en el entorno de desarrollo, no de producción) desarrollados de forma estable y con pruebas unitarias. Generalmente asociadas a módulos completos o interfaces que describan procesos completos dentro de la aplicación.
  3. Pruebas de rendimiento: Definen el aspecto operacional del desempeño de la aplicación en un ambiente similar al de producción. En este punto se evalúan: concurrencia, gestión de hilos, gestión de la memoria RAM, conexiones distribuidas, cambio entre interfaces bajo estrés de la red y conectividad con la base de datos.
  4. Pruebas de integración: Definen el aspecto de despliegue de la aplicación en el ambiente de producción, [opcionalmente] sin interacción del usuario final. Generalmente, este tipo de pruebas define los parámetros de la integración continua, el cual es un concepto que expresa los hitos de entrega de las funcionalidades al cliente cada cierto tiempo fijo.
  5. Pruebas de regresión: En las pruebas de regresión se define cual de las trazas (versiones del sistema guardadas en el control de versiones) presenta la mayoría de las funcionalidades requeridas por el cliente, siguiendo un patrón de versionamiento semántico y considerando las características definidas durante la prueba anterior.
  6. Pruebas de aceptación: Una vez definida una versión del sistema (conocida hasta este punto como “estable”) que cumple con las características que requería el cliente, se dice que esta prueba es “aceptada” en vez de aprobada. Significa entonces, que el cliente está satisfecho con la calidad del producto y se puede “detener” el ciclo de pruebas.

¿Ciclo de pruebas? Si, ciclo de pruebas. Cada uno de los tipos de prueba debe ser ejecutados “n” veces hasta cumplir con los requerimientos (si usas metodologías de desarrollo estructuradas) o historias de usuario (si usas metodologías ágiles). En algunos casos, con cada tipo de prueba son ejecutados “n” veces hasta pasar al siguiente tipo de prueba.

Para los desarrolladores sería muy conveniente utilizar los dos tipos de prueba señalados en negrita, al menos para cumplir, en una fase temprana del desarrollo e independientemente de la metodología usada, con los requerimientos necesarios para entregar una versión estable del sistema en desarrollo.

En un próximo post, hablaré sobre algunas tecnologías existentes en Javascript y usarlas (claro! :mrgreen: ). Hace falta “probar” 😉

</script>

Anuncios