menu_superior

Testing Funcional: Algunos mitos para no hacer pruebas

Después de llevar unos años en el mundo del testing y la calidad del software he tenido que justificar muchas veces la necesidad de probarlo y los beneficios y el valor añadido que aportan. En algún momento me he planteado si no estaba siendo demasiado cerrado… ¿Realmente es necesario hacer pruebas al software?

Si la respuesta es simple y seguro que todos la tenemos en mente, ¿por qué resulta tan complicado a veces justificar la necesidad de hacer pruebas? ¿Es posible que haya prejuicios, mitos o temores? ¿Por que hay reticencias al testing como una actividad de valor añadido? En este post voy a exponer algunos de los frenos con los que me he encontrado yo a la hora de implantar la actividad de testing en los proyectos en los que he colaborado y por que creo que son falsos, espero que os sean de utilidad:

  • Mi código está hecho por programadores experimentados y no se equivocan nunca“. Bien, supongamos que es cierto y que no se equivocan nunca. Incluso en ese caso nada te garantiza que la integración entre los diferentes módulos que forman parte de tu aplicativo sea perfecta, ni que tu aplicación no tenga problemas de diseño o, algo tan sencillo como que no hagas una adecuada captura de excepciones. Es muy común pensar que si todo se hace con buenos y experimentados programadores no habrá defectos… Suena razonable, pero no es cierto. La realidad es que en la inmensa mayoría de los casos los aplicativos se integran con otros aplicativos, utilizan entradas y salidas de subsistemas que no están bajo nuestro control, se instalan en plataformas que evolucionan con el tiempo, hacen uso de drivers de dispositivos que se actualizan según las necesidades. Todas estas circunstancias generan dependencias. Por lo tanto hay que probar el software por que es la única manera de acotar en qué casos podemos predecir su funcionamiento.
  • El testing es caro, si hay defectos saco una versión nueva que lo corrija“. El prespuesto es el caballo de batalla más duro al que tengo que  enfrentarme. Para ello yo tengo dos lineas de argumentación que contrarrestran el peso de la escasez de presupuesto.  Eso sí, siendo muy convincentes y de una lógica aplastante, el éxito no está garantizado:
    • El presupuesto de testing es adaptable. En la gestión de proyectos se maneja la regla de que entre un 10 y un 20% del presupuesto se debe gastar en el testing. Esto es muy difuso por que “el testing” incluye testing funcional, de rendimiento, automático, de seguridad, etc. Lo ideal es conciliar el nivel de profundidad y cobertura que deseamos con el presupuesto disponible. Si es una aplicación que tiene muchos problemas y tenemos poco presupuesto podremos recurrir a estrategias de tipo Rapid Software Testing o a Testing Exploratorio, si es una aplicación con muchas versiones podemos grabar scripts para automatizar las pruebas que se hacen con todas las versiones, etc. Existen soluciones adecuadas para todos los presupuestos.
    • Versionar sobre defectos es mucho más costoso. Sacar versiones para solucionar defectos (enfoque reactivo) es mucho más caro por tres causas:1) el tiempo que tardemos en generar la versión y ponerla en producción (Time to Market) es mayor que si corregimos el defecto antes de salir a producción; 2) hay un coste de imagen y de confianza por parte del usuario al que hemos podido causar un daño económico (lucro cesante) si hay una pérdida de servicio y 3) El coste de disminución o pérdida del servicio hubiera sido menor (o nulo) si se hubieran hecho unas mínimas pruebas antes de salir a producción. Hay un factor multiplicador del testing que lo hace extremadamente interesante desde un punto de vista de ahorro de costes.
  • Los usuarios hacen pruebas antes de salir a producción“. Esta práctica consiste en dejar unos días a usuarios experimentados para que utilicen la aplicación como lo hacen normalmente. A favor tiene que es barato, fácil de organizar y crea un precedente para implantar un testing más elaborado. En contra tiene que es tremendamente ineficiente y que parte del uso habitual, no del análisis de los requisitos funcionales de la aplicación. También es muy posible que los usuarios no tengan capacidad para generar casos de prueba que verifiquen que la aplicación es tolerante a fallos. Es imprescindible que el testing sea un proceso fruto del análisis y no de la fuerza bruta.
  • Hay una última reticencia que tiene que ver más con una percepción que con un argumento, es la intimidación que provoca sentirse controlado, sentir que el tu trabajo es permanentemente cuestionado por que se presupone que no lo haces bien. Esta sensación la tienen los equipos de desarrollo por que tradicionalmente la actividad de pruebas de software se publicitaba como un control que evitaba que salieran a la luz los errores cometidos por los equipos de desarrollo. Esta concepción negativa, reactiva y oscura me parece totalmente equivocada ya que, como he escrito más arriba, por muy bien que lo hagan los desarrolladores el producto final puede tener interacciones perjudiciales. Todavía hay algunos profesionales del testing que se identifican como cazadores de defectos, no obstante la mayoría identificamos y ejercemos nuestra labor de testers desde el aporte de valor, como soporte de la construcción de software y como optimizadores de calidad del producto con el que trabajamos.

Espero que después de leer esta entrada se haga más patente la necesidad de someter al software a procesos de testing antes de salir a producción. A mí me parece que es muy necesario recalcar la aportación que realizan las pruebas y la mejora que experimenta la calidad del software cuando se somete a un proceso de testing que se adapte a las prioridades y presupuestos de cada proyecto.

Comments are closed.