Software Testing Como una Disciplina Formal de la Ingeniería

Ahora tener cero defectos, y cumplir con todos los requerimientos y especificaciones, no basta para decir que el software tiene calidad, es necesario cumplir y exceder las expectativas del cliente, hacer más de lo que él espera para que realmente haya una reacción de satisfacción y adopción.El objetivo de hacer pruebas –más que encontrar la mayor cantidad de defectos– debe de ser mejorar en lo más posible la calidad y satisfacción del usuario final, afrontar esta situación con un enfoque constructivo, no destructivo. Un segundo objetivo, debe de ser también, crear indicadores acerca de la calidad del producto, para que los tomadores de decisiones en base a esto, puedan decidir si liberar o no un producto a tiempo, o si es necesario esperar y seguir mejorando el software, hasta que cumpla con los estándares establecidos. Por otro lado, el proceso de testing debe de generar evidencia de que las pruebas se han hecho correctamente, existen compañías que debido a fallas críticas en su software –que representan grandes cantidades de dinero para sus clientes–, han sido demandadas, y han tenido que presentar en la corte casos de prueba para comprobar que, realmente sí ejecutaron las pruebas debidas de manera responsable, durante el tiempo del desarrollo.

Es por esto que es vital involucrar la parte de Testing durante todo el ciclo de vida de desarrollo de software y no sólo al final, como en muchos casos se hace. Hoy en día, en la mayoría de las empresas, no existe un departamento de testing como tal, algunas veces, es el mismo desarrollador, que al finalizar su parte del código, si le queda tiempo, hace un par de pruebas por aquí y por allá, sólo para asegurarse de que lo que hizo, funciona, dejando a un lado otro tipos de pruebas que también son importantes. Son pocas las Universidades a nivel mundial que tienen en sus planes de carrera, materias relacionadas con testing, únicamente vemos en las clases de Ingeniería de Software un apartado acerca del Aseguramiento de Calidad, pero esta disciplina se cubre de una manera muy limitada.

Si queremos alcanzar niveles altos de calidad para competir con nuestro software a nivel internacional, es necesario que el equipo de testing esté integrado desde el principio, representando al usuario final, evaluando requerimientos y empezando a probar el software desde la especificación, aunque no tenga en sus manos el producto final.

Pero, ¿cuál es la mentalidad de un tester?, ¿un desarrollador puede ser un buen tester?. Esta es una pregunta interesante, un tester, necesita tener una curiosidad especial que lo lleve a querer intentar distintos escenarios al hacer sus pruebas, debe de ser una persona que quiera representar al usuario final, que se ponga en sus zapatos y que realmente intente utilizar el software de la manera que éste lo haría. Debe ser una persona estructurada, pero a la vez, con un pensamiento lateral, que le permita ver más allá de lo que las personas normales ven; y al mismo tiempo debe tener la capacidad de orientar las pruebas de manera ordenada. Generalmente, se recomienda que el tester sea alguien que no haya desarrollado el software, para que el conocimiento de la arquitectura y algoritmos no afecte la manera en que prueba las cosas. Se tiene la imagen de que un buen tester es alguien que le gusta destruir y descomponer cosas; puede ser verdad, pero al mismo tiempo, debe de ser alguien preocupado y comprometido con la calidad, como comentamos al principio.

Ya que tengo al equipo indicado de testing, ¿cómo debo de empezar?, ¿cómo estructurar las pruebas de mi software? Pensemos en un microondas que parece ser un aparato electrodoméstico muy sencillo, ¿qué pruebas le podemos hacer? Bueno, es necesario ver que caliente la comida, pero hay mucho más que eso, es necesario probar que haga las cosas para las cuales fue hecho, calentar, una de ellas; pero que también sirvan sus funciones para descongelar; que a la vez que calienta pollo, caliente bien la carne, que si calienta bien un plato pequeño de comida, también caliente bien un kilo; que con el tiempo específico, no queme las palomitas. ¿Qué pasa si al microondas lo utilizan al aire libre, donde le puede caer agua?, ¿funciona igual si lo utilizan en una cocina pequeña que si lo utilizan todo el día en un restaurante?, ¿qué pasa si mientras funciona, se va la luz?, ¿qué pasa con el reloj incluido en el micro, funciona bien?, ¿los distintos sonidos que tiene, suenan cuando deben de sonar?, ¿qué pasa si me lo llevo a Inglaterra donde el voltaje que utilizan es distinto al de México? Existen un sin número de pruebas que le podemos hacer a un microondas, podemos utilizar esta analogía y transportarla al software.

Una manera sencilla de explicar cómo se pueden organizar las pruebas, es a través de una pirámide, donde si las partes de arriba no van bien, no vale la pena seguir probando y hay que pedir que se arreglen los defectos antes de continuar. (Ver figura 1)

Figura 1. Pirámide para organizar las pruebas

La punta de la pirámide es ver la funcionalidad básica: ¿el software hace lo que debe de hacer? Si es una calculadora, ¿hace las operaciones básicas? La siguientes pruebas son las de funcionalidad extendida, ¿además de sumar, restar, multiplicar y dividir, también puedes obtener raíz cuadrada?, ¿qué tal porcentajes? También hay que probar casos extremos, si la calculadora maneja enteros, ¿qué pasa si le pongo un número entero mayor al que puede desplegar?, ¿qué pasa si hago operaciones con números decimales?, ¿qué pasa si hago operaciones con cero? Por otro lado, el performance también es importante, ¿la calculadora se tarda más tiempo en dar el resultado que hacer yo la operación en la mente? Hoy en día también vale la pena evaluar si el software es fácil de usar, ¿necesito leer cien páginas de instructivo para saber usarlo?, ¿es intuitivo?, ¿cuántos clicks tengo que dar para llegar a un resultado? Las pruebas de seguridad no hay que olvidarlas, ¿pueden otras personas ver lo que estoy haciendo con mi software? Los sistemas de misión crítica necesitan correr los 365 días del año las 24 horas del día, ¿puedo confiar en que el sistema estará corriendo todo el tiempo?, ¿es de uso rudo?, ¿qué pasa si lo someto a condiciones de estrés? Estas pruebas son las de confiabilidad y estrés. Compatibilidad, ¿cómo trabaja mi aplicación sobre X sistema operativo? Y qué pasa si quiero exportar esa calculadora, ¿la puedo vender en Japón?, ¿cumple con los estándares de calidad japoneses?
Es importante involucrar testing desde el inicio del ciclo de desarrollo para cumplir con estándares de calidad a nivel mundial, es recomendable que la mentalidad de un tester esté orientada al cliente y al mismo tiempo que esté comprometido con la calidad. Existen distintos tipos de pruebas y todo depende de la magnitud del software que se esté construyendo, lo que se debe de buscar no es cero defectos, sino cumplir y exceder con las expectativas del usuario final del software.