Introduccin.

La prueba de software es un conjunto de herramientas, tecnicas y mtodos que hacen a la excelencia del desempeo de un programa, asi como tambien la mejor publicidad que una empresa dedicada a la produccin de software pueda tener. Las tecnicas para encontrar problemas en un programa son extensamente variadas y van desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas que ayudan a aliviar el peso y el costo de tiempo de esta actividad. Pero de nada servira conocer todas las tecnicas de prueba de software, si un programa carece de documentacin, el cdigo es confuso, o no se han seguido pasos para la planificacin y desarrollo del software, ya que seria como buscar una aguja en un pajar. Es por eso que en este trabajo monogrfico nos hemos volcado a definir no solo las herramientas, tecnicas y metodos de prueba sino que tambin a todo el trabajo previo de control de calidad en el desarrollo de software, ya que sabemos que mucho mejor que encontrar y solucionar un problema es prevenir que no ocurra. Que es el control de calidad del software ? El control de calidad del software incluye desde el monitoreo de desarrollo de procesos haciendo respetar los estandares y procedimientos concordados asegurandose un buen seguimiento de programa y la deteccion y correccion de errores. El control de calidad del software esta orientado a la prevencin.

 Que es prueba de software ? La prueba de software involucra las operaciones del sistema bajo condiciones controladas y evaluando los resultados. Las condiciones controladas pueden ser normales o anormales. La prueba puede intencionalmente esforzar al programa y producir errores en las respuestas para determinar si los sucesos ocurren cuando no tendran que ocurrir o cuando los hechos no suceden cuando deberan suceder. La prueba de software esta detectada a la deteccion. La mayora de las grandes organizaciones asumen la responsabilidad del control de calidad y prueba de software a tal medida que en la produccin se incluyen desarrolladores de sistemas (analistas , programadores) y un grupo dedicado a la prueba de software para que estos grupos antes mencionados trabajen en conjunto cumpliendo el control de calidad (prevencin) y la prueba de software (deteccion) logrando una tarea exitosa. Fallos mas recientes causados por software con bugs en sistemas de computacin : En enero del 2000 se registro la mayor cantidad de fallas de sistemas, en organizaciones europeas, de todos los tiempos al sufrir las consecuencias del efecto Y2K (Y2K bug). Como por ejemplo el sistema de trenes se vio afectado al no reconocer la fecha 010100 y los trenes no salieron o salieron a destiempo, de la misma manera se produjeron problemas de comunicacin en correos electrnicos en aquellos sistemas que utilizaban agenda de pedidos o informes que se enviaban automticamente en cada fecha. Otro problema fue causado en una escuela publica de los Estados Unidos donde alrededor de 100.000 estudiantes solicitaron la inscripcin y el sistema no contemplaba el manejo de tal cantidad de inscriptos causando errores en

las tarjetas de reportes de los alumnos inclusive inscriptos en otros aos y en el sistema de registros de materias. Esta escuela decidi reinstalar el sistema viejo de hace 25 aos hasta que los bugs del sistema hayan sido corregidos. En octubre de 1999 un modulo de la nave espacial para el estudio de Marte valuado en 125 Millones de dlares fue perdido en el espacio debido a un simple error de conversin de datos. Fue ciertamente determinado que el software de la nave utilizaba datos en el sistema mtrico ingles , el error fue causado cuando se ejecutaban procesos concurrentes donde uno de ellos estableca comunicacin para el descenso en el sistema mtrico ingles y el otro proceso calculaba los parmetros de rbita con otro tipo de unidades, entonces estos dos procesos utilizaron el mismo procedimiento para la conversin de datos, aunque no se ha determinado que modulo del sistema causaron el bug. Un bug en le programa de soporte de una red comercial de alta velocidad afecto 70.000 negocios de clientes por el periodo de 8 idas en agosto de 1999, entre los afectados fue la empresa Electronic Trading System Futures Exchange , la cual tuvo que suspender sus tareas. Esto fue causado per el repentino paro del programa de soporte en este sistema Non Stop. Porque es tan difcil para el desarrollo de sistemas incluir seriamente un control de calidad y una buena prueba de errores ? Resolver los problemas cuando se presentan es un proceso fcilmente determinado, pero prevenir problemas es una tarea muy minuciosa y muy difcil de determinar. En la antigua china exista una familia de curadores , uno de los integrantes de esta familia siendo ya muy reconocido fue contratado por uno de los grandes Seores del territorio como su medico personal. Una noche mientras cenaban el Seor le pregunta al medico cual de sus otros familiares era tan poderoso como el, entonces el medico comento; Yo atiendo a personas con grandes males, casi moribundos llegan a mi con cierta fe, y algunas veces logro curarlos, y mi nombre es reconocido en casi todo el territorio. Mi hermano mayor cura las enfermedades cuando recin comienzan a hacer raz en el cuerpo y su nombre es reconocido en los vecindarios, mi hermano menor cura enfermedades antes de que aparezcan y solo es conocido por la 3

