Una estrategia de prueba de software proporciona una guía quedescribe los pasos que deben realizarse como parte de la prueba,cuando se planean y se llevan a cabo dichos pasos, y cuanto esfuerzo,tiempo y recursos se requieran. Por tanto, cualquier estrategia deprueba debe incorporar la planificación de la prueba, el diseño decasos de prueba, la ejecución de la prueba y la recolección yevaluación de los resultados.Una estrategia de prueba de software debe ser suficientementeflexible para promover un uso personalizado de la prueba. Al mismotiempo, debe ser suficientemente rígida para alentar la planificaciónrazonable y el seguimiento de la gestión conforme avanza el proyecto.

Verificación y validación

La prueba de software es un elemento de un tema mas amplio queusualmente se conoce como verificación y validación se refiere alconjunto de tareas que garantizan que el software implementancorrectamente una función especifica. La validación es un conjuntoDiferente de tareas que aseguran que el software que se construyesigue los requerimientos del cliente.Verificación : “¿ construimos el producto correctamente?”Validación : “¿construimos el producto correcto?”La definición de V&V abarca muchas actividades de aseguramientoDe calidad del software . La verificación y la validación incluye unamplio arreglo de actividades SQA:

revisiones tecnicas,auditorias de calidad y configuraciones,Monitoreo de rendimiento, simulación, estudio de, revisión defactibilidad, revisión de documentación , revisión de base de datos,Análisis de algoritmos, pruebas de desarrollo, pruebas deUsabilidad, pruebas de calificación, pruebas de aceptación yPruebas de instalación.

Organización de las pruebas del software

En todo proyecto de software hay un conflicto inherente deintereses que ocurre conforme comienzan las pruebas. Hoy en día,Las personas que construyen el software se les pide probarlo.En si, esto parece sencillo; después de todo, ¿Quién conoce mejorEl programa que sus desarrolladores tienen mucho interés enDemostrar que el programa esta libre de errores, que funciona deacuerdo con los requerimientos del cliente y se completará aTiempo y dentro del presupuesto. Cada uno de estos interesestienen un efecto negativo sobre las pruebas mas cuidadosas.Desde un punto de vista psicológico, el análisis y diseño deSoftware (junto con la codificación) son tareas destructivas .

El ingeniero de software analiza, modela, y luego crea un programade computadora y su documentación. Como cualquier constructorel ingeniero de software esta orgulloso del edificio que construyo yVe con desconfianza a quien intente derrumbarlo.Cuando comienzan las pruebas hay un sutil, pero definitivo,intento por “romper” lo que construyó el ingeniero de software.Desde el punto de vista del constructor, las pruebas puedenconsiderarse como (psicológicamente) destructivas. De modo queel constructor actuará con cuidado, diseñará y ejecutará pruebasQue demostrarán que el programa funciona, en lugar de descubrirerrores. Desafortunadamente, los errores estarán presentes. Y si elingeniero de software no los encuentra !el cliente lo hará!

Estrategia de prueba del software. Visión general

Inicialmente la ingeniería de sistemas define el papel del softwarey conduce el análisis de los requerimientos del mismo, donde seEstablecen los criterios de dominio, función, comportamiento,Desempeño restricciones y validación de información para elSoftware. Al avanzar hacia adentro a lo largo de la espiral, se llegaal diseño y finalmente a la codificación. Para desarrollar softwareDe computadoras, se avanza en espiral hacia adentro(contra lasmanecillas del reloj) a lo largo de una línea que reduce el nivel deabstracción en cada vuelta.Una estrategia para probar el software también puede verse en elcontexto de la espiral .

La prueba de unidad comienza en el vértice de la espiral y seconcentra en cada unidad (por ejemplo, componente, clase o unobjeto de contenido de una webapp) del software como seimplemento en el código fuente. La prueba avanza al moversehacia afuera a lo largo de la espiral, hacia la prueba de integraciónDonde el enfoque se centra en el diseño y la construcción de laarquitectura del software. Al dar otra vuelta hacia fuera de laEspiral , se encuentra la prueba de validación, donde losRequerimientos establecidos como parte de su modelado sevalidan confrontándose con el software que se construyo.Finalmente , se llega ala prueba del sistema, donde el software yotros elementos del sistema se prueban como un todo.

Criterios para completar las pruebas

