Introducción.

La prueba de software es un conjunto de herramientas,

tecnicas y métodos que hacen a la excelencia del desempeño

de un programa, asi como tambien la mejor publicidad que

una empresa dedicada a la producción 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 serviría conocer todas

las tecnicas de prueba de software, si un programa carece de

documentación, el código es confuso, o no se han seguido

pasos para la planificación y desarrollo del software, ya que

seria como buscar una aguja en un pajar.

Es por eso que en este trabajo monográfico nos hemos

volcado a definir no solo las herramientas, tecnicas y metodos

de prueba sino que también 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 prevención.

¿ 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 tendrían que

ocurrir o cuando los hechos no suceden cuando deberían suceder.

La prueba de software esta detectada a la deteccion.

La mayoría de las grandes organizaciones asumen la responsabilidad del

control de calidad y prueba de software a tal medida que en la producción 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 (prevención) y la prueba

de software (deteccion) logrando una tarea exitosa.

Fallos mas recientes causados por software con bugs en sistemas de computación :

• 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 01-01-00 y los trenes no salieron o salieron a destiempo, de la misma

manera se produjeron problemas de comunicación en correos electrónicos en

aquellos sistemas que utilizaban agenda de pedidos o informes que se

enviaban automáticamente en cada fecha.

• Otro problema fue causado en una escuela publica de los Estados Unidos

donde alrededor de 100.000 estudiantes solicitaron la inscripción 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 años y en

el sistema de registros de materias.

Esta escuela decidió reinstalar el sistema viejo de hace 25 años 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 dólares fue perdido en el espacio debido a un

simple error de conversión de datos. Fue ciertamente determinado que el

software de la nave utilizaba datos en el sistema métrico ingles , el error fue

causado cuando se ejecutaban procesos concurrentes donde uno de ellos

establecía comunicación para el descenso en el sistema métrico ingles y el otro

proceso calculaba los parámetros de órbita con otro tipo de unidades, entonces

estos dos procesos utilizaron el mismo procedimiento para la conversión 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 difícil 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 fácilmente

determinado, pero prevenir problemas es una tarea muy minuciosa y muy difícil de

determinar.

En la antigua china existía una familia de curadores , uno de los integrantes de esta familia siendo ya muy reconocido fue contratado por uno de los grandes Señores del territorio como su medico personal. Una noche mientras cenaban el Señor 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 recién comienzan a hacer raíz 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 familia y su nombre no ha salido de la casa.

Es decir, arreglar o corregir un problema o bug después 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 todavía.

¿Cuales son las razones para que un programa contenga bugs?

• Poca o falta de comunicación entre diferentes aplicaciones.(Requerimientos

de las aplicaciones.)

• Complejidad del software. Causa dificultad en la reutilización de código y

generalmente requiere personas con experiencia en desarrollo de sofware

modernos como por ejemplo en sistemas cliente servidor, aplicaciones

distribuidas, comunicación de datos, manejo de enormes bases de datos

relacionales y un gran manejo de tecnicas orientadas a objetos. A veces estos

conocimientos también 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 rediseño y la replanificación

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 análisis funcional

a partir de su planificación, todo esto influye y atenta con la integridad del

programa y genera riesgos de una gran cantidad de errores.

• Presiones de tiempos. Una buena planificación y un buen análisis 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 psicológico del personal).A veces la situación y el contexto

lleva a que la gente diga:

- No hay problema

- Es muy fácil.

- Puedo terminar esto en pocas horas.

-No habrá inconvenientes en adaptar ese viejo código.

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 código.

Son muchas las ocasiones en las que un ¨ No hay problema ¨ genera un bug.

• Pobre documentación del código. Es difícil poder modificar código cuya

documentación es escasa o esta mal escrita.

En muchas organizaciones los directivos no incentivan a los programadores a

realizar una buena documentación e incluso a no darle importancia a la

entendibilidad del código, como también el hecho de incentivar demasiada

seguridad en la documentación y escritura del código. Lo que fue difícil de

escribir podría llegar a ser difícil de leer y aun mas complicado de modificarlo.

• Herramientas de desarrollo de software. Herramientas visuales , librerías de

clases, compiladores, herramientas de escritura, etc., a menudo introducen

código extra con pobre documentación lo cual genera un bug en el programa

en cuestion.

¿ Cómo un nuevo software con control de calidad puede ser introducido en una organizacion existente ?

Depende del tamaño de la organizacion y de los riesgos involucrados.

Para grandes organizaciones con altos niveles de riesgos en términos 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 implementación 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 podría ser

equilibrada con mayor productividad eliminando niveles de burocracia.

Para pequeños 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 comunicación entre

desarrolladores y personal ocupado de la prueba de programa asegurando también

una retroalimentación del sistema optimizando la relación 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 especificación y cumpliendo con

las expectativas pero generalmente el desempeño y los requerimientos de la empresa

principalmente el factor tiempo hacen que las pruebas de software y controles sean

limitadas.

¿ Que es verificación y validación ?

