Protocolos de Pruebas de SoftwareLaspruebas de software(eninglssoftware testing) son las investigaciones empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte interesada ostakeholder. Es una actividad ms en el proceso decontrol de calidad.

Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo desoftware. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, as como modelos de pruebas. A cada uno corresponde una nivel distinto de involucramiento en las actividades de desarrollo.

El objetivo de las pruebas es presentar informacin sobre la calidad del producto a las personas responsables de este.

Teniendo esta afirmacin en mente, la informacin que puede ser requerida es de lo ms variada. Esto hace que el proceso detestingsea completamente dependiente del contexto1en el que se desarrolla.

A pesar de lo que muchos promueven, no existen las "mejores prcticas" como tal. Toda prctica puede ser ideal para una situacin pero completamente intil o incluso perjudicial en otra.

Por esto, las actividades, tcnicas, documentacin, enfoques y dems elementos que condicionarn las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera ms eficiente segn contexto del proyecto.

Pruebas estticas

Son el tipo de pruebas que se realizan sin ejecutar el cdigo de la aplicacin (Ceferino).

Puede referirse a la revisin de documentos, ya que no se hace una ejecucin de cdigo. Esto se debe a que se pueden realizar pruebas de escritorio con el objetivo de seguir los flujos de la aplicacin.

Pruebas dinmicas

Todas aquellas pruebas que para su ejecucin requieren la ejecucin de la aplicacin.

Las pruebas dinmicas permiten el uso de tcnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinmica de la ejecucin de pruebas es posible medir con mayor precisin el comportamiento de la aplicacin desarrollada.

En laspruebas de software, laautomatizacin de pruebasconsiste en el uso de software especial (casi siempre separado del software que se prueba) para controlar la ejecucin de pruebas y la comparacin entre los resultados obtenidos y los resultados esperados. La automatizacin de pruebas permite incluir pruebas repetitivas y necesarias dentro de un proceso formal de pruebas ya existente o bien adicionar pruebas cuya ejecucin manual resultara difcil.Algunaspruebas de softwaretales como laspruebas de regresinintensivas de bajo nivel pueden ser laboriosas y consumir mucho tiempo para su ejecucin si se realizan manualmente. Adicionalmente, una aproximacin manual puede no ser efectiva para encontrar ciertos tipos de defectos, mientras que las pruebas automatizadas ofrecen una alternativa que lo permite. Una vez que una prueba ha sido automatizada, sta puede ejecutarse repetitiva y rpidamente en particular con productos de software que tienen ciclos de mantenimiento largo, ya que incluso cambios relativamente menores en la vida de una aplicacin pueden inducir fallos en funcionalidades que anteriormente operaban de manera correcta. Existen dos aproximaciones a las pruebas automatizadas:

Pruebas manejadas por el cdigo: Se prueban lasinterfaces pblicasde lasclases,mdulosobibliotecascon una variedad amplia de argumentos de entrada y se valida que los resultados de obtenidos sean los esperados.

Pruebas deInterfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interface de usuario, tales como teclear, hacer click con el ratn e interactuar de otras formas con el software y se observan los cambios resultantes en la interface de usuario, validando que el comportamiento observable del programa sea el correcto.

La eleccin misma entre automatizacin y ejecucin manual de pruebas, los componentes cuya prueba ser automatizada, las herramientas de automatizacin y otros elementos son crticos en el xito de las pruebas, y por lo regular deben provenir de una eleccin conjunta de los equipos de desarrollo, control de calidad y administracin. Un ejemplo de mala eleccin para automatizar, sera escoger componentes cuyas caractersticas son inestables o su proceso de desarrollo implica cambios continuos.

Pruebas de caja blanca

