Pasos para el desarrollo de pruebas : - Obtener los requerimientos en forma clara. - Obtener planificacin de diseo. - 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. - 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.

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.

Estudio de tecnicas de prueba basicas.

Hoy en dia, la mayor parte de las tecnicas de prueba se basan en las tcnicas 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.

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. 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.

Pruebas de configuracin:

Programas tales como sistemas operativos, sistemas de gerencia de base de datos, y programas de conmutacin de mensajes soportan una variedad de configuraciones de hardware, incluyendo varios tipos y nmeros de dispositivos de entrada-salida y lneas de comunicaciones, o diversos tamaos de memoria. En palabras de Bryson, RationalQualtymanagementsolution manager: Hace un par de aos, el problema empezaba y terminaba al asegurarnos que la aplicacin funcionara sobre diferentes exploradores y sistemas operativos. Las aplicaciones de ahora estn ms interconectadas; por eso lo llamo el iceberg. Podemos ver algo en la superficie, pero es la inmensa infraestructura de abajo lo que lo hace complicado. Esta infraestructura es la que debe ser probada para ver si el software funciona bajo diferentes condiciones, tanto de otro software como de hardware, y dichas pruebas sern hechas por medio de pruebas de configuracin.

Descripcin de la Tcnica de prueba

Pruebas de configuracin, son pruebas al sistema utilizando todas las configuraciones de software y hardware que este soporta.

Durante estas pruebas, el tester valida que tan bien nuestro proyecto actual es capaz de soportar diferentes tipos de tecnologas de hardware, como diferentes tipos de impresoras, interfaces, topologa etc. Estas pruebas tambin son llamadas pruebas de hardware o pruebas de portabilidad. Esto puede llegar a ser un reto para los testers, especialmente con la velocidad de cambio de estos das. En los ltimos 12 meses hemos visto tres versiones de exploradores nuevas, y nos acercamos al lanzamiento de dos sistemas operativos ms en este ao, dice Marc Nadeau, senior director de QA enBlackboard Inc., Esto se est volviendo cada vez ms desalentador.

Para ayudar evitar algunos de estos obstculos, vale la pena ver algunas cosas que podras no saber sobre las pruebas de configuracin. Podras no darte cuenta del impacto que una configuracin puede tener sobre como una aplicacin funciona.

Las aplicaciones no se mueven por si solas, tienen piezas y partes, y si estas piezas y partes no se mueven con ella puede crear un problema, dice Karen N. Johnson, una consultora de software independiente. Por ejemplo, dice ella, la raz del problema de una aplicacin Web que estaba probando recientemente, fue que RubyGem necesitaba ser actualizada. RubyGem es el estndar de Ruby para publicar y manejar libreras de tercera mano.

Hay pocos estndares en el lado del hardware. No hay suficientes estndares de hardware, para identificar lo que una pieza de hardware entrega, dice Frank Cohen, CEO y fundador de PushToTest, Lo que es irnico tomando en cuenta que, a nivel de chip, hay una increble cantidad de especificaciones sobre la funcin del chip. Pero ms all del nivel de la tarjeta madre, casi no hay nada que sea estndar. Hay un ciclo de vida de desarrollo para Hardware como lo hay para el software. Mientras te mueves de desarrollo de [software] a produccin, podran no haber datos correctos como input a una prueba automatizada para saber si algo cambio en el hardware, dice Cohen. Es fcil no saber que el ambiente ha cambiado por alguna actualizacin encendida/corriendo en el fondo. De acuerdo con Johnson, la dificultad est aumentando a la hora de mantener un ambiente con las actualizaciones de Windows y otros procesos de fondo que pueden hacer cambios.Esunapesadilla, dice. Un casoesunaaplicacin web. Con tantas maquinas Windows que tienen actualizaciones automticas, el ambiente

puede cambiar a una velocidad impresionante. Esta semana gaste mi tiempo rastreando como una barra de herramientas agregada al explorador, introduca un bug. No es poco comn para las personas terminar con una gran cantidad de addons en su ambiente.

Los

desarrolladores

pueden

proveer

de

ayuda

los

testers.

Con problemas como los add-on y actualizaciones, No espero que los desarrolladores anticipen todo, pero si pueden avisarme sobre las piezas que son vulnerables, entonces puedo trabajar en como el explorador maneja las cosas. Para ellos es posible sealas algo, dice Johnson. Por ejemplo, dice, una aplicacin podra tener conexin con otra aplicacin de tercera mano. Si no han codificado esa pieza, me gustara verla de una forma d iferente.

Pruebas

de

configuracin

pueden

ser

difciles

sin

automatizacin.

Pruebas manuales Funcionan bien si tenemos un despliegue pequeo y limitado, dice Cohen, Pero para el internet, SOA, y aplicaciones de internet no hay forma de probarlo correctamentehay muchas partes. Cuando un sistema habla a otro sistema, digamos, pruebas de carga, el resultado puede variar cada vez porque depende de lo que el otro sistema est haciendo.

Una

definicin

modelo

contra

quien

probar,

es

necesario.

Mayormente, las organizaciones fallan porque no estn 100% comprometidos con lo que esta implementado, dice Cohen. El mtodo de pruebas de configuracin se usa para identificar un uso de modelo para una pieza de equipo en particular y probar contra este modelo. Digamos que un estudiante universitario est usando una nueva laptopno necesitamos conexiones Ethernet Gigabit. Entonces identificamos el arquetipo.

Las pruebas de configuracin pueden ser costosas.

Johnson lista varias razones para este alto costo de las pruebas de configuracin, incluyendo las siguientes:

Toma mucha dedicacin el conocer todos los aspectos de configuracin de cierto sistema. Se necesita cuidar del ambiente para mantener todos los factores. Podra aumentar la necesidad de pruebas. Podra requerir mltiples configuraciones de hardware lo que genera ms costos. No es tan bien entendido al nivel de ejecucin. Por la mayor parte, el tema aburre a las personas, dice Johnson. Las personas tecnolgicas lo encontraran interesante, pero cuando subimos unos niveles en la lnea de gerencia, los aburre al instante, pero si no entienden la importancia, esto regresara con ms problemas. No conocen la necesidad de ms dispositivos para hacer pruebas; no conocen la labor envuelta en el cuidado y mantenimiento de la maquinas. Tendrs que pelear por dinero si las personas no saben cul es el punto. No todos hacen pruebas de configuracin.La gente puede simplemente saltarlo y no entenderlo, o caer sorprendidos por la complejidad, o darse cuenta que no pueden pagarlo y lo saltan. En algunos casos esta es la solucin prctica, dice Johnson. Vienen reportes de produccin y te das cuenta de cmo estamos. No intento sonar alarmante. Pero la cantidad de trabajo que toma encontrar tres bus, podra no valerlo. Una de las cosas mas grandes, es conocer tu audiencia. Siempre hay rezagados te molestaras por probar sobre Windows 98 cuando esto representa el 1% de tu audiencia?

Pruebas de configuracin

Objetivos: Verificar que los objetivos de las pruebas anteriores responden

adecuadamente sobre distintos sistemas operativos y navegadores web.

Tcnicas: Todos los casos de prueba resultantes de los casos de prueba anteriores se aplicarn sobre las siguientes combinaciones familia de sistema Operativo + Navegador: