miércoles, 22 de febrero de 2012

Hablando de pruebas de software y calidad

Con esta imagen empecé hace 2 años una de mis exposiciones favoritas en la especialización, 5 minutos 10 diapositivas, los límites impuestos por uno de mis profes favoritos @betancur en la materia Verificación y Validación.

El tema que escogí para la exposición probar el software completamente es imposible, y que mejor que una referencia como Cem Kaner, experto en el tema de Pruebas de Sotfware para hablar sobre esto en su publicación The Impossibility of Complete Testing (a quien no le gusten los documentos densos, esta publicación tiene una versión corta que les recomiendo leer).

Bien los tuits que me hicieron pensar nuevamente en este tema fueron estos:


Una de las ideas gráficas más claras acerca de las pruebas de software es pensar en los programas como "campos minados" donde evidentemente los bugs (o fallas de calidad) son las minas, la diferencia frente al tema del campo minado, es que no hay como en el espacio físico, fronteras claras sobre el espacio a explorar, y entre otras, en cada revisión existe la posibilidad de que los errores ya encontrados continúen o se introduzcan nuevos, así que ¡vaya tarea!

En este punto es donde siempre recuerdo lecciones aprendidas con @betancur, la primera es clara y es que si tienes un terreno desconocido por explorar, encontrar errores en ese terreno se tratará de tener ideas, los testers deberían ser los mejores compañeros de un emprendimiento, deberían ser profesionales admirables por su capacidad de tener diferentes ideas para explorar y encontrar escenarios nuevos o derivados, entendiendo la heurística como fuente de las ideas, que lejos de ser un escenario de descontrol o desorden busca que además de tener esa chispa de encontrar diferentes vías se usen metodologías, técnicas y mecanismos de investigación para descubrir, develar o encontrar diferentes escenarios y resultados, y es que ni todos los programas de software, ni todos los equipos de trabajo, ni todos los proyectos son iguales, citando a betancur: "Diferentes objetivos requieren diferentes estrategias e implican distintas pruebas, documentación y resultados". 

La segunda de mi más valiosas lecciones aprendidas es:

"Quality is a value for someone"

En esa perspectiva es obvio que el tema resulta bastante subjetivo, pero esa frase es tan real y casi hace alusión a otra frase más típica que dice que "El cliente tiene la razón", esto en cualquier ámbito profesional está lejos de hacerse solo por seguir caprichos, tiene que ver fuertemente con los deseos (sensatos) de las personas y está sustentado en sus necesidades, finalmente y citando otra frase: "Si alguien que no importa encuentra que el producto es terrible es probable que no cambiemos nada".

Ahora bien, si ubicamos la calidad en contexto de tiempo y dinero, bajo nuestro escenario de no tener un espacio de exploración preciso, obtener un punto donde nuestro cliente considere que el software esta 100% probado, podría suponer un escenario de tener un software extremadamente probado en unos varios años cuando el promedio de errores por mes encontrados sea absolutamente insignificante (Insignificante es bien diferente a inexistente). En este punto podría casi escuchar a un cliente preguntando ¿Cuántos años? ¿Cual es el costo? ¿Qué obtenemos a cambio de invertir tanto tiempo es protegernos de posibles errores? No se ustedes que digan, parece un poco difícil convencer a alguien de asumir semejante inversiónLes invito a leer una última frase, con detenimiento:

Probar completamente significa que al final de las pruebas, usted sabe que no quedan mas bugs desconocidos.
Cem Kaner 

Creo que sobran las explicaciones. Por otro lado y para finalizar, algo que nunca debemos perder de vista es que la calidad no se logra encontrando al final de todo un proceso los errores que quedaron, parte de la calidad se logra con el compromiso de los individuos que hacen parte de un equipo en seguir un proceso y mejores prácticas, en tener técnicas y desmitificar el tema de que la improvisación en software es suficiente.

El tema de pruebas de software es un universo completo, como lo es en ingeniería de software cada una de las disciplinas existentes, razón por la que siempre me ven por estos lados discutiendo con los programasoes que se creen que hacer software en "solo" un arte, yo si creo firmemente que hacer software es un arte, pero no es eso solamente y creo que eso falta dejarlo claro.

Una última frase de reflexión
“Aunque haga muchos experimentos, mi hipótesis no queda confirmada, pero basta un solo experimento para confirmar mi errorAlbert Einstein

Espero les haya resultado útil

Sorey

1 comentario:

Judavi dijo...

Que buen post Sorey. Tienes razón en afirmar que es imposible encontrar todos los bugs de una aplicación... Nunca ha forma de de probar todas las posibles entradas y los usuarios son expertos en colocar las situaciones más inesperadas!