Conforme el investigador va cambiando su fuente de información de google o wikipedia a documentos más especializados, éste se va dando cuenta que los detalles comienzan por hacerse cada vez más relevantes. Tomemos un ejemplo. Pídale a una persona que pruebe algo y luego dígale que lo revise. Observe bien. ¿Hizo algo diferente? Mi intuición me indica que en la mayoría de los casos no hay mayor diferencia en lo que se haga en una u otra solicitud. Sin embargo a nivel formal hay un mundo de diferencia entre ambas definiciones, y aún las hay más cuando se asocian a un tema de software.
Leyendo el libro de Lewis (Software testing and continuous quality improvement) encuentro la reveladora aclaración de que "probar" es una acción que busca encontrar errores, mientas que "revisar" lo que pretende es verificar la calidad asociada a los estándares del producto. Pese a que la persona del ejemplo del párrafo anterior haya hecho prácticamente lo mismo, nótese como en el software los resultados esperados cumplen objetivos no semejantes.
Por supuesto que ambas acciones guardan varias similitudes. Buscan mejorar el software, reducen las futuras complicaciones y costos reputacionales y económicos de no aplicarse, siguen metodologías de diagnóstico equiparables, pero en última instancia su objetivo es diferente.
Si partimos de los modelos de desarrollo estándares, en donde primero surge un levantamiento de requerimientos, luego viene un diseño lógico de la aplicación, luego un diseño físico que da lugar a una programación y finalmente a un código utilizable, cada una de estás etapas tiene asociado un tipo particular de pruebas: pruebas de aceptación, pruebas de sistema, pruebas de integración y en un inicio pruebas unitarias. Lo que Lewis plantea es que cada etapa del desarrollo debe tener su correspondiente prueba, de manera que no se pueda pasar a la siguiente etapa con errores.
Por su parte la parte de la revisión puede que ni siquiera llegue a ejecutar el programa. Se concentra más bien en verificar los estándares seguidos por las partes involucradas en el desarrollo, pudiendo hacerse formal o informalmente. Las revisiones surgen para complementar las pruebas. Es importante notar que establecer que un software tiene errores puede ser una tarea titánica e infinita, con lo cual revisar las prácticas seguidas puede ser una forma operativamente más sencilla de garantizar que las condiciones para que el producto final salga bien se hayan dado.
Como pueden notar ambas, pruebas y revisiones, son necesarias y pueden hacerse en simultáneo. Lo relevante y lo que persigo con esta publicación es que entendamos, cuando alguien nos requiera una de ellas en particular, saber diferenciar lo que se nos ha pedido y no pecar de manejar un vocabulario tecnológico light.
No hay comentarios:
Publicar un comentario