familia y su nombre no ha salido de la casa. Es decir, arreglar o corregir un problema o bug despus que sale a la luz es una tarea relativamente sencilla, ya que se conoce el foco del problema, el inconveniente esta en corregir un error que no esta visible o no ha sucedido todava. Cuales son las razones para que un programa contenga bugs? Poca o falta de comunicacin entre diferentes aplicaciones.(Requerimientos de las aplicaciones.) Complejidad del software. Causa dificultad en la reutilizacin de cdigo y generalmente requiere personas con experiencia en desarrollo de sofware modernos como por ejemplo en sistemas cliente servidor, aplicaciones distribuidas, comunicacin de datos, manejo de enormes bases de datos relacionales y un gran manejo de tecnicas orientadas a objetos. A veces estos conocimientos tambin pueden causar mas errores de los que corrigen. Errores de programacion. Los programadores son uno de los principales factores en la causa de errores o bugs. Requerimiento de cambio en el sistema. El rediseo y la replanificacin causan efectos en otros proyectos que trabajan en conjunto o a partir de resultados del sistema modificado. Estos procesos cooperativos generan mas complejidad en las diferentes pruebas y en el control y generalmente el entusiasmo de los desarrolladores del sistema se ve afectado al tener que realizar actividades diferentes o no correspondientes a su labor. Como por ejemplo el de los ingenieros al tener que hacer un anlisis funcional a partir de su planificacin, todo esto influye y atenta con la integridad del programa y genera riesgos de una gran cantidad de errores. Presiones de tiempos. Una buena planificacin y un buen anlisis con sus

respectivos controles de calidad y prueba se ven afectados por un lapso corto de tiempo para que esto sea completo. La falta de tiempo generalmente conlleva a no considerar u omitir ciertas fases de prueba y control. El ego (aspecto psicolgico del personal).A veces la situacin y el contexto lleva a que la gente diga: No hay problema Es muy fcil. Puedo terminar esto en pocas horas. No habr inconvenientes en adaptar ese viejo cdigo. en vez de decir: Eso es muy complejo. Nos llevara a cometer varios errores. No puedo estimar cuanto tiempo me llevara este trabajo. No se como readaptar ese cdigo. Son muchas las ocasiones en las que un No hay problema genera un bug. Pobre documentacin del cdigo. Es difcil poder modificar cdigo cuya documentacin es escasa o esta mal escrita. En muchas organizaciones los directivos no incentivan a los programadores a realizar una buena documentacin e incluso a no darle importancia a la entendibilidad del cdigo, como tambin el hecho de incentivar demasiada seguridad en la documentacin y escritura del cdigo. Lo que fue difcil de escribir podra llegar a ser difcil de leer y aun mas complicado de modificarlo. Herramientas de desarrollo de software. Herramientas visuales , libreras de clases, compiladores, herramientas de escritura, etc., a menudo introducen cdigo extra con pobre documentacin lo cual genera un bug en el programa en cuestion.

 Cmo un nuevo software con control de calidad puede ser introducido en una organizacion existente ? Depende del tamao de la organizacion y de los riesgos involucrados. Para grandes organizaciones con altos niveles de riesgos en trminos de capital y vida evolutiva de la empresa un serio manejo de control de calidad es absolutamente necesario por lo que un nuevo software debe garantizar una muy buena seguridad y cumplir con lo formalizado. En organizaciones donde los riesgos son menores la implementacin con control de calidad puede ir disminuyendo su intensidad con el tiempo sin que la organizacion con el tiempo. Esta falta de procesos con control de calidad podra ser equilibrada con mayor productividad eliminando niveles de burocracia. Para pequeos proyectos el control de calidad de procesos puede ser enfocado a partes especificas del sistema dependiendo del tipo de organizacion o de clientes, aunque es importante asegurar una adecuada comunicacin entre desarrolladores y personal ocupado de la prueba de programa asegurando tambin una retroalimentacin del sistema optimizando la relacin cliente empresa. En todo los casos, lo mas valioso es el esfuerzo en la prueba de software y un control de calidad del sistema garantizando buena especificacin y cumpliendo con las expectativas pero generalmente el desempeo y los requerimientos de la empresa principalmente el factor tiempo hacen que las pruebas de software y controles sean limitadas. Que es verificacin y validacin ? La verificacin tpicamente incluye por parte de los desarrolladores la revisin de los planes, del cdigo, de los requerimientos, de la documentacin y las especificaciones y posteriormente una reunin con los usuarios para evaluar dichos documentos. Esto puede ser hecho con listas de chequeos, listas de problemas, walkthrough.