La verificación típicamente incluye por parte de los desarrolladores la revisión

de los planes, del código, de los requerimientos, de la documentación y las

especificaciones y posteriormente una reunión con los usuarios para evaluar dichos

documentos. Esto puede ser hecho con listas de chequeos, listas de problemas,

walkthrough.

La validación típicamente incluye las pruebas del software y comienza después

que la verificación este completa.

Este proceso de verificación y validación da lugar al termino ¨IV&V¨

Independent verification and validation.

¿Que es walkthrough ?

Es una reunión informal entre analistas y usuarios para la evaluación de propuestas informacionales, generalmente es requerida una pequeña preparación de documentos.

¿Que es la inspección ?

La inspección es una reunión 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 código o diseño interno,

determina la funcionalidad del sistema.

•Caja blanca. Esta basada en la lógica interna de la aplicacion y el código. Hace

una cobertura de declaraciones del código, ramas, caminos y condiciones.

•Unidad de testeo o prueba. Es la escala mas pequeña de la prueba, esta

basada en la funcionalidad de los módulos del programa, como funciones,

procedimientos, módulos de clase, etc. En ciertos sistemas también se

verifican o se prueban los drivers y el diseño de la arquitectura.

•Integración incremental. Cuando nuevas funciones son ingresadas al sistema

se hace la prueba basándose en la funcionalidad, la dependencia con otros

módulos y la integración con el programa completo.

•Prueba de integración. Se basa en las pruebas de conexiones y

comunicaciones entre diferentes módulos. 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 documentación.

•Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la

interacción con otros hardwares, bases de datos y redes.

•Prueba de sanidad. Determina si la nueva versión de un software esta bien

realizada y si necesita un nuevo esfuerzo en la prueba de software. Por

ejemplo la nueva versión 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 condición sana.

•Prueba de regresión. Es una nueva revisión en las pruebas del programa

luego de que este haya sufrido algún cambio o por apuros de tiempo o la

modificación 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 aceptación. 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 estrés. 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

estrés. Incluye entrevistas con el usuario y programador.

•Prueba de instalación y desinstalación. Determina la eficiencia de los

procesos que instalan y desinstalan las aplicaciones del programa.

•Prueba de recuperacion. Es la prueba que evalúa que tan bien se recupera el

sistema luego de bloqueos , fallas del hardware u otros problemas

catastróficos.

•Prueba de seguridad. Evalúa que tan bien el sistema se protege contra

accesos , internos o externos, no autorizados, esta prueba requiere

sofisticadas tecnicas y herramientas.

•Prueba de compatibilidad. Evalúa el desempeño del software en diferentes

hardwares , sistemas operativos , redes, etc.

•Prueba de exploración. Es una prueba informal del software que no esta

basada en ningún 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 exploración pero los testers

deben tener suficiente noción sobre el funcionamiento del programa antes de

comenzar esta prueba. Incluye reunión con analistas y programadores.

•Prueba de usuario. Determina si el usuario se desenvuelve satisfactoriamente

con el programa.

•Prueba de comparación. 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 pequeños cambios generalmente en el diseño de

interfaces. Esta prueba es hecha por usuarios.

•Prueba beta. Es la búsqueda de bugs en el programa completo.

Generalmente es hecha por usuarios.

•Prueba de mutación. Esta prueba esta basada en la introducción deliberada

de diferentes códigos externos al programa (bugs) para reexaminar si estos

bugs pueden ser detectados. Requiere gran disponibilidad de recursos de

computación.

¿Cuales son los cinco problemas mas comunes en el desarrollo de

procesos. ?

•Pobre definición 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.

•Planificación irreal. Planifica sobre supuestos para acortar el tiempo de

desarrollo, los problemas serán inevitables.

•Pruebas inadecuadas. Es imprescindible asegurarse que el programa funciona

antes de la entrega al usuario.

•Falta de comunicación. Si desarrolladores de programas, clientes o usuarios y

directivos del proyecto tienen una mala o escasa comunicación los problemas

estarán garantizados.

•Carencia de rasgos. Definir nuevos rasgos una vez que el programa se haya

terminado es muy común y genera problemas. Se deben definir las

características del programa.

¿Cuales son las cinco soluciones para los problemas de desarrollo?

•Requerimientos sólidos. Deben ser claros, completos, detallados, probables, posibles, cohesivos y coherentes. Son imprescindibles los prototipos para que se cumplan estas condiciones.

•Planificación real. Se debe ser sincero y dedicar el tiempo adecuado a la planificación. Esto agilizara el diseño, 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.

•Comunicación continua. Con la tecnología existente hoy en dia, un buen profesional debe poder utilizar todas las herramientas posibles, desde teléfonos celulares, e-mail, hasta reuniones formales e informales en los diferentes ámbitos que conciernan al desarrollo del software.

•Seguimiento de rasgos. Es deseable realizar una buena preparación de las características a seguir por el programa. Interfaces, salidas, equipos etc. Una buena prototipación de las entradas y salidas es lo ideal para defenderse de posibles cambios y potenciales problemas.