Cada vez que se analiza la prueba del software, surge una preguntaClásica: “¿Cuándo terminan las pruebas ?”,¿Cómo se sabe que se haprobado lo suficiente?”. Lamentablemente , no hay una respuestaDefinitiva a esta pregunta , pero existen algunas respuestasPragmáticas e intentos tempranos a manera de guía empírica.Una respuesta a la pregunta es: “nunca se termina de probar; lacarga simplemente pasa de usted (el ingeniero de software) alUsuario final". cada vez que el usuario ejecuta un programa decomputo, el programa se pone aprueba. Este instructivo subraya laimportancia de otras actividades a fin de garantizar la calidad delsoftware. otra respuesta (un tanto cínica, mas no obstante precisa)es: “ las pruebas terminan cuando se agota el tiempo o el dinero”.

Aspectos estratégicos

Una estrategia de software triunfará cuando quienes prueben elsoftware:

Especifican los requerimientos del producto en formacuantificable mucho antes de comenzar con las pruebas. Aunqueel objeto predominante de una prueba es encontrar errores,una buena estrategia de prueba también valor otrascaracterísticas de la calidad , como la portabilidad, elmantenimiento y la facilidad de uso. Esto debe especificarse enuna forma medible, de modo que los resultados de las pruebasno sean ambiguos.

Establecen de manera explicita los objetivos de las pruebas. Losobjetivos especificados de las pruebas pueden enunciarse entérminos medible. Por ejemplo, la efectividad de las pruebas, sucobertura, el tiempo medio antes de aparecer una falla, el costopor descubrir y corregir defectos. La densidad de defectosrestantes o la frecuencia de ocurrencia, y las horas de trabajode prueba deben enunciarse dentro del plan de la prueba.

Entienden a los usuarios del software y desarrollan un perfilpara cada categoría del usuario. Los casos de uso que describenel escenario de interacción para cada clase de usuario puedenreducir el esfuerzo de prueba global al enfocar las pruebas enel uso real del producto.

Desarrollan un plan de prueba que enfatice “prueba de ciclorápido”. Recomienda que un equipo de software “aprenda aprobar enciclos rápidos (2 por ciento del esfuerzo proyecto) de cliente-Utilidad al menos la ‘comprobabilidad’ en campo, losincrementos de funcionalidad y/o la mejora de la calidad”. Laretroalimentación Generada a partir de estas pruebas de ciclorápido puede usarse para controlar niveles de calidad y lascorrespondientes estrategias de prueba.

Construyen software “robusto” que esté diseñado para probarsea si mismo. El software debe diseñarse en forma que usetécnicas anti errores es decir, el software debe poderdiagnosticar ciertas clases de errores. Además el diseño debeincluir pruebas automatizadas y pruebas de regresión.

Usan revisiones técnicas efectivas como filtro previo a laspruebas. Las revisiones técnicas pueden ser tan efectivas comoprobar para descubrir errores. Por esta razón, las revisionespueden reducir la cantidad del esfuerzo de pruebas que serequieren para producir software de alta calidad.

Realizan revisiones técnicas para valorar la estrategia deprueba y los casos de prueba. Las revisiones de prueba puedendescubrir inconsistencias, omisiones y errores evidentes en elabordaje de las pruebas. Esto ahorra tiempo y también mejorala calidad del producto.

Desarrollan un enfoque de mejora continuo para el proceso deprueba. La estrategia de pruebas debe medirse. Las métricasrecopiladas durante las pruebas deben usarse como parte deun enfoque de control de proceso estadístico para la prueba delsoftware.

Estrategias de prueba para software convencional

Existen muchas estrategias que pueden usarse para probar elsoftware. En un extremo, puede esperarse hasta que el sistema esté completamente construido y luego realizar las pruebas sobre el sistema total, con la esperanza de encontrar errores. Esteenfoque, aunque atractivo, simplemente no funciona. Dara comoresultado software defectuoso que desilusionará a todosParticipantes. En el otro extremo, podrían realizarse pruebasdiariamente, siempre que se construya alguna parte del sistema.Este enfoque, aunque menos atractivo para muchos, puede sermuy efectivo. Por desgracia, algunos desarrolladores de softwareson reacios a usarlo.

Prueba de unidad

