\u00bfCu\u00e1nto esfuerzo en pruebas es suficiente?<\/strong><\/p>\n Como todos los dem\u00e1s productos, tampoco el software est\u00e1 \u201csiempre\u201d libre de fallos. Las pruebas no pueden garantizar nunca la ausencia de fallos en un programa, sin embargo pueden encontrar y solucionar errores. En la pr\u00e1ctica unas pruebas exhaustivas son rara vez posibles, sin embargo tampoco se puede garantizar para las partes probadas la ausencia total de errores.<\/p>\n Seg\u00fan el \u00e1mbito de aplicaci\u00f3n y el tipo de error pueden ocasionarse da\u00f1os graves. Por eso deben ser probadas \u201ctodas\u201d las funcionalidades de un software de manera sistem\u00e1tica. Un proceso de pruebas puede considerarse en cierto sentido como destructivo y debe estar siempre encaminado a encontrar fallos.<\/p>\n La resoluci\u00f3n de errores durante el desarrollo mejora el producto y reduce el coste de una eliminaci\u00f3n posterior de los errores<\/p>\n Problemas generales de las pruebas<\/strong><\/p>\n \u00c1mbito de las pruebas<\/strong><\/p>\n \u00a1Ning\u00fan software complejo puede ser probado completamente! Incluso si se definieran todos los casos de prueba posibles su ejecuci\u00f3n consumir\u00eda enormes recursos. En la pr\u00e1ctica no ser\u00eda posible la definici\u00f3n de todos los casos de prueba necesarios para unas pruebas exhaustivas, ya que habr\u00eda que tener en cuenta todas las diferentes condiciones de entorno posibles. Adem\u00e1s pr\u00e1cticamente en ning\u00fan caso se podr\u00e1 decir con seguridad que se han definido todos los casos de prueba posibles.<\/p>\n Alcance<\/strong><\/p>\n El alcance de las pruebas debe ser, por consiguiente, reducido \u2013 esto sucede en funci\u00f3n de la relaci\u00f3n entre Prioridades y Riesgo establecida utilizando formas de proceder sistem\u00e1ticas. No est\u00e1 justificado un alto esfuerzo de pruebas para la eliminaci\u00f3n de fallos \u201cmenores\u201d. Implementar un programa sin comprobar los errores en sus caracter\u00edsticas esenciales no tiene mucho sentido.<\/p>\n En la pr\u00e1ctica se prueba mediante casos puntuales. En todo caso, esta prueba puntual se determina en la pr\u00e1ctica de manera anal\u00edtica.<\/p>\n Costes<\/strong><\/p>\n Las pruebas originan altos costes dentro del desarrollo de software. Sobre todo en grandes proyectos de TI el esfuerzo para realizar las pruebas puede ser el mayor de todos respecto del esfuerzo total. Las pruebas tempranas contribuyen a la mejora del proceso de desarrollo y reducen de esta manera los costes (entre otras causas por la reducci\u00f3n de errores descubiertos en fases posteriores del desarrollo de software, ya que ah\u00ed el descubrimiento de fallos y su resoluci\u00f3n conlleva un esfuerzo claramente mayor).<\/p>\n Los errores que no se encuentran en las pruebas tambi\u00e9n producen costes (Coste de Errores). P\u00e9rdidas de imagen, esfuerzos para las correcciones y compensaci\u00f3n de da\u00f1os amenazan al productor. Errores o p\u00e9rdidas de datos y tiempos de inactividad son las consecuencias para los clientes.<\/p>\n En muchas situaciones es aplicable que los costes en las pruebas deber\u00edan ser menores que los posibles costes de los errores.<\/p>\n Principio 1: Las pruebas muestran la presencia de defectos<\/strong><\/p>\n Las pruebas pueden mostrar la presencia de defectos. Las desviaciones respecto a los resultados previstos que se descubren durante las pruebas permiten localizar defectos existentes en el software. Las pruebas no pueden probar la ausencia de defectos. Las pruebas reducen la posibilidad de que queden defectos sin descubrir. La ausencia de fallos no prueba que el software sea correcto. El propio procedimiento de prueba puede contener errores. Las condiciones de pruebas pueden no estar bien preparadas para encontrar errores.<\/p>\n Principio 2: Las pruebas exhaustivas no son posibles<\/strong><\/p>\n Pruebas exhaustivas<\/em><\/strong>. Es una estrategia de pruebas en la que se abarcan todas las posibles combinaciones de valores de entrada y precondiciones.<\/p>\n Explosi\u00f3n de casos de prueba<\/strong><\/em>. Define el aumento exponencial de esfuerzo y coste que aparece cuando se hacen pruebas exhaustivas.<\/p>\n Muestreo en las pruebas<\/em>.\u00a0<\/strong>Las pruebas deben incluir s\u00f3lo un subconjunto de todos los valores de entrada posibles. Las entradas seleccionadas pueden escogerse de forma sistem\u00e1tica o aleatoria. En condiciones reales, se suele emplear el muestreo. Las pruebas de todas las combinaciones de entradas y precondiciones es viable desde el punto de vista econ\u00f3mico s\u00f3lo en casos triviales. En lugar de llevar a cabo pruebas exhaustivas, se deber\u00eda utilizar el an\u00e1lisis de riesgo y el uso de priorizaciones para enfocar los esfuerzos de las pruebas.<\/p>\n Principio 3:\u00a0 Pruebas tempranas<\/strong><\/p>\n Las actividades de prueba deber\u00edan iniciarse tan pronto como sea posible en el ciclo de vida de desarrollo y deber\u00edan tener objetivos concretos. Cuanto antes se descubra un defecto, menos costosa ser\u00e1 su correcci\u00f3n. La m\u00e1xima efectividad se alcanza cuando los errores se corrigen antes de ser implementados. Pueden probarse los documentos de requisitos conceptuales y las especificaciones Principio 4: Bloques de defectos<\/strong><\/p>\n Unos pocos m\u00f3dulos contienen la mayor parte de los defectos descubiertos durante la fase de pruebas o son responsables de la mayor\u00eda de los fallos de producci\u00f3n. Encuentre un defecto y encontrar\u00e1 m\u00e1s en los alrededores. Los defectos aparecen frecuentemente en grupos como las setas. Es una buena idea repasar el m\u00f3dulo en el que se ha encontrado un defecto. Los probadores deben ser flexibles. Una vez detectado un defecto, es una buena idea reconsiderar la direcci\u00f3n de las siguientes pruebas. La localizaci\u00f3n de un defecto debe ser revisada con un mayor nivel de detalle, ya sea incorporando nuevas pruebas o modificando las existentes.<\/p>\n Principio 5: La paradoja del pesticida (Bezier)<\/strong><\/p>\n Si se repiten una y otra vez los casos de prueba, se llegar\u00e1 a que el mismo conjunto de casos de prueba no sirva para localizar nuevos defectos. Para superar esta \u201cparadoja del pesticida\u201d, los casos de prueba necesitan ser revisados de manera regular y se necesita escribir casos nuevos (y diferentes) para ejercitar diferentes partes del software o sistema y localizar m\u00e1s defectos. Cualquier m\u00e9todo que se use para prevenir o encontrar bugs deja un residuo o bugs m\u00e1s sutiles, contra los que ese m\u00e9todo no es efectivo. Repetir las pruebas bajo las mismas condiciones no es efectivo. Si se repiten una y otra vez las mismas pruebas no se encontrar\u00e1n nuevos errores. Las pruebas deben ser revisadas regularmente. Es necesario repetir una prueba despu\u00e9s de que se hagan cambios en el c\u00f3digo. Las pruebas automatizadas pueden ser una ventaja si se usa regularmente un grupo de casos de prueba.<\/p>\nPrincipios generales de las pruebas<\/h2>\n
\nLos defectos que se descubren en la fase de concepci\u00f3n del proyecto se corrigen con m\u00ednimos esfuerzos y costes. La preparaci\u00f3n de una prueba consume tiempo. La prueba no es s\u00f3lo la ejecuci\u00f3n. Pueden realizarse actividades de prueba (Dise\u00f1o) antes de que se complete el desarrollo de software. Las actividades de prueba (considerando como tales las revisiones) deber\u00edan llevarse a cabo en paralelo a la especificaci\u00f3n y el dise\u00f1o de sw.<\/p>\n