En este mundo de los sistemas y software, la calidad del software siempre se ha tenido que justificar la necesidad de probarlo y los beneficios y el valor añadido que aportan…

¿Realmente es necesario hacer pruebas al software?

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 convencionalismos, mitos o temores alrededor del testing? ¿Por qué hay tantos “peros” al testing como una actividad de valor añadido? En este artículo se va exponer algunos de los “mitos” con los que me he enfrentado a la hora de realizar la actividad de testing en los proyectos en los que he tenido la fortuna de colaborar, y por qué creo que son falsos, espero que sean de utilidad:

    • -“Mi sistema está hecho por desarrolladores experimentados y no se equivocan nunca“. Bien, supongamos que es cierto y que no se equivocan nunca. 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 enorme mayoría de los casos los sistemas se integran con otros aplicativos, utilizan entradas y salidas de subsistemas que no están bajo nuestro control. Por lo tanto hay que realizar pruebas del software porque es la única manera de señalar en qué casos podemos predecir su funcionamiento.

 

    • -“Los usuarios hacen las pruebas antes de salir a producción“. Esta práctica consiste en dejar que los usuarios utilicen el sistema como lo harían normalmente. A favor tiene que es muy barato, fácil de organizar y crea un precursor para establecer un testing más elaborado. En contra es que no se está probando los requerimientos especificados. También es muy posible que los usuarios no posean la capacidad para desarrollar casos de prueba para verificar que el sistema es tolerable a fallos. Es necesario que el testing sea un proceso proveniente de un análisis detallado.

 

  • -Hay un último punto que me gustaría tocar, que tiene que ver más con una percepción que con un argumento, es la sensación que provoca sentirse cuestionado, sentir que tu trabajo es permanentemente debatido por todo el equipo, respecto a que no se hacen pruebas correctamente o por el contrario haces tu trabajo demasiado bien, provocando con esto, muchas veces el enojo de los programadores, por encontrarles una cantidad considerable de fallas Esta concepción hacia los que nos dedicamos al mundo del testing, me parece totalmente desacertada ya que, como se ha escrito, por muy bien que trabajen los desarrolladores el producto final puede tener resultados no esperados, o funcionamiento no esperado. 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 encargados de entregar productos con calidad a todos nuestros clientes.