La prueba de unidad enfoca los esfuerzos de verificación en launidad más pequeña del diseño de software: el componente omodulo de software. Al usar la descripción del diseño decomponentes como guía, las rutas de control importantes seprueban para descubrir errores dentro de la frontera del modulo.larelativa complejidad de las pruebas y los errores quedescubren están limitados por el ámbito restringido que seestablece para la prueba de unidad. Las pruebas de unidad seenfocan en la lógica de procesamiento interno de las estructuras dedatos dentro de las fronteras de un componente. Este tipo depruebas puede realizarse en paralelo para múltiples componentes.

Consideraciones de las pruebas de unidad

Las pruebas de unidad se ilustran de manera esquemática , lainterfaz del modulo Se prueba para garantizar que la informaciónfluya de manera adecuada hacia y desde la unidad de software que se está probando. Las estructuras de datos locales se examinanpara asegurar que los datos almacenados temporalmente mantienen su integridad durante todos los pasos en la ejecuciónde un algoritmo. Todas las rutas independientes a través de laestructura de control se ejercitan para asegurar que todos losestatutos en un modulo se ejecuten al menos una vez.

Procedimientos de prueba de unidad

Las pruebas por lo general se consideran como adjuntas alpaso de codificación. El diseño de las pruebas de unidadpueden ocurrir antes de comenzar la codificación o después degenerar el código fuente: la revisión de la información deldiseño proporciona una guía para establecer casos de prueba que es probable que descubran errores en cada una de lasCategorías analizadas anteriormente. Cada caso de prueba debeacoplarse con un conjunto de resultados esperados.Puesto que un componente no es un programa independiente, confrecuencia debe desarrollarse software controlador y/o deresguardo para cada prueba de unidad. En la mayoría de lasAplicaciones un controlador no es mas que un “programaprincipal” que acepta datos de caso de prueba pasa tales datos alcomponente (que va a ponerse a prueba) e imprime resultados relevantes.

Pruebas de integración

Un neófito en el mundo del software podrá plantear una preguntaaparentemente legitima una vez que todos los módulos se hayan probado de manera individual: “si todos ellos funcionanIndividualmente, ¿Por qué dudan que funcionará cuando se juntentodos?”. Desde luego el problema es “juntarlos todos”: conectarlos. Los datos pueden perderse atreves de una interfaz; uncomponente puede tener un inadvertido efecto adverso sobreotro; la imprecisión aceptable individualmente puede magnificarse a niveles inaceptables ; las estructuras de datos globales puedenpresentar problemas. Lamentablemente, la lista sigue y sigue.

Las pruebas de integración son una técnica sistemática paraconstruir la arquitectura del software mientras se llevan a cabopruebas para descubrir errores asociados con la interfaz. Elobjetivo es tomar los componentes probados de manera individual y construir una estructura de programa que se haya dictado pordiseño. Con frecuencia existe una tendencia a intentar laIntegración no incremental, es decir a construir el programausando un enfoque de big bang.Todos los componentes se combinan por adelantado. todo programase prueba como un todo. !Y usualmente resulta el caos! Se descubre unconjunto de errores. La corrección se dificulta pues el aislamiento de las causas se complica por la vasta extensión de todo el programa. Una vez corregido estos errores, otros nuevos aparecen y el procesocontinua en un bucle aparentemente interminable.

Integración descendente

Es un enfoque incremental a la construcción de la arquitectura desoftware. Los módulos se integran al moverse hacia abajo a travésde la jerarquía de control, comenzando con el modulo de control principal(programa principal).los módulos subordinados almodulo de control principal se incorporan en la estructura enuna forma de primero en profundidad o primero en anchura.Con frecuencia la integración primero en profundidad integratodos los componentes sobre una ruta de control mayor de la estructura del programa.

Integración ascendente

Como su nombre lo implica, comienza la construcción y la pruebacon módulos atómicos (es decir, componentes en los nivelesinferiores dentro de la estructura del programa). Puesto que loscomponentes se integran de abajo hacia arriba, la funcionalidadque proporcionan los componentes subordinados en determinado nivel siempre está disponible y se elimina la necesidad derepresentantes (sus). Una estrategia de integración ascendentepuede implementarse con los siguientes pasos:

Los componentes en el nivel inferior se combinan en grupos (en ocasiones llamados construcciones o builds) que realizan unasubsunción de software específica.

Se escribe un controlador(un programa de control parapruebas) a fin de coordinar la entrada y salida de casos deprueba.

Se prueba el grupo.

Los controladores se remueven y los grupo se combinanmoviéndolos hacia arriba en la estructura del programa.

