Proceso de pruebas de software

El proceso de pruebas de software es una tarea técnica, precisa del dominio del lenguaje de programación en el que el artefacto a probar fue generado, también del conocimiento necesario para comprender la arquitectura del sistema implementado y de las implicaciones de tipo lógico que su diseño pueda suponer. Adicionalmente, el tester deberá conocer los lenguajes y herramientas que ha de usar para llevar a cabo este proceso de pruebas.

No obstante, el Software Testing es algo más que una tarea técnica. Es necesario un cambio de mentalidad importante por parte del tester. Consideremos la siguiente definición de Software Testing:

«El proceso de pruebas consiste en demostrar que los artefactos generados están libres de fallos»

«El proceso de Testing tiene como objetivo demostrar que el software realiza correctamente aquellas tareas para las que fue diseñado»

¿Es esta definición correcta? Obviamente NO. El proceso de pruebas no va orientado a demostrar la ausencia de fallos en el software, sino más bien a todo lo contrario: encontrar cuantos fallos existan, por escondidos que se encuentren o difícilmente reproducibles que sean.

Como ya comenté en la introducción de esta serie de posts, la gran mayoría de nosotros tiene la tendencia a entender la creación de software como un proceso únicamente constructivo. Soy mejor cuanto menos tardo en generar artefactos, y una vez los haya generado realizaré una serie de pruebas con las que quedaré satisfecho si no encuentro fallos: ¡Qué gran developer estoy hecho!

Cuando un artefacto llega a manos de un tester, su función dentro del proceso de ingeniería software es añadir valor al producto sobre el que está trabajando. ¿Esto qué significa? Una aproximación válida al concepto de valor añadido por un tester podría ser «incrementar la fiabilidad del software». Esto se consigue encontrando la mayor cantidad de bugs posibles, realizando un informe adecuado de los mismos, establecer la prioridad de resolución para cada uno de ellos… Otro factor que marca la mayor o menor validez de un tester consiste en la pregunta: «¿Hasta cuándo debo de intentar encontrar bugs?», a dicha pregunta le dedicaremos una entrada completa más adelante, pero básicamente podemos establecer que, obviamente, la respuesta no puede ser «hasta que hayamos probado todas las posibles ejecuciones del programa y estemos seguros de que no existe ningún bug oculto más». ¿Y por qué no? Principalmente, cuando consideramos artefactos suficientemente complejos, resulta imposible abarcar todas las posibles entradas y salidas posibles, todas las posibles trazas de ejecución, así como todas las situaciones de «incertidumbre» que se puedan producir.

Por tanto, una definición más acertada acerca de lo que es el Software Testing podría enunciarse de la siguiente forma:

«Software Testing es el proceso de ejecutar un programa con la intención de encontrar fallos»

Una vez hayamos sido capaces de llevar a cabo este cambio de mentalidad, podremos comenzar con nuestra labor de tester de una manera más efectiva y beneficiosa dentro del proceso de Ingeniería del Software. En el próximo post os hablaré acerca de las condiciones que debería tener un buen tester.

Leído desde http://geeks.ms/blogs/mllopis/archive/2008/02/09/191-en-qu-233-consiste-el-proceso-de-pruebas-de-software.aspx