La validacin tpicamente incluye las pruebas del software y comienza despus que la verificacin este completa. Este proceso de verificacin y validacin da lugar al termino IV&V Independent verification and validation. Que es walkthrough ? Es una reunin informal entre analistas y usuarios para la evaluacin de propuestas informacionales, generalmente es requerida una pequea preparacin de documentos. Que es la inspeccin ? La inspeccin es una reunin formal luego del walkthrough, generalmente incluye personal de diferentes sectores esencialmente analistas, programadores, y personal de prueba (testers) donde acuerdan con los usuarios los metodos de seguridad prueba a llevar a cabo. A menudo en estas reuniones se incluye un moderador el cual representa a la empresa y que da a conocer al usuario una lista de operaciones de metodos de prueba y controles de calidad en las cuales el usuario debe optar definiendo el mismo el nivel de calidad. Que tipos de prueba de programa deben ser considerados ? Caja negra. No esta basada en el conocimiento del cdigo o diseo interno, determina la funcionalidad del sistema. Caja blanca. Esta basada en la lgica interna de la aplicacion y el cdigo. Hace una cobertura de declaraciones del cdigo, ramas, caminos y condiciones. Unidad de testeo o prueba. Es la escala mas pequea de la prueba, esta basada en la funcionalidad de los mdulos del programa, como funciones, procedimientos, mdulos de clase, etc. En ciertos sistemas tambin se verifican o se prueban los drivers y el diseo de la arquitectura. Integracin incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basndose en la funcionalidad, la dependencia con otros mdulos y la integracin con el programa completo. 7

Prueba de integracin. Se basa en las pruebas de conexiones y comunicaciones entre diferentes mdulos. Es esencial en sistemas de cliente_servidor o red. Prueba funcional. La caja negra hace la prueba funcional de los requerimientos de la aplicacion y generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los testers. Prueba de sistema. Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentacin. Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interaccin con otros hardwares, bases de datos y redes. Prueba de sanidad. Determina si la nueva versin de un software esta bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versin de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no esta en una condicin sana. Prueba de regresin. Es una nueva revisin en las pruebas del programa luego de que este haya sufrido algn cambio o por apuros de tiempo o la modificacin fue en el ambiente en que se desenvuelve. Actualmente aparecieron herramientas automatizadas que hacen que este tipo de pruebas no lleve demasiado tiempo. Prueba de aceptacin. Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo. Prueba de carga. Esta basada en las aplicaciones bajo cargas pesadas , generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.

Prueba de estrs. Es una prueba de carga y perfomance basada en la funcionalidad del sistema bajo cargas pesadas , un gran numero de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de datos grandes. Prueba de perfomance. Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrs. Incluye entrevistas con el usuario y programador. Prueba de instalacin y desinstalacin. Determina la eficiencia de los procesos que instalan y desinstalan las aplicaciones del programa. Prueba de recuperacion. Es la prueba que evala que tan bien se recupera el sistema luego de bloqueos , fallas del hardware u otros problemas catastrficos. Prueba de seguridad. Evala que tan bien el sistema se protege contra accesos , internos o externos, no autorizados, esta prueba requiere sofisticadas tecnicas y herramientas. Prueba de compatibilidad. Evala el desempeo del software en diferentes hardwares , sistemas operativos , redes, etc. Prueba de exploracin. Es una prueba informal del software que no esta basada en ningn plan o caja de prueba y a menudo los testers aprenden del programa al explorar todas las aplicaciones posibles. Prueba de anuncio. Es similar a la prueba de exploracin pero los testers deben tener suficiente nocin sobre el funcionamiento del programa antes de comenzar esta prueba. Incluye reunin con analistas y programadores. Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente con el programa. Prueba de comparacin. En esta prueba se comparan los pro y los contra del