Prueba de regresión

Cada vez que agrega un nuevo modulo como parte de las pruebasde integración, el software cambia. Se establecen nuevas rutas deflujo de datos, ocurren nuevas operaciones de entrada/salida y seinvoca nueva lógica de control. Dichos cambios pueden causarproblemas con las funciones que anteriormente trabajaban sinfallas. En el contexto de una estrategia de prueba de integración, laprueba de regresión es la nueva ejecución de algún subconjunto de prueba que ya se realizaron a fin de asegurar que los cambios nopropagaron efectos colaterales no deseados. En un contexto masamplio, las pruebas exitosas (de cualquier tipo) dan comoresultado el descubrimiento de errores, y los errores debencorregirse. Siempre que se corrige el software , cambia algún aspecto de la configuración del software(el programa, su documentación o losdatos que sustenta).

Prueba de humo

La prueba de humo es un enfoque de integración que se usa cuandose desarrolla software de producto. Se diseña como un mecanismode ritmo para proyectos críticos en el tiempo, lo que permite alequipo del software valorar el proyecto de manera frecuente.En esencia, el enfoque de prueba de humo abarca las siguientesactividades:Los componentes de software traducidos en código se integran en una construcción. Una construcción incluye todos los archivos de datos, bibliotecas, módulos reutilizables y componentes sometidos a ingeniería que se requieren para implementar una o mas funciones del producto.

Se diseña una serie de pruebas para exponer los errores queevitaran a la construcción realizar adecuadamente su función.La intención debe ser descubrir errores “paralizantes” quetengan la mayor probabilidad de retrasar el proyecto.

La construcción se integra con otras construcciones, y todo elproducto (en su forma actual) se somete a prueba de humodiariamente. El enfoque de integración puede ser descendenteo ascendente.

Opciones estratégicas

Ha habido mucha discusión acerca de las relativas ventajas ydesventajas de las pruebas de integración descendente encomparación con las ascendentes. En general, las ventajas de unaestrategia tienden a ser desventajas para la otra. La principal desventaja del enfoque descendente es la necesidad de representantes y las dificultades de prueba que pueden asociarse con ellos los problemas asociados con los representantes puede compensarse con la ventaja de probar tempranamente lasprincipales funciones de control. La principal desventaja de laintegración ascendente es que “ el problema como entidad noexiste hasta que se agrega al ultimo módulo” . Este inconveniente se atempera con la mayor facilidad en el diseño de casos dePrueba y la falta de representantes.

Producto de trabajo de las pruebas de integración

Un plan global para integración del software y una descripción delas pruebas específicas se documentan en una especificación depruebas. Este producto de trabajo incorpora un plan de prueba yun procedimiento de prueba, y se vuelve parte de la configuracióndel software. La prueba se divide en fases y construcciones queabordan características del software funcionales y decomportamiento específicas. por ejemplo la prueba de integraciónpara el sistema de seguridad CasaSegura puede dividirse en lassiguientes fases de prueba:

Interacción con el usuario(entrada y salida de comandos,representación de despliegue, procesamiento y representaciónde errores)

Procesamiento de sensores (adquisición de salida de sensor,determinación de condiciones del sensor , acciones requeridascomo consecuencia de las condiciones)Funciones de comunicación( capacidad para comunicarse con laestación de monitoreo central)

Procesamiento de alarma(pruebas de acciones del software queocurren cuando cuando se encuentran una alarma)

Los siguientes criterios y pruebas correspondientes se aplican atodas las fases de prueba:Integridad de interfaz: las interfaces internas y externas se prueban conforme cada modulo(o grupo) se incorpora en la estructura.Validez funcional. Se realizan pruebas diseñadas para descubrir errores funcionales ocultos.

Contenido de la información. Se realizan pruebas diseñadas paradescubrir errores ocultos asociados con las estructuras de datoslocales o globales

Rendimiento. Se realizan pruebas diseñadas para verificar loslimites del rendimiento establecidos durante el diseño delsoftware.

Prueba de unidad en el contexto OO