¿Cómo realizar un buen código?

Un Buen código es aquel que funciona sin bugs, además 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 codificación.

A continuación definiremos reglas que la mayoría de las organizaciones consideran importantes para evitar problemas en la mayoría de los lenguajes de programacion mas usados como el C, C++.

•Minimizar el uso de variables globales.

•Nombres descriptivos de funciones, variables, módulos, objetos y metodos.

•Minimizar el tamaño de funciones, metodos y procedimientos. Acercamiento al caso ideal de no exceder las 50 líneas.

•Descripciones deben ser cortas y claras para no confundir la lectura del código.

•Organizacion de los metodos, una buena disposición del código hará que futuros cambios sean posibles.

•Uso generoso de espacios en blanco.

•Es importante que cada línea de código no supere los 70 caracteres.

•Una sentencia por línea.

•Es fundamental que el grupo de desarrolladores respete el mismo estilo de

codificación.

•Toda aplicacion debe ser documentada no importa lo pequeña sea dicha

aplicacion.

¿Cómo pueden las nuevas herramientas automatizadas de prueba simplificar el proceso de deteccion de errores ?

Una de las herramientas automatizadas que a logrado ser muy popular en el

entorno del diseño de software, por su simplicidad y, además, por el ultimo gran

disgusto en cuestion a problemas de software, el efecto Y2K, es la herramienta

RECORD-PLAYBACK, al ejecutar dicha aplicacion antes de hacer correr el programa

a probar, se activa la opción récord, el tester navega por las diferentes aplicaciones

del software, menús, 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 opción playback de la herramienta navega

automáticamente 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 código. Es una especie de depurador externo que

examina además 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. Evalúa 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 código y de

cobertura, haciendo un reporte de las partes de códigos no examinadas

o confusas.

•Reporte de configuración. Hace un reporte de los requerimientos del

programa en cuestion a hardware y los parámetros mínimos que se

deben cumplir para que el software pueda trabajar al máximo.

•Reporte de desempeño. Hace un reporte del nivel de desempeño,

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 años 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

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 desempeño 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 pequeño 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

podría hacerse sin que el usuario haya tenido previo contacto con los

prototipos del sistema, y para los testers una efectiva interacción con

herramientas CASE.

Prueba de caja blanca

Para esta prueba se consideran tres importantes puntos.

I) Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y consistencia del código.

II) Considerar las reglas predefinidas por cada algoritmo.

III) Comparar el desarrollo del programa en su código con la documentación pertinente.

La primera parte de esta prueba es el análisis estático.

• Análisis estático Manual

• Inspección : Determina si el código esta completo y correcto,

como también las especificaciones.

• Walkthrough : Interrelación informal entre testers, creadores y

usuarios del sistema.

• Análisis estático Automático

• Verificación estática : Compara los valores generados por el

programa con los rangos de valores predefinidos haciendo una

descripción del funcionamiento de los procedimientos en términos

booleanos determinando los puntos de falla.

• Ejecución simbólica : Hace un seguimiento de la comunicación

entre funciones, módulos, aplicaciones, luego de que todas las

partes hayan sido verificadas por separado.

La segunda parte de esta es el análisis dinámico. Para esto se cuenta con

diferentes tipo de herramientas.

• Análisis de cobertura : Examina las extensiones del código, haciendo

una caja blanca por modulo.

• Trafico : Sigue todos los caminos de comunicación entre módulos

guardando los valores de las variables en cada uno de ellos.

• Simulador : Simula partes del sistema para el cual el hardware no esta

habilitado.

• Sintonía : Testea los recursos utilizados durante la ejecución del

programa.

• Prueba de certeza : Examina las construcciones lógicas del programa.

Generación 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 hacían un

acercamiento a una sofisticada prueba estructural determinando el desempeño de los

módulos 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, además

examinan paso a paso la ejecución 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 análisis 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 noción 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 planificación de diseño.

- 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 revisión en la prueba.

- Evaluar resultados en reportes.

- Buscar bugs.

- Volver a probar si es necesario.

- Actualizar el plan de prueba.

¿ Cómo se define un plan de prueba ?

- Titulo

- Identificación, números de versión, creador, fecha de creacion.

- Tabla de contenidos.

- Reportes de reuniones.

- Reportes de requerimientos.

- Reportes de documentación.

- Análisis de riesgos.

- Prioridades y focos de prueba.

- Limites. (tiempo, riesgos, etc.)

- Reporte de datos de prueba.

- Reporte de resultados.

- Reporte de aplicaciones conjuntas al programa.

- Informe de herramientas automatizadas.

- Determinación de la sanidad del programa.

- Personal implicado.

- Reportes relevantes. (Licencias, clasificaciones, metodos, etc.)

- Apéndices, glosario, cronología.

Bibliografia.

Revista Programacion Actual

Prueba de Software y Seguridad en entornos distribuidos

M. Vasquez C. Falcato Editorial Prensa Tecnica S. L. España

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