programa con los programas creados con la competencia. Prueba alfa. Es la prueba cuando la aplicacion esta cerca de la entrega al usuario. Se hacen pequeos cambios generalmente en el diseo de interfaces. Esta prueba es hecha por usuarios. Prueba beta. Es la bsqueda de bugs en el programa completo. Generalmente es hecha por usuarios. Prueba de mutacin. Esta prueba esta basada en la introduccin deliberada de diferentes cdigos externos al programa (bugs) para reexaminar si estos bugs pueden ser detectados. Requiere gran disponibilidad de recursos de computacin. Cuales son los cinco problemas mas comunes en el desarrollo de procesos. ? Pobre definicin de requerimientos. Es normal que se comience a trabajar en base a requerimientos que estan en bruto, si no hay una buena prueba de requerimientos con el usuario se crearan problemas. Planificacin irreal. Planifica sobre supuestos para acortar el tiempo de desarrollo, los problemas sern inevitables. Pruebas inadecuadas. Es imprescindible asegurarse que el programa funciona antes de la entrega al usuario. Falta de comunicacin. Si desarrolladores de programas, clientes o usuarios y directivos del proyecto tienen una mala o escasa comunicacin los problemas estarn garantizados. Carencia de rasgos. Definir nuevos rasgos una vez que el programa se haya terminado es muy comn y genera problemas. Se deben definir las caractersticas del programa. Cuales son las cinco soluciones para los problemas de desarrollo?

10

Requerimientos slidos. Deben ser claros, completos, detallados, probables, posibles, cohesivos y coherentes. Son imprescindibles los prototipos para que se cumplan estas condiciones. Planificacin real. Se debe ser sincero y dedicar el tiempo adecuado a la planificacin. Esto agilizara el diseo, la prueba y dara tiempo a posibles cambios. Pruebas adecuadas. Las pruebas deben ser tempranas y adecuadas durante el desarrollo pudiendo establecer puntos de prueba (checkpoints) en caso de cambios, y pruebas finales una vez concluido el programa. Comunicacin continua. Con la tecnologa existente hoy en dia, un buen profesional debe poder utilizar todas las herramientas posibles, desde telfonos celulares, email, hasta reuniones formales e informales en los diferentes mbitos que conciernan al desarrollo del software. Seguimiento de rasgos. Es deseable realizar una buena preparacin de las caractersticas a seguir por el programa. Interfaces, salidas, equipos etc. Una buena prototipacin de las entradas y salidas es lo ideal para defenderse de posibles cambios y potenciales problemas. Cmo realizar un buen cdigo? Un Buen cdigo es aquel que funciona sin bugs, adems debe ser legible y mantenible, se debe ajustar a los estandares de la organizacion para que todos los desarrolladores del sistema manejen y entiendan las mismas herramientas y mecanismos en la codificacin. A continuacin definiremos reglas que la mayora de las organizaciones consideran importantes para evitar problemas en la mayora de los lenguajes de programacion mas usados como el C, C++. Minimizar el uso de variables globales. Nombres descriptivos de funciones, variables, mdulos, objetos y metodos. Minimizar el tamao de funciones, metodos y procedimientos. Acercamiento al caso ideal de no exceder las 50 lneas. Descripciones deben ser cortas y claras para no confundir la lectura del cdigo. Organizacion de los metodos, una buena disposicin del cdigo har que futuros cambios sean posibles. Uso generoso de espacios en blanco. Es importante que cada lnea de cdigo no supere los 70 caracteres. Una sentencia por lnea. Es fundamental que el grupo de desarrolladores respete el mismo estilo de codificacin. Toda aplicacion debe ser documentada no importa lo pequea sea dicha aplicacion. Cmo pueden las nuevas herramientas automatizadas de prueba simplificar el proceso de deteccion de 11

errores ? Una de las herramientas automatizadas que a logrado ser muy popular en el entorno del diseo de software, por su simplicidad y, adems, por el ultimo gran disgusto en cuestion a problemas de software, el efecto Y2K, es la herramienta RECORDPLAYBACK, al ejecutar dicha aplicacion antes de hacer correr el programa a probar, se activa la opcin rcord, el tester navega por las diferentes aplicaciones del software, mens, cuadros de dialogo, plantillas, tablas, botones, y los resultados son grabados en forma de texto para un reporte, y en el lenguaje de la herramienta en un archivo de grabado, cuando nuevas aplicaciones son agregadas al software o son modificadas las aplicaciones actuales, la opcin playback de la herramienta navega automticamente por el programa y luego emite un reporte de resultados y operaciones aun no testeadas. Otras herramientas automatizadas existentes en el mercado son: Analizador de cdigo. Es una especie de depurador externo que examina adems de las sentencias, los caminos e hilos del programa. Analizador de cobertura. Solamente prueba las ramas y caminos de todas las funciones que trabajan, internamente o externamente, con el programa. Analizador de memoria. Evala si las aplicaciones no exceden los limites de memoria en los peores casos, o situaciones criticas. Perfomance de carga. En sistemas cliente servidor, esfuerza al programa para que trabaje con cargas pesadas y en situaciones extremas. Analizador de sitios WEB. Examina los enlaces y las aplicaciones en los diferentes nodos y en el servidor. Reporte de bugs. Trabaja en conjunto con analizadores de cdigo y de

12

cobertura, haciendo un reporte de las partes de cdigos no examinadas o confusas. Reporte de configuracin. Hace un reporte de los requerimientos del programa en cuestion a hardware y los parmetros mnimos que se deben cumplir para que el software pueda trabajar al mximo. Reporte de desempeo. Hace un reporte del nivel de desempeo, aplicacion por aplicacion, del programa en el hardware instalado. Estudio de tecnicas de prueba basicas. Hoy en dia, la mayor parte de las tecnicas de prueba se basan en las tecnicas aparecidas en los aos 70, dandole fundamental importancia los avances tecnologicos, los avances en lenguajes de programacion y la gran variedad de tipos de software, las pruebas de caja negra y caja blanca han tomado un lugar muy importante en el desarrollo de sistemas de cualquier tipo, tanto que sin dichas pruebas un sistema desarrollado careceria de garantias y credibilidad en sus resultados. Prueba de caja negra Esta prueba implica una variada seleccion de los datos de prueba asi como una buena interpretacion de los resultados para determinar el nivel de optimizacion de la funcionalidad del sistema. Se ha determinado con diferentes estudios estadisticos, que el software no debe ser probado por el creador o grupo de creadores del sistema ya que el extenso conocimiento de la estructura interna del programa limita la variedad de datos probados o el encaminamiento de las pruebas es hacia ciertos rasgos del programa olvidando otras partes del software poco valoradas por su simpleza en la creacion. Segun C. Kaner en su libro Testing Computer Software de 1993, el aspecto humano es esencial en la prueba de caja negra aplicando factibles sucesos de la vida

13

real a la prueba, errores de tipeo, trabajar en aplicaciones equivocadas creyendo trabajar en la aplicacion deseada, etc., pero sucede que los programadores han pasado tanto tiempo en la creacion del sistema y al ser la prueba de caja negra una de las mas tempranas sus hechos factibles de la vida real estan entre el begin y el end de cada aplicacion. La prueba de caja negra ha hecho que cada organizacion dedicada al desarrollo de software contemple dentro de ella un departamento especial dedicado a las pruebas. El principal objetivo es determinar la funcionalidad del software y parte de tratar al programa como si fuera una funcion matematica, estudiando si las respuestas o salidas son codominio de los datos entrantes dominio. La prueba de caja negra tiene otras metas, determinar la eficiencia del programa desde el desempeo en el equipo, el tiempo de retardo de las salidas hasta el nivel de recuperacion del sistema luego de fallas o caidas sean estas producidas por manejo incorrecto de datos, equipo, o producidas externamente como cortes de energia. La prueba de caja negra debe cubrir el espectro entero de sucesos factibles, de esto se debe ocupar el departamento de prueba, pero nunca se sabe si se han cubierto todos los casos o gran parte de ellos, no olvidemos que los testers pertenecen a la organizacion por lo que la prueba de caja negra no termina una vez que salio del laboratorio. La prueba con intervencion del usuario es un pequeo periodo de tiempo en el cual el usuario bajo el asesoramiento de testers, se desenvuelve en el software y examina la operabilidad de los datos que el maneja. El usuario dara la puntada final en la cuestion de datos de prueba. Esta parte de la prueba no podra hacerse sin que el usuario haya tenido previo contacto con los prototipos del sistema, y para los testers una efectiva interaccin con