Cuando se considera software orientado a objeto, el concepto deunidad cambia. La encapsulación determina la definición de clasesY objetos. Esto significa que cada clase y cada instancia de unaClase empaqueta los atributos (datos) y las operaciones quemanipulan estos datos. Por lo general, una clase encapsulada es elfoco de la prueba de unidad. No obstante, las operaciones(métodos) dentro de la clase son las unidades comprobables maspequeñas. Puesto que una clase puede contener unas operacionesdiferentes, y una operación particular puede existir como parte dealgunas clases diferentes, las tácticas aplicadas a la prueba deunidad debe cambiar. Ya no es posible probar una sola operaciónen aislamiento (la visión convencional de la prueba de unidad)sino mas bien como parte de una clase.

Prueba de integración en el contexto OO

Puesto que el software orientado a objeto no tiene una estructurade control jerárquico obvia, las estrategias tradicionales descendente y ascendente tiene poco significado. Además confrecuencia es imposible integrar las operaciones a a la vez en una clase (el enfoque de integración incremental convencional) debido alas “interacciones directa e indirecta de los componentes que construyen la clase” existen dos estrategias diferentes para laprueba de integración de los sistemas OO la primera la pruebabasada en hebra, integra el conjunto de clases requeridas pararesponder a una entrada o evento para el sistema. Cada hebra se integra y prueba de manera individual la prueba de regresión seaplica para asegurar que no ocurran efectos colaterales.

la prueba basada en uso, comienza la construcción del sistemaal probar dichas clases (llamadas clases independientes) queusan muy pocas clases servidor (si es que usan algunas).Después de probar las clases independientes, se prueba lasiguiente capa de clases llamadas dependientes, que usan lasclases independientes. Esta secuencia de probar capas declases dependientes continua hasta que se construye todo elsistema.

La prueba de grupo es un paso en la prueba de integración delsoftware OO. Aquí, un grupo de clases colaboradoras(determinadas al examinar el CRC y el modelo objetorelacional) se ejercita al diseñar casos de prueba que intentedescubrir errores en las colaboraciones.

Estrategias de prueba para webapps

Los siguientes pasos resumen el enfoque:El modulo de contenido para webapp se revisa para describirerrores.el modulo de interfaz se revisa para garantizar que todos loscasos de uso pueden adecuarse.El modulo de diseño para la weapp se revisa para descubrirerrores de navegación.La interfaz de usuario se prueba para descubrir errores en losmecanismos de presentación y/o navegación.A cada componente funcional se le aplica una prueba deunidad.Se prueba la navegación a lo largo de toda la arquitectura.

La webapp se implementa en varias configuracionesambientales diferentes y se prueba en su compatibilidad concada configuración.Las pruebas de seguridad se realizan con la intención deexplotar vulnerabilidades en la webapp o dentro de suambiente.Se realizan pruebas de rendimientoLa webapp se prueba mediante una población de usuariosfinales controlada y monitoreada. Los resultados de suinteracción con el sistema se evalúan por errores de contenidoy navegación, preocupaciones de facilidad de uso ,preocupaciones de compatibilidad, así como confiabilidad yrendimiento de la webapp.

Pruebas de validación

Las pruebas de validación comienzan en la culminación de laspruebas de integración , cuando se ejercitaron componentesindividuales, el software esta completamente ensamblado como un paquete y los errores de interfaz se descubrieron y corrigieron.En el nivel de validación o de sistema, desaparece la distinción entre software convencional, software orientado a objetos ywebapp. Las pruebas se enfocan en las acciones visibles para el usuario y las salidas del sistema reconocibles por el usuario.La validación es exitosa cuando el software funciona en una formaque cumpla con las expectativas razonables del cliente.

Criterios de prueba de validación

La validación del software se logra atreves de una serie de pruebasque demuestran conformidad con los requerimientos. un plan deprueba subraya las clases de prueba que se van a realizar y unprocedimiento de prueba define casos de prueba específicos quese diseñan para garantizar que: se satisfacen todos losrequerimientos de funcionamientos de funcionamiento, se lograntodas las características de comportamiento, todo el contenido espreciso y se presenta de manera adecuada, se logran todos losrequerimientos de rendimiento , la documentación es correcta y se satisfacen la facilidad de uso y otros requerimientos (por ejemplotransportabilidad, compatibilidad, recuperación de errores,mantenimiento).

Revisión de la configuración

Un elemento importante del proceso de validación es una revisión de la configuración. La intención de la revisión es garantizar quetodos los elementos de la configuración del software sedesarrollaron de manera adecuada , y que se cataloga y se tiene eldetalle necesario para reforzar las actividades de apoyo.

Pruebas alfa y beta