Laspruebas de caja blanca(tambin conocidas comopruebas de caja de cristalopruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseo est fuertemente ligado alcdigo fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posiblesflujos de ejecucindel programa y cerciorarse de que se devuelven los valores de salida adecuados.

Al estar basadas en una implementacin concreta, si sta se modifica, por regla general las pruebas tambin debern redisearse.

Aunque las pruebas de caja blanca son aplicables a varios niveles unidad,integracinysistema, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecucin dentro de cada unidad (funcin,clase,mdulo, etc.) pero tambin pueden testear los flujos entre unidades durante la integracin, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite disear pruebas que cubran una amplia variedad decasos de prueba, podra pasar por alto partes incompletas de laespecificacinorequisitosfaltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecucin del cdigo analizado.

Las principales tcnicas de diseo de pruebas de caja blanca son:

Pruebas de flujo de control Pruebas de flujo de datos Pruebas de bifurcacin(branch testing)

Pruebas de caminos bsicosHacking

En lostests de penetracin, las pruebas de caja blanca hacen referencia a una metodologa donde elhackerposee un conocimiento total y absoluto del sistema que pretende atacar. El objetivo de estos tests de penetracin, que perciben el sistema de forma transparente, es simular el comportamiento de un intruso malicioso que contase con permisos de acceso e informacin precisa acerca del sistema.Pruebas de caja negraEnteora de sistemasyfsica, se denominacaja negraa aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de unacaja negranos interesar su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que tambin podran sercajas negras) entendiendoqu es lo que hace, pero sin dar importancia acmo lo hace. Por tanto, de unacaja negradeben estar muy bien definidas sus entradas y salidas, es decir, suinterfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.Enprogramacin modular, donde unprograma(o unalgoritmo) es dividido enmdulos, en la fase de diseo se buscar que cada mdulo sea unacaja negradentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia entre los mdulos que facilita su implementacin separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un mdulo) del programa global; el implementador de un mdulo concreto deber conocer como es la comunicacin con los otros mdulos (la interfaz), pero no necesitar conocer como trabajan esos otros mdulos internamente; en otras palabras, para el desarrollador de un mdulo, idealmente, el resto de mdulos serncajas negras.Testing exploratorioEltesting exploratorioopruebas exploratoriases un estilo o enfoque para la realizacin depruebas de software. Su principal caracterstica es que el aprendizaje, el diseo y la ejecucin de las pruebas se realizan de forma simultnea. Cem Kaner, quien acu el trmino en 1983, define el testing exploratorio como "un estilo de testing que enfatiza la libertad personal y la responsabilidad del tester para optimizar continuamente la calidad de su trabajo tratando el aprendizaje a travs de las pruebas, el diseo de las pruebas, la ejecucin de las pruebas y la interpretacin del resultado de las pruebas como actividades que se apoyan mutuamente y que se ejecutan en paralelo a lo largo del proyecto."

Mientras se est probando el software, el tester va aprendiendo a manejar el sistema y junto con su experiencia y creatividad, genera nuevas pruebas a ejecutar. A menudo se piensa que el testing exploratorio como una tcnica de prueba de caja negra. Sin embargo, aquellos que lo han estudiado, lo consideran un enfoque que se puede aplicar a cualquier tcnica de pruebas, en cualquier etapa del proceso de desarrollo. La clave no es la tcnica ni el elemento que estamos probando o revisando; la clave es el compromiso cognitivo del tester y la responsabilidad del tester para gestionar su tiempo.

Prueba unitaria

Enprogramacin, unaprueba unitariaes una forma de probar el correcto funcionamiento de un mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione correctamente por separado. Luego, con lasPruebas de Integracin, se podr asegurar el correcto funcionamiento del sistema o subsistema en cuestin.

La idea es escribir casos de prueba para cada funcin no trivial omtodoen el mdulo, de forma que cada caso sea independiente del resto.

Caractersticas

Para que una prueba unitaria seabuenase deben cumplir los siguientes requisitos:

Automatizable

No debera requerirse una intervencin manual. Esto es especialmente til paraintegracin continua.

Completas

Deben cubrir la mayor cantidad de cdigo.

Repetibles o Reutilizables

No se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til paraintegracin continua.

Independientes

La ejecucin de una prueba no debe afectar a la ejecucin de otra.

Profesionales

Las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad, documentacin, etc.

Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su funcin.

Ventajas

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe satisfacer.Limitaciones

Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del cdigo. Por definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn errores de integracin, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Adems, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias slo son efectivas si se usan en conjunto con otras pruebas de software.HerramientasJUnit: Entorno de pruebas para Java creado porErich GammayKent Beck. Se encuentra basado en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje Smalltalk.

TestNG: Creado para suplir algunasdeficienciasen JUnit.

JTiger: Basado en anotaciones, como TestNG.

SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.

PHPUnit: Sistema para la realizacin pruebas unitarias en PHP.

CPPUnit: Versin del framework para lenguajes C/C++.

NUnit: Versin del framework para la plataforma.NET.

FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro

MOQ: Entorno para la creacin dinmica de objetos simuladores (mocks). MOQ.

QUnit: Librera para pruebas unitarias en Javascript. Creada por la fundacin jQuery, ha sido reescrita para ser independiente de la librera jQuery.