14

herramientas CASE. Prueba de caja blanca Para esta prueba se consideran tres importantes puntos. I) Conocer el desarrollo interno del programa, determinante en el anlisis de coherencia y consistencia del cdigo. II) Considerar las reglas predefinidas por cada algoritmo. III) Comparar el desarrollo del programa en su cdigo con la documentacin pertinente. La primera parte de esta prueba es el anlisis esttico. Anlisis esttico Manual Inspeccin : Determina si el cdigo esta completo y correcto, como tambin las especificaciones. Walkthrough : Interrelacin informal entre testers, creadores y usuarios del sistema. Anlisis esttico Automtico Verificacin esttica : Compara los valores generados por el programa con los rangos de valores predefinidos haciendo una descripcin del funcionamiento de los procedimientos en trminos booleanos determinando los puntos de falla. Ejecucin simblica : Hace un seguimiento de la comunicacin entre funciones, mdulos, aplicaciones, luego de que todas las partes hayan sido verificadas por separado. La segunda parte de esta es el anlisis dinmico. Para esto se cuenta con diferentes tipo de herramientas. Anlisis de cobertura : Examina las extensiones del cdigo, haciendo una caja blanca por modulo. Trafico : Sigue todos los caminos de comunicacin entre mdulos guardando los valores de las variables en cada uno de ellos. 15

Simulador : Simula partes del sistema para el cual el hardware no esta habilitado. Sintona : Testea los recursos utilizados durante la ejecucin del programa. Prueba de certeza : Examina las construcciones lgicas del programa. Generacin de datos de prueba. La seleccion de datos de prueba es una de las mas importantes disciplinas dentro de la caja blanca. Usualmente se generaban en forma aleatoria y hacan un acercamiento a una sofisticada prueba estructural determinando el desempeo de los mdulos con dichos valores. A partir del gran colapso causado por el efecto Y2K han aparecido en el mercado herramientas automatizadas que generan datos de prueba y que, adems examinan paso a paso la ejecucin del programa. Que cosas hacen a un buen ingeniero en pruebas y control de calidad ? El ingeniero debe tener una actitud de probar para romper, o sea, la habilidad de conseguir el punto de vista del cliente y un buen anlisis de detalle para encontrar errores que no se ven a simple vista. Aunque no parezca importante, la actitud de trabajo en equipo, la diplomacia con usuarios , desarrolladores y ejecutivos dar a este la nocin de los focos de prueba mas importantes cuando el tiempo de prueba es extremadamente limitado y los riesgos de un mal control son altos. Un buen ingeniero dedicado a esta disciplina debe ser paciente y tener la habilidad de saber encontrar los problemas y las omisiones. Pasos para el desarrollo de pruebas : Obtener los requerimientos en forma clara. Obtener planificacin de diseo.

16

 Determinar funcionalidad. Identificar aplicaciones de alto riesgo o con prioridad de prueba. Determinar metodos de prueba. Determinar contexto de la prueba. Obtener datos de prueba. Estimar tiempo de prueba. Clasificar errores del programa. Documentar errores del programa. Redactar los casos de prueba que encontraron fallas. Aprobar una revisin en la prueba. Evaluar resultados en reportes. Buscar bugs. Volver a probar si es necesario. Actualizar el plan de prueba. Cmo se define un plan de prueba ? Titulo Identificacin, nmeros de versin, creador, fecha de creacion. Tabla de contenidos. Reportes de reuniones. Reportes de requerimientos. Reportes de documentacin. Anlisis de riesgos. Prioridades y focos de prueba. Limites. (tiempo, riesgos, etc.) Reporte de datos de prueba. Reporte de resultados.

17

 Reporte de aplicaciones conjuntas al programa. Informe de herramientas automatizadas. Determinacin de la sanidad del programa. Personal implicado. Reportes relevantes. (Licencias, clasificaciones, metodos, etc.) Apndices, glosario, cronologa. Bibliografia. Revista Programacion Actual Prueba de Software y Seguridad en entornos distribuidos M. Vasquez C. Falcato Editorial Prensa Tecnica S. L. Espaa Material de Internet Computer Organization (Computer.org) Testing Computer Software C. Kaner Software Testing in the Real World E. Kit Software Engineering R. Pressman Practical Testing Advice Diomidis Spinellis 1

18