Virtualmente es imposible que un desarrollador de softwareprevea como usara el cliente realmente un programa. Lasinstrucciones para usarlo pueden malinterpretarse; regularmentepueden usarse combinaciones extrañas de datos; la salida queparecía clara a quien realizo la prueba puede ser ininteligible paraun usuario. Cuando se construye software a la medida para uncliente, se realiza una serie de pruebas de aceptación a fin depermitir al cliente validar todos los requerimientos.

La prueba alfa se lleva acabo en el sitio del desarrollador por ungrupo representativo de usuarios finales. El software se usa en unescenario natural con el desarrollador “mirando sobre el hombro” delos usuarios y registrando los errores y problemas de uso. Las pruebas alfa se realizan en un ambiente controlado.

La prueba beta se realiza en uno o mas sitios del usuario final.A diferencia de la prueba alfa, por lo general el desarrollador noesta presente. Por tanto la prueba beta es una aplicación “en vivo” del software en un ambiente que no puede controlar eldesarrollador. El cliente registra todos los problemas (reales oimaginarios) que se encuentran durante la prueba beta y losreporta al desarrollador periódicamente. Como resultado de losproblemas reportados durante las pruebas beta, es posible hacermodificaciones y luego preparar la liberación del producto desoftware a toda la base de clientes.

Pruebas de recuperación

Muchos sistemas basados en computadoras deben recuperarse de fallas y reanudar el procesamiento con poco o ningún tiempo deinactividad. En algunos casos, un sistema debe ser tolerante a lasFallas, es decir, las fallas del procesamiento no deben causar el cese del funcionamiento del sistema global. En otros casos, la falla deun sistema debe corregirse dentro de un periodo de tiempoespecifico u ocurran severos daños economicos. La recuperación es una prueba del sistema que fuerza al software a fallar en variasFormas y que verifica que la recuperación se realice de maneraadecuada. Si la recuperación es automática (realizada por elsistema en si), se evalúa el reinicio, los mecanismos de puntos deVerificación, la recuperación de datos y la reanudación para correcciones.

Pruebas de seguridad

La penetración abarca un amplio rango de actividades: hackers que intentan penetrar en los sistemas por deporte, empleadosresentidos que intentan penetrar por venganza, individuosdeshonestos que intentan penetrar para obtener ganacia personal ilícita. La prueba de seguridad intenta verificar que losmecanismos de protección que se construyen en un sistema enrealidad lo protegeran de cualquier penetración impropia. “ laseguridad del sistema debe, desde luego , probarse para serinvulnerable ante ataques frontales; pero también debe probarse su invulnerabilidad contra ataques laterales y traseros.”

El proceso de depuración

El proceso de depuración comienza con la ejecución de un caso de prueba. Los resultados se valoran y se encuentra la falta deCorrespondencia entre el rendimiento esperado y el real. Enmuchos casos, la no correspondencia de los datos es un síntoma de una causa subyacente y escondida. El proceso de depuraciónintenta relacionar síntomas con causa, lo que por tanto conduce a la corrección del error. Por lo general, el proceso de depuracióndará como resultado que: 1) la causa se encontrará y corregirá o 2)la causa no se encontrará.

Corrección de errores

Una vez encontrado el error, debe corregirse. Pero, como ya seseñaló, la corrección de un error puede introducir otros errores y por tanto, hacer más daño que bien. Van vleck sugiere sugiere tres preguntas simples que deban plantearse antes de hacer la“corrección” que remueva la causa de un error:

¿la causa del error se produce en otra parte del programa? Enmuchas situaciones , un defecto de programa es causado por unpatrón de lógica erróneo que puede producirse en alguna otraparte. La consideración explicita del patrón lógico puederesultar en el descubrimiento de otros errores.

¿Qué “siguiente error” puede introducirse con la corrección queesta a punto de realizar? Antes de hacer la corrección, debeevaluarse el código fuente (o, mejor, el diseño) para valorar elacoplamiento de las estructuras lógica y de datos. Si lacorrección se realizará en una sección altamente acoplada delprograma, debe tenerse especial cuidado cuando se realicealgún cambio.

¿Qué debió hacerse para evitar este error desde el principio? Estapregunta es el primer paso hacia el establecimiento de unenfoque de aseguramiento de calidad estadística del software sise corrigen tanto el proceso como el producto, el error seremoverá del programa actual y podrá eliminarse de todos losprogramas futuros.

GRACIAS PUBLICO