libunittest: Librera portable para pruebas unitarias en C++ que usa el nuevo estndar C++11.Prueba de integracin

Pruebas integralesopruebas de integracinson aquellas que se realizan en el mbito deldesarrollo de softwareuna vez que se han aprobado laspruebas unitarias. nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes desoftwarefuncionan juntos.

Las pruebas de integracin (algunas veces llamadas integracin y testeo I&t) es la fase de la prueba de software en la cual mdulos individuales de software son combinados y probados como un grupo. Son las pruebas posteriores a laspruebas unitariasy preceden a las pruebas del sistema.Prueba funcional

Unaprueba funcionales una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamentediseadaspara elsoftware. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paqueteinformtico. Dicho de otro modo son pruebas especficas, concretas y exhaustivas para probar y validar que el software hace lo que debe y sobre todo, lo que se ha especificado.Las pruebas funcionales se dividen en las siguientes fases:

Anlisis de requisitos (Planificacin)

En esta fase se inicia la elaboracin del modelo jerrquico de requisitos de prueba partiendo de los procesos funcionales que soporta el producto o activo de software a evaluar. A partir de las funcionalidades se elaborar el plan de pruebas. Hay que obtener toda la informacin posible de las aplicaciones sobre las cuales se realizarn las pruebas. Esta informacin se deber conseguir de toda la documentacin disponible sobre su funcionamiento y hablando con el personal responsable de la misma.

Diseo del plan de pruebas (Preparacin)

En esta fase se identifica, acuerda y especifican los atributos y caractersticas de calidad que se van a probar. El objetivo es disear las pruebas para que tengan la mayor probabilidad de encontrar defectos con la mnima cantidad de esfuerzo y tiempo. Sern pruebas que se llevarn a cabo a travs de la interfaz grfica del software (GUI). Es decir, demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta, as como que la integridad de la informacin externa se mantiene. Se crearn casos de prueba divididos en pasos (steps) para cada accin a realizar con un resultado esperado asociado, que podr ser verificado. Durante la fase de diseo tambin se especifican los datos de entrada necesarios para que los casos de pruebas definidos puedan ser ejecutados (ya sea buscando el xito de la prueba, o bien el fallo).

Ejecucin

En esta fase se ejecutarn los casos de prueba anteriormente diseados de forma manual. Hay que seguir al detalle el guin establecido dejando cierta libertad al tester para detectar situaciones anmalas no contempladas. Las bateras de pruebas sern ejecutadas como mnimo una vez antes del paso a produccin, independientemente de las ejecuciones anteriores. Los casos de prueba fallados se reportarn a los desarrolladores para su correccin hasta que su resultado sea correcto.

Gestin de Incidencias (Defectos)

La gestin de incidencias es una parte implcita de la fase de ejecucin, pero que al tener una alta importancia en las pruebas funcionales, diferenciamos como una etapa independiente. Cuando al realizar la accin de un step el resultado obtenido no es el esperado, habr que abrir o reportar una incidencia para que el equipo de desarrollo tenga constancia del error. La gestin de incidencias es el principal canal de comunicacin con el equipo de desarrollo. Las incidencias han de ser claras y con todo lujo de detalle, tienen que describir el error para que el equipo de desarrollo pueda comprenderlo perfectamente, reproducirlo, localizarlo y poder solucionarlo. Se deber mantener una continua comunicacin con el equipo de desarrollo para conocer el estado de los defectos y poder realizar las repruebas necesarias para su cierre.

Las pruebas funcionales pueden ser, segn su ejecucin:

Manuales

Las pruebas funcionales manuales son las que ejecuta un tester como si fuese un usuario pero siguiendo una serie de pasos establecidos o test plan, diseado en el anlisis de los requisitos para garantizar que hace lo que debe (casos positivos), que no falla (casos negativos) y que es lo que se ha solicitado. El tester realizar las acciones indicadas en cada step del caso de prueba comprobando que se cumple el resultado esperado. Si el resultado es distinto al esperado, se reportar un defecto con todo detalle: descripcin, datos utilizados, capturas de pantalla, etc. para facilitar la solucin del defecto por parte de los desarrolladores.

Automticas

Las pruebas funcionales automticas son pruebas funcionales que se automatizan para "ahorrar tiempo de pruebas". A partir de los casos de prueba de las pruebas manuales, se automatizan los casos de prueba que se repitan en las ejecuciones. Esos casos suelen ser los ms importantes (happy flow) de los mdulos o procesos de negocio "vitales" de la aplicacin, es decir, los procesos que siempre tienen que funcionar y que bajo ningn concepto pueden fallar. El objetivo de las pruebas funcionales automticas es comprobar que nada de lo probado con anterioridad ha dejado de funcionar como debera.

Las pruebas funcionales pueden ser, segn tipo de pruebas:

Pruebas exploratorias

Son aquellas pruebas a travs de las cuales, simultneamente, se obtiene un aprendizaje y conocimiento de la aplicacin a probar a la vez que se genera un valor desde el primer momento. Ayudan a la integracin de la fase de pruebas de una forma mucho ms rpida, pues permiten al tester elaborar un guion de pruebas que utilizar para el diseo de los futuros planes de pruebas. Estas pruebas son realmente tiles a la hora de probar aplicaciones ya desarrolladas, es decir, aquellas pruebas de software que no comienzan a la vez que el desarrollo. Para realizar las pruebas funcionales exploratorias se identificarn los distintos procesos de negocio o mdulos de la aplicacin y se le dar al tester libertad, ponindose en la piel de un usuario, para probarlos. Estas pruebas exploratorias debern ejecutarse sobre la ltima versin cerrada disponible de la aplicacin.

Pruebas de regresin

El objetivo de las pruebas de regresin es eliminar el efecto onda, es decir, comprobar que cambios realizados en el software no introducen un comportamiento no deseado o errores adicionales en otros mdulos o partes no modificados. Las pruebas de regresin se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para corregir un error como para realizar una mejora. No es suficiente probar slo los componentes modificados o aadidos, o las funciones que en ellos se realizan, sino que tambin es necesario controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros componentes. Este tipo de pruebas tiene que garantizar que tras un cambio en el software, al menos la funcionalidad ms importante sigue funcionando. Para este tipo de pruebas lo ideal es automatizar los casos que validen que estas partes siguen funcionando, pues se ejecutarn de manera repetitiva a lo largo del ciclo de vida del software.

Pruebas de compatibilidad

Las pruebas de compatibilidad son pruebas funcionales realizas en cada navegador de internet, sistema operativo o dispositivo, para garantizar el correcto funcionamiento del aplicativo en todos los medios. El mismo software puede presentar errores dependiendo de dnde se ejecute: funcionales (botones y enlaces pueden dejar de funcionar, producen errores de sistema o simplemente no realizan la funcionalidad esperada), estticos (pueden descuadrarse frames de la aplicacin, no cargarse imgenes, desaparecer enlaces o botones, textos).

Pruebas de integracin

Las pruebas de integracin son pruebas funcionales entre dos o ms sistemas. El objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces, cubren la funcionalidad establecida y se ajustan a los requisitos.

Pruebas de aceptacin

El objetivo de las pruebas de aceptacin es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptacin, desde el punto de vista de su funcionalidad y rendimiento. En las pruebas de aceptacin, la ejecucin y aprobacin final corresponden al usuario o cliente, que es el que valida y verifica que el alcance es el correcto.Metodologas

La metodologa estndar o en cascada

Es una metodologa lineal. Se ordenan rigurosamente las etapas del proceso de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. El equipo de pruebas trabaja de forma paralela al equipo de desarrollo y empieza a ejecutar o pasar las pruebas una vez el desarrollo est completado.

Las metodologas giles

