menu_superior

Repetir, repetir y repetir…

coloresComo profesionales del testing, una de nuestras responsabilidades pasa por hacer cierta pedagogía de nuestra actividad profesional. Mi concepto de “hacer pedagogía” es precisamente escribir posts como este, dar charlas,  crear/fomentar/participar en comunidades profesionales… Hay que enseñar qué posibilidades ofrecemos, qué tareas podemos asumir, cómo se hacen bien las cosas, etc.

Por cierto, hacer pedagogía, divulgar no es vender(*).

Creo que, como gremio, hacemos poco por divulgar porque siempre que leo sobre pruebas o asisto a conferencias hay muchas ideas generales, muchos lugares comunes(**) y pocas veces hacemos hincapié en conceptos básicos. Hoy en concreto quería escribir sobre uno de estos conceptos que no siempre dejamos claros. Muchas veces indicamos que las pruebas deben ejecutarse hasta que el software sale a producción sin tener en cuenta que las pruebas son un proceso cíclico que se repite una y otra vez…

Creo se pone muy poco énfasis en caracterizar el proceso de pruebas como algo cíclico. Las pruebas no terminan con la salida a producción de la misma manera que el desarrollo no termina con la salida a producción. Todos (proveedores y clientes) tenemos asumido que el software tiene mantenimiento evolutivo o correctivo, sin embargo no está tan claro que a esos mantenimiento haya que someterlos a prueba.

La idea de la repetición es beneficiosa desde varios puntos de vista:

  • Pruebas sobre el nuevo código. Resulta más que evidente que el cambio que se va a integrar en la aplicación no está probado, por lo tanto hay que probarlo (pruebas funcionales y las que sean necesarias en función de la entidad del cambio).
  • Pruebas de regresión. Como es posible que  este evolutivo o correctivo, que parece que funciona correctamente, interfiera en alguna estructura o funcionalidad, es imprescindible efectuar pruebas de regresión. La idea es que el cambio introducido no genere efectos colaterales ni defectos en partes de la aplicación que no han sido modificadas. Esta idea tan simple es un dolor de cabeza realmente notable en aplicaciones grandes por que cada cambio normalmente afecta a varias partes de la aplicación. Hay que hacer muchas pruebas para tener un nivel de seguridad aceptable en que el cambio no ha dañado el resto de la aplicación.
  • Especialización de las pruebas. A medida que este proceso de pruebas sobre los cambios se va repitiendo, es decir, cada cambio tiene que pasar sus pruebas y la aplicación al completo tiene que pasar las pruebas de regresión, los casos de prueba serán más precisos y estarán más especializados. Hay que descartar aquellos que queden obsoletos y generar nuevos casos con las funcionalidades que se vayan incorporando.
  • Especialización del equipo. Aunque este tipo de pruebas serán ejecutadas de manera abrumadoramente automática, el equipo de pruebas conocerá más profundamente la aplicación, los datos, el negocio y la funcionalidad. Por lo tanto su trabajo será cada vez más eficiente (más rápido y más efectivo).

Por lo tanto, pongamos el acento en el proceso cíclico, no lineal y enseñemos que las pruebas son efectivas cuando se hacen una y otra vez… La clave para mejorar el software es repetir, repetir, repetir y repetir!

(*)Vaya por delante que vender no es malo, ni tiene que verse como algo negativo o peyorativo, por que no lo es. En el fondo exponer argumentos para la venta no es más que satisfacer la necesidad que alguien tiene a cambio del precio convenido. Veamoslo así: Se puede vender haciendo divulgación del testing, pero los enfoques son diferentes y los objetivos también.

(**)Lugares comunes: ¿quién no está harto de la curva del coste de los defectos?¿De que se hable de pruebas automáticas como algo mágico que soluciona todo tipo de problemas?¿De metodologías que garantizan el éxito? ¿De que las pruebas eliminan defectos?

, , ,

Comments are closed.