Se basan en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto-organizados y multidisciplinarios, minimizando riesgos desarrollando en lapsos cortos de tiempo. Estos lapsos se denominan "Iteracin". Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener algo tangible (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.

Caso de pruebaEnlaingeniera del software, loscasos de pruebaoTest Caseson un conjunto de condiciones o variables bajo las cules el analista determinar si el requisito de una aplicacines parcial o completamente satisfactorio.

Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Con el propsito de comprobar que todos los requisitos de una aplicacin son revisados, debe haber al menos un caso de prueba para cada requisito a menos que un requisito tenga requisitos secundarios. En ese caso, cada requisito secundario deber tener por lo menos un caso de prueba. Algunas metodologas como RUP recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa.

Si la aplicacin es creada sin requisitos formales, entonces los casos de prueba se escriben basados en la operacin normal de programas de una clase similar.

Lo que caracteriza un escrito formal de caso de prueba es que hay unaentrada conociday unasalida esperada, los cuales son formulados antes de que se ejecute la prueba. Laentrada conocidadebe probar una precondicin y lasalida esperadadebe probar una pos condicin.

Bajo circunstancias especiales, podra haber la necesidad de ejecutar la prueba, producir resultados, y luego un equipo de expertos evaluara si los resultados se pueden considerar como "correctos". Esto sucede a menudo en la determinacin del nmero del rendimiento de productos nuevos. La primera prueba se toma como lnea base para los subsecuentes ciclos de pruebas/lanzamiento del producto.

Los casos de prueba escritos, incluyen una descripcin de la funcionalidad que se probar, la cual es tomada ya sea de los requisitos o de loscasos de uso, y la preparacin requerida para asegurarse de que la prueba pueda ser dirigida.

Los casos de prueba escritos se recogen generalmente en unasuite de pruebas.

Las variaciones de los casos de prueba son comnmente utilizadas enpruebas de aceptacin. La prueba de aceptacin es realizada por un grupo deusuarios finaleso los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus requisitos. La prueba de aceptacin de usuario se distingue generalmente por la incorporacin de un trayecto feliz o casos de prueba positivos.Dimensiones de calidadLa calidad se incorpora en una aplicacin web como consecuencia de un buen diseo. Se evala aplicando una serie de revisiones tcnicas que valoran varios elementos del modelo de diseo y un proceso de prueba que se estudia a lo largo de este captulo. Tanto las revisiones como las pruebas examinan una o ms de las siguientes dimensiones de calidad:El contenido se evala tanto en el nivel sintctico como en el semntico. En el primero, se valora vocabulario, puntuacin y gramtica para documentos basados en texto. En el segundo, se valora la correccin (de la informacin presentada), la consistencia (a travs de todo el objeto de contenido y de los objetos relacionados) y la falta de ambigedad.La funcin se prueba para descubrir errores que indican falta de conformidad con los requerimientos del cliente. Cada funcin del sistema se valora en su correccin, inestabilidad y conformidad general con estndares de implantacin adecuados (por ejemplo, estndares de lenguaje Java o AJAX).La estructura se valora para garantizar que entrega adecuadamente el contenido y la funcin de la aplicacin, que es extensible y que puede soportarse conforme se agregue nuevo contenido o funcionalidad.La usabilidad se prueba para asegurar que la interfaz soporta a cada categora de usuario y que puede aprender y aplicar toda la sintaxis y semntica de navegacin requerida.La navegabilidad se prueba para asegurar que toda la sintaxis y la semntica de navegacin se ejecutan para descubrir cualquier error de navegacin (por ejemplo, vnculos muertos, inadecuados y errneos).El rendimiento se prueba bajo condiciones operativas, configuraciones y cargas diferentes a fin de asegurar que el sistema responde a la interaccin con el usuario y que maneja la carga extrema sin degradacin operativa inaceptable.La compatibilidad se prueba al ejecutar el sistema en varias configuraciones anfitrin, tanto en el cliente como en el servidor. La intencin es encontrar errores que sean especficos de una configuracin anfitrin nico.La Interoperabilidad se prueba para garantizar que el sistema tiene interfaz adecuada con otras aplicaciones y/o bases de datos.La seguridad se prueba al valorar las vulnerabilidades potenciales e intenta explotar cada una. Cualquier intento de penetracin exitoso se estima como un fallo de seguridad.Errores dentro de un entorno webappLos errores que se encuentran como consecuencia de una prueba exitosa de una webapp tienen algunas caractersticas nicas:Puesto que muchos tipos de pruebas de webapps descubren problemas que se evidencian primero en el lado del cliente (es decir, mediante una interfaz implantada en un navegador especfico o en un dispositivo de comunicacin personal), con frecuencia se ve un sntoma del error, no el error en s.Puesto que una webapp se implanta en algunas configuraciones distintas y dentro de diferentes entornos, puede ser difcil o imposible reproducir un error afuera del entorno en el que originalmente se encontr.Aunque algunos errores son resultado de diseo incorrecto o codificacin HTML (u otro lenguaje de programacin) impropia, muchos errores pueden rastrearse en la configuracin de la webapp.

Dado que las webapps residen dentro de una arquitectura cliente-servidor, los errores pueden ser difciles de rastrear a travs de tres capas arquitectnicas: el cliente, el servidor o la red en s.Algunos errores se deben al entamo operativo esttico (es decir, a la configuracin especfica donde se realiza la prueba mientras que otros son atribuibles al entorno operativo dinmico (es decir, a la carga de recurso instantnea o a errores relacionados con el tiempo).Estos cinco atributos de error sugieren que el entorno juega un importante papel en el diagnstico de todos los errores descubiertos durante la prueba de webapps. En algunas situaciones (por ejemplo, la prueba de contenido), el sitio del error es obvio, pero en muchos otros tipos de prueba de webapps (por ejemplo, prueba de navegacin, prueba ele rendimiento, prueba de seguridad), la causa subyacente del error puede ser considerablemente ms difcil de determinar.

Planificacin de pruebas

El uso de la palabra planificacin (en cualquier contexto) es un anatema para algunos desarrolladores web que no planifican; slo arrancan, con la esperanza de que surja una webapp asesina.Un enfoque ms disciplinado reconoce que la planificacin establece un mapa de ruta para todo el trabajo que va despus. Vale la pena el esfuerzo.Excepto por el ms simple de los sitios web, rpidamente resulta claro que es necesaria alguna especie de planificacin de pruebas. Con demasiada frecuencia, el nmero inicial de errores encontrados a partir de una prueba ad hoc es suficientemente grande como para que no todos se corrijan la primera vez que se detectan. Esto impone una carga adicional sobre el personal que prueba sitios y webapps.No slo deben idear nuevas pruebas imaginativas, sino que tambin deben recordar cmo se ejecutaron las pruebas anteriores con la finalidad de volver a probar de manera confiable el sitio/webapp, y garantizar que se removieron los errores conocidos y que no se introdujeron algunos nuevos.Las preguntas que deben plantearse son: cmo se "idean nuevas pruebas imaginativas" y sobre qu deben enfocarse dichas pruebas? Las respuestas a estas preguntas se integran en un plan de prueba que identifica: 1) el conjunto de tareas2 que se van a aplicar cuando comiencen las pruebas, 2) los productos de trabajo que se van a producir conforme se ejecuta cada tarea de prueba y 3) la forma en la que se evalan, registran y reutilizan los resultados de la cuando se realizan pruebas de regresin. En algunos casos, el plan de prueba se integra con el plan del proyecto. En otros, es un documento separado.ResumenLa meta de la prueba de software es ejercitar cada una de las muchas dimensiones de calidad, con la intencin de encontrar errores o descubrir conflictos que puedan conducir a fallas en la calidad. Las pruebas se enfocan en contenido, funcin, estructura, usabilidad, navegabilidad, rendimiento, compatibilidad, interaccin, capacidad y seguridad. Estas pruebas incorporan revisiones que ocurren conforme se disea el sistema y pruebas que se llevan a cabo una vez que se implanta el mismo.La estrategia de prueba de software ejercita cada dimensin de calidad al examinar inicialmente "unidades" de contenido, funcionalidad o navegacin. Una vez validadas las unidades individuales, la atencin se cambia hacia pruebas que ejercitan el software como un todo. Para lograr esto, muchas pruebas se derivan desde la perspectiva del usuario y se activan mediante la informacin contenida en casos de uso. Se desarrolla un plan de prueba de software y se identifican los pasos de la prueba, productos de trabajo (por ejemplo, casos de prueba) y mecanismos para la evaluacin de los resultados de la prueba. El proceso de prueba abarca siete tipos diferentes de pruebas.La prueba de contenido (y las revisiones) se enfocan en varias categoras de contenido. La intencin es descubrir errores semnticos y sintcticos que afectan la precisin del contenido o la forma en la que se presenta al usuario final. La prueba de interfaz ejercita los mecanismos de interaccin que permiten al usuario comunicarse con el software y valida los aspectos estticos de la interfaz. La intencin es descubrir errores que resultan a partir de mecanismos de interaccin pobremente implantados o de omisiones, inconsistencias o ambigedades en la semntica de la interfaz.Las pruebas de navegacin aplican casos de uso, derivados de la actividad de modelado, en el diseo de casos de prueba que ejercitan cada escenario de uso contra el diseo de navegacin. Los mecanismos de navegacin se ponen a prueba para garantizar que cualquier error que impida completar un caso de uso se identifique y corrija. La prueba de componente ejercita las unidades de contenido y funcionales dentro del software. La prueba de configuracin intenta descubrir errores y/o problemas de compatibilidad que son especficos de un entorno cliente o servidor particular. Entonces se realizan pruebas para descubrir errores asociados con cada posible configuracin. Las pruebas de seguridad incorporan una serie de pruebas diseadas para explotar las vulnerabilidades en de software y su entorno.La intencin es encontrar huecos de seguridad. La prueba de rendimiento abarca una serie de pruebas que se disean para valorar el tiempo de respuesta y la confiabilidad del software conforme aumenta la demanda en la capacidad de recursos en el lado servidor.

Herramientas para pruebas