Protocolos de Pruebas de Software

Las pruebas de software (en ingls software testing) son las investigaciones empricas y tcnicas cuyo
objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte
interesada o stakeholder. Es una actividad ms en el proceso de control de calidad.
Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software. ependiendo
del tipo de pruebas! estas actividades podrn ser implementadas en cual"uier momento de dic#o
proceso de desarrollo. E$isten distintos modelos de desarrollo de software! as como modelos de
pruebas. % 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.
&eniendo esta afirmacin en mente! la informacin "ue puede ser re"uerida es de lo ms variada. Esto
#ace "ue el proceso de testing sea completamente dependiente del conte$to
'
en el "ue se desarrolla.
% pesar de lo "ue muc#os promueven! no e$isten las (mejores prcticas( como tal. &oda prctica puede
ser ideal para una situacin pero completamente in)til o incluso perjudicial en otra.
*or esto! las actividades! tcnicas! documentacin! enfo"ues y dems elementos "ue condicionarn las
pruebas a reali+ar! deben ser seleccionadas y utili+adas de la manera ms eficiente seg)n conte$to del
proyecto.
Pruebas estticas
,on el tipo de pruebas "ue se reali+an sin ejecutar el cdigo de la aplicacin (-eferino).
*uede referirse a la revisin de documentos! ya "ue no se #ace una ejecucin de cdigo. Esto se debe a
"ue se pueden reali+ar .pruebas de escritorio. con el objetivo de seguir los flujos de la aplicacin.
Pruebas dinmicas
&odas a"uellas pruebas "ue para su ejecucin re"uieren la ejecucin de la aplicacin.
Las pruebas dinmicas permiten el uso de tcnicas de caja negra y caja blanca con mayor amplitud.
ebido a la naturale+a dinmica de la ejecucin de pruebas es posible medir con mayor precisin el
comportamiento de la aplicacin desarrollada.
En las pruebas de software! la automatizacin de pruebas consiste en el uso de software especial (casi
siempre separado del software "ue se prueba) para controlar la ejecucin de pruebas y la comparacin
entre los resultados obtenidos y los resultados esperados. La automati+acin de pruebas permite incluir
pruebas repetitivas y necesarias dentro de un proceso formal de pruebas ya e$istente o bien adicionar
pruebas cuya ejecucin manual resultara difcil.
%lgunas pruebas de software tales como las pruebas de regresin intensivas de bajo nivel pueden ser
laboriosas y consumir muc#o tiempo para su ejecucin si se reali+an manualmente. %dicionalmente! una
apro$imacin manual puede no ser efectiva para encontrar ciertos tipos de defectos! mientras "ue las
pruebas automati+adas ofrecen una alternativa "ue lo permite. /na ve+ "ue una prueba #a sido
automati+ada! sta puede ejecutarse repetitiva y rpidamente en particular con productos de software
"ue tienen ciclos de mantenimiento largo! ya "ue incluso cambios relativamente menores en la vida de
una aplicacin pueden inducir fallos en funcionalidades "ue anteriormente operaban de manera correcta.
E$isten dos apro$imaciones a las pruebas automati+adas0
Pruebas manejadas por el cdigo0 ,e prueban las interfaces p)blicas de
las clases! mdulos o bibliotecas con una variedad amplia de argumentos de entrada y se valida "ue
los resultados de obtenidos sean los esperados.
Pruebas de Interfaz de Usuario0 /n marco de pruebas genera un conjunto de eventos de la
interface de usuario! tales como teclear! #acer clic1 con el ratn e interactuar de otras formas con el
software y se observan los cambios resultantes en la interface de usuario! validando "ue el
comportamiento observable del programa sea el correcto.
La eleccin misma entre automati+acin y ejecucin manual de pruebas! los componentes cuya prueba
ser automati+ada! las #erramientas de automati+acin y otros elementos son crticos en el $ito de las
pruebas! y por lo regular deben provenir de una eleccin conjunta de los e"uipos de desarrollo! control
de calidad y administracin. /n ejemplo de mala eleccin para automati+ar! sera escoger componentes
cuyas caractersticas son inestables o su proceso de desarrollo implica cambios continuos.
Pruebas de caja blanca
Las pruebas de caja blanca (tambin conocidas como pruebas de caja de cristal o pruebas
estructurales) se centran en los detalles procedimentales del software! por lo "ue su dise2o est
fuertemente ligado al cdigo fuente. El testeador escoge distintos valores de entrada para e$aminar cada
uno de los posibles flujos de ejecucin del programa y cerciorarse de "ue se devuelven los valores de
salida adecuados.
%l estar basadas en una implementacin concreta! si sta se modifica! por regla general las pruebas
tambin debern redise2arse.
%un"ue las pruebas de caja blanca son aplicables a varios niveles 3unidad! integracin y sistema3!
#abitualmente se aplican a las unidades de software. ,u 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.
% pesar de "ue este enfo"ue permite dise2ar pruebas "ue cubran una amplia variedad de casos de
prueba! podra pasar por alto partes incompletas de la especificacin ore"uisitos faltantes! pese a
garanti+ar la prueba e$#austiva de todos los flujos de ejecucin del cdigo anali+ado.
Las principales tcnicas de dise2o de pruebas de caja blanca son0
*ruebas de flujo de control
*ruebas de flujo de datos
*ruebas de bifurcacin (branch testing)
*ruebas de caminos bsicos
Hacking
En los tests de penetracin! las pruebas de caja blanca #acen referencia a una metodologa donde
el #ac1er posee un conocimiento total y absoluto del sistema "ue pretende atacar. El objetivo de estos
tests de penetracin! "ue perciben el sistema de forma transparente! es simular el comportamiento de un
intruso malicioso "ue contase con permisos de acceso e informacin precisa acerca del sistema.
Pruebas de caja negra
En teora de sistemas y fsica! se denomina caja negra a a"uel elemento "ue es estudiado desde el
punto de vista de las entradas "ue recibe y las salidas o respuestas "ue produce! sin tener en cuenta su
funcionamiento interno. En otras palabras! de una caja negra nos interesar su forma de interactuar con
el medio "ue le rodea (en ocasiones! otros elementos "ue tambin podran ser cajas negras)
entendiendo qu es lo que hace! pero sin dar importancia a cmo lo hace. *or tanto! de una caja
negra deben estar muy bien definidas sus entradas y salidas! es decir! su interfa+4 en cambio! no se
precisa definir ni conocer los detalles internos de su funcionamiento.
En programacin modular! donde un programa (o un algoritmo) es dividido en mdulos! en la fase de
dise2o se buscar "ue cada mdulo sea una caja negra dentro del sistema global "ue es el programa
"ue se pretende desarrollar! de esta manera se consigue una independencia entre los mdulos "ue
facilita su implementacin separada por un e"uipo de trabajo donde cada miembro va a encargarse de
implementar una parte (un mdulo) del programa global4 el implementador de un mdulo concreto deber
conocer como es la comunicacin con los otros mdulos (la interfa+)! pero no necesitar conocer como
trabajan esos otros mdulos internamente4 en otras palabras! para el desarrollador de un mdulo!
idealmente! el resto de mdulos sern cajas negras.
Testing exploratorio
El testing exploratorio o pruebas exploratorias es un estilo o enfo"ue para la reali+acin de pruebas
de software. ,u principal caracterstica es "ue el aprendi+aje! el dise2o y la ejecucin de las pruebas se
reali+an de forma simultnea. -em 5aner! "uien acu2 el trmino en '678! define el testing e$ploratorio
como (un estilo de testing "ue enfati+a la libertad personal y la responsabilidad del tester para optimi+ar
continuamente la calidad de su trabajo tratando el aprendi+aje a travs de las pruebas! el dise2o de las
pruebas! la ejecucin de las pruebas y la interpretacin del resultado de las pruebas como actividades
"ue se apoyan mutuamente y "ue se ejecutan en paralelo a lo largo del proyecto.(
9ientras se est probando el software! el tester va aprendiendo a manejar el sistema y junto con su
e$periencia y creatividad! genera nuevas pruebas a ejecutar. % menudo se piensa "ue el testing
e$ploratorio como una tcnica de prueba de caja negra. ,in embargo! a"uellos "ue lo #an estudiado! lo
consideran un enfo"ue "ue se puede aplicar a cual"uier tcnica de pruebas! en cual"uier etapa del
proceso de desarrollo. La clave no es la tcnica ni el elemento "ue estamos probando o revisando4 la
clave es el compromiso cognitivo del tester y la responsabilidad del tester para gestionar su tiempo.
Prueba unitaria
En programacin! una prueba unitaria es una forma de probar el correcto funcionamiento de un mdulo
de cdigo. Esto sirve para asegurar "ue cada uno de los mdulos funcione correctamente por separado.
Luego! con las *ruebas de :ntegracin! se podr asegurar el correcto funcionamiento del sistema o
subsistema en cuestin.
La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo! de forma "ue
cada caso sea independiente del resto.
Caractersticas
*ara "ue una prueba unitaria sea buena se deben cumplir los siguientes re"uisitos0
utomatizable
;o debera re"uerirse una intervencin manual. Esto es especialmente )til para integracin continua.
!ompletas
eben cubrir la mayor cantidad de cdigo.
"epetibles o "eutilizables
;o se deben crear pruebas "ue slo puedan ser ejecutadas una sola ve+. &ambin es )til
para integracin continua.
Independientes
La ejecucin de una prueba no debe afectar a la ejecucin de otra.
Profesionales
Las pruebas deben ser consideradas igual "ue el cdigo! con la misma profesionalidad! documentacin!
etc.
%un"ue estos re"uisitos no tienen "ue 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 "ue las partes
individuales son correctas. *roporcionan un contrato escrito "ue el tro+o de cdigo debe satisfacer.
#imitaciones
Es importante darse cuenta de "ue las pruebas unitarias no descubrirn todos los errores del cdigo. *or
definicin! slo prueban las unidades por s solas. *or lo tanto! no descubrirn errores de integracin!
problemas de rendimiento y otros problemas "ue afectan a todo el sistema en su conjunto. %dems!
puede no ser trivial anticipar todos los casos especiales de entradas "ue 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.
Herramientas
JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck Se encuentra
basado en SUnit creado ori!inalmente para reali"ar pruebas unitarias para el len!ua#e
Smalltalk
$est%G: &reado para suplir al!unas deficiencias en JUnit
J$i!er: Basado en anotaciones' como $est%G
Simple$est: Entorno de pruebas para aplicaciones reali"adas en P(P
P(PUnit: Sistema para la reali"aci)n pruebas unitarias en P(P
&PPUnit: *ersi)n del framework para len!ua#es &+&,,
%Unit: *ersi)n del framework para la plataforma%E$
-o.Unit: Entorno /penSource de pruebas unitarias para 0icrosoft *isual -o.Pro
0/1: Entorno para la creaci)n din2mica de ob#etos simuladores 3mocks4 50/16
1Unit: 7ibrer8a para pruebas unitarias en Javascript &reada por la fundaci)n #1uery' ha sido
reescrita para ser independiente de la librer8a #1uery
libunittest: 7ibrer8a portable para pruebas unitarias en &,, 9ue usa el nuevo est2ndar &,,::
Prueba de integracin
Pruebas integrales o pruebas de integracin son a"uellas "ue se reali+an en el mbito del desarrollo
de software una ve+ "ue se #an aprobado las pruebas unitarias. <nicamente se refieren a la prueba o
pruebas de todos los elementos unitarios "ue componen un proceso! #ec#a en conjunto! de una sola
ve+.
-onsiste en reali+ar pruebas para verificar "ue un gran conjunto de partes de software funcionan juntos.
Las pruebas de integracin (algunas veces llamadas integracin y testeo :=t) es la fase de la prueba de
software en la cual mdulos individuales de software son combinados y probados como un grupo. ,on
las pruebas posteriores a las pruebas unitarias y preceden a las pruebas del sistema.
Prueba funcional
/na prueba funcional es una prueba basada en la ejecucin! revisin y retroalimentacin de las
funcionalidades previamente dise2adas para el software. Las pruebas funcionales se #acen mediante el
dise2o de modelos de prueba "ue buscan evaluar cada una de las opciones con las "ue cuenta el
pa"uete informtico. ic#o de otro modo son pruebas especficas! concretas y e$#austivas para probar y
validar "ue el software #ace lo "ue debe y sobre todo! lo "ue se #a especificado.
Las pruebas funcionales se dividen en las siguientes fases0
n$lisis de requisitos %Planificacin&
En esta fase se inicia la elaboracin del modelo jerr"uico de re"uisitos de prueba partiendo de los
procesos funcionales "ue soporta el producto o activo de software a evaluar. % partir de las
funcionalidades se elaborar el plan de pruebas. >ay "ue obtener toda la informacin posible de las
aplicaciones sobre las cuales se reali+arn las pruebas. Esta informacin se deber conseguir de toda la
documentacin disponible sobre su funcionamiento y #ablando con el personal responsable de la misma.
'ise(o del plan de pruebas %Preparacin&
En esta fase se identifica! acuerda y especifican los atributos y caractersticas de calidad "ue se van a
probar. El objetivo es dise2ar las pruebas para "ue tengan la mayor probabilidad de encontrar defectos
con la mnima cantidad de esfuer+o y tiempo. ,ern pruebas "ue se llevarn a cabo a travs de la
interfa+ grfica del software (?/:). Es decir! demostrar "ue las funciones del software son operativas!
"ue la entrada se acepta de forma adecuada y "ue se produce una salida correcta! as como "ue la
integridad de la informacin e$terna se mantiene. ,e crearn casos de prueba divididos en pasos (steps)
para cada accin a reali+ar con un resultado esperado asociado! "ue podr ser verificado. urante la
fase de dise2o tambin se especifican los datos de entrada necesarios para "ue los casos de pruebas
definidos puedan ser ejecutados (ya sea buscando el $ito de la prueba! o bien el fallo).
)jecucin
En esta fase se ejecutarn los casos de prueba anteriormente dise2ados de forma manual. >ay "ue
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 ve+ antes del paso a
produccin! independientemente de las ejecuciones anteriores. Los casos de prueba fallados se
reportarn a los desarrolladores para su correccin #asta "ue su resultado sea correcto.
*estin de Incidencias %'efectos&
La gestin de incidencias es una parte implcita de la fase de ejecucin! pero "ue al tener una alta
importancia en las pruebas funcionales! diferenciamos como una etapa independiente. -uando al reali+ar
la accin de un step el resultado obtenido no es el esperado! #abr "ue abrir o reportar una incidencia
para "ue el e"uipo de desarrollo tenga constancia del error. La gestin de incidencias es el principal
canal de comunicacin con el e"uipo de desarrollo. Las incidencias #an de ser claras y con todo lujo de
detalle! tienen "ue describir el error para "ue el e"uipo de desarrollo pueda comprenderlo perfectamente!
reproducirlo! locali+arlo y poder solucionarlo. ,e deber mantener una continua comunicacin con el
e"uipo de desarrollo para conocer el estado de los defectos y poder reali+ar las repruebas necesarias
para su cierre.
Las pruebas funcionales pueden ser! seg)n su ejecucin0
+anuales
Las pruebas funcionales manuales son las "ue ejecuta un tester como si fuese un usuario pero siguiendo
una serie de pasos establecidos o test plan! dise2ado en el anlisis de los re"uisitos para garanti+ar "ue
#ace lo "ue debe (casos positivos)! "ue no falla (casos negativos) y "ue es lo "ue se #a solicitado. El
tester reali+ar las acciones indicadas en cada step del caso de prueba comprobando "ue se cumple el
resultado esperado. ,i el resultado es distinto al esperado! se reportar un defecto con todo detalle0
descripcin! datos utili+ados! capturas de pantalla! etc. para facilitar la solucin del defecto por parte de
los desarrolladores.
utom$ticas
Las pruebas funcionales automticas son pruebas funcionales "ue se automati+an para (a#orrar tiempo
de pruebas(. % partir de los casos de prueba de las pruebas manuales! se automati+an los casos de
prueba "ue se repitan en las ejecuciones. Esos casos suelen ser los ms importantes (#appy flow) de los
mdulos o procesos de negocio (vitales( de la aplicacin! es decir! los procesos "ue siempre tienen "ue
funcionar y "ue bajo ning)n concepto pueden fallar. El objetivo de las pruebas funcionales automticas
es comprobar "ue nada de lo probado con anterioridad #a dejado de funcionar como debera.
Las pruebas funcionales pueden ser! seg)n tipo de pruebas0
Pruebas exploratorias
,on a"uellas pruebas a travs de las cuales! simultneamente! se obtiene un aprendi+aje y conocimiento
de la aplicacin a probar a la ve+ "ue se genera un valor desde el primer momento. %yudan a la
integracin de la fase de pruebas de una forma muc#o ms rpida! pues permiten al tester elaborar un
guion de pruebas "ue utili+ar para el dise2o de los futuros planes de pruebas. Estas pruebas son
realmente )tiles a la #ora de probar aplicaciones ya desarrolladas! es decir! a"uellas pruebas de
software "ue no comien+an a la ve+ "ue el desarrollo. *ara reali+ar las pruebas funcionales e$ploratorias
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 e$ploratorias 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 "ue cambios
reali+ados 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 ve+ "ue se
#ace un cambio en el sistema! tanto para corregir un error como para reali+ar una mejora. ;o es
suficiente probar slo los componentes modificados o a2adidos! o las funciones "ue en ellos se reali+an!
sino "ue tambin es necesario controlar "ue las modificaciones no produ+can efectos negativos sobre el
mismo u otros componentes. Este tipo de pruebas tiene "ue garanti+ar "ue tras un cambio en el
software! al menos la funcionalidad ms importante sigue funcionando. *ara este tipo de pruebas lo ideal
es automati+ar los casos "ue validen "ue 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 reali+as en cada navegador de internet! sistema
operativo o dispositivo! para garanti+ar el correcto funcionamiento del aplicativo en todos los medios. El
mismo software puede presentar errores dependiendo de dnde se ejecute0 funcionales (botones y
enlaces pueden dejar de funcionar! producen errores de sistema o simplemente no reali+an la
funcionalidad esperada)! estticos (pueden descuadrarse frames de la aplicacin! no cargarse imgenes!
desaparecer enlaces o botones! te$tos).
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 ve+ "ue
#an sido probados unitariamente con el fin de comprobar "ue interact)an correctamente a travs de sus
interfaces! cubren la funcionalidad establecida y se ajustan a los re"uisitos.
Pruebas de aceptacin
El objetivo de las pruebas de aceptacin es validar "ue un sistema cumple con el funcionamiento
esperado y permitir al usuario de dic#o sistema "ue 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! "ue es el "ue valida y verifica "ue el alcance es el correcto.
+etodolog,as
#a metodolog,a est$ndar o en cascada
Es una metodologa lineal. ,e ordenan rigurosamente las etapas del proceso de tal forma "ue el inicio de
cada etapa debe esperar a la finali+acin de la etapa anterior. El e"uipo de pruebas trabaja de forma
paralela al e"uipo de desarrollo y empie+a a ejecutar o pasar las pruebas una ve+ el desarrollo est
completado.
#as metodolog,as $giles
,e basan en el desarrollo iterativo e incremental! donde los re"uerimientos y soluciones evolucionan
mediante la colaboracin de grupos auto@organi+ados y multidisciplinarios! minimi+ando riesgos
desarrollando en lapsos cortos de tiempo. Estos lapsos se denominan (:teracin(. -ada iteracin del ciclo
de vida incluye0 planificacin! anlisis de re"uerimientos! dise2o! codificacin! revisin y documentacin.
/na iteracin no debe agregar demasiada funcionalidad para justificar el lan+amiento del producto al
mercado! pero la meta es tener algo tangible (sin errores) al final de cada iteracin. %l final de cada
iteracin el e"uipo vuelve a evaluar las prioridades del proyecto.
!aso de prueba
En la ingeniera del software! los casos de prueba o -est !ase son un conjunto de condiciones o
variables bajo las cules el analista determinar si el re"uisito de una aplicacin es parcial o
completamente satisfactorio.
,e pueden reali+ar muc#os casos de prueba para determinar "ue un re"uisito es completamente
satisfactorio. -on el propsito de comprobar "ue todos los re"uisitos de una aplicacin son revisados!
debe #aber al menos un caso de prueba para cada re"uisito a menos "ue un re"uisito tenga re"uisitos
secundarios. En ese caso! cada re"uisito secundario deber tener por lo menos un caso de prueba.
%lgunas metodologas como A/* recomiendan el crear por lo menos dos casos de prueba para cada
re"uisito. /no de ellos debe reali+ar la prueba positiva de los re"uisitos y el otro debe reali+ar la prueba
negativa.
,i la aplicacin es creada sin re"uisitos formales! entonces los casos de prueba se escriben basados en
la operacin normal de programas de una clase similar.
Lo "ue caracteri+a un escrito formal de caso de prueba es "ue #ay una entrada conocida y una salida
esperada! los cuales son formulados antes de "ue se ejecute la prueba. La entrada conocida debe
probar una precondicin y la salida esperada debe probar una pos condicin.
Bajo circunstancias especiales! podra #aber la necesidad de ejecutar la prueba! producir resultados! y
luego un e"uipo de e$pertos evaluara si los resultados se pueden considerar como (correctos(. Esto
sucede a menudo en la determinacin del n)mero del rendimiento de productos nuevos. La primera
prueba se toma como lnea base para los subsecuentes ciclos de pruebasClan+amiento del producto.
Los casos de prueba escritos! incluyen una descripcin de la funcionalidad "ue se probar! la cual es
tomada ya sea de los re"uisitos o de los casos de uso! y la preparacin re"uerida para asegurarse de
"ue la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de pruebas.
Las variaciones de los casos de prueba son com)nmente utili+adas en pruebas de aceptacin. La prueba
de aceptacin es reali+ada por un grupo de usuarios finales o los clientes del sistema! para asegurarse
"ue el sistema desarrollado cumple sus re"uisitos. La prueba de aceptacin de usuario se distingue
generalmente por la incorporacin de un trayecto feli+ o casos de prueba positivos.
'imensiones de calidad
La calidad se incorpora en una aplicacin web como consecuencia de un buen dise2o. ,e eval)a
aplicando una serie de revisiones tcnicas "ue valoran varios elementos del modelo de dise2o y un
proceso de prueba "ue se estudia a lo largo de este captulo. &anto las revisiones como las pruebas
e$aminan una o ms de las siguientes dimensiones de calidad0
El contenido se eval)a tanto en el nivel sintctico como en el semntico. En el primero! se valora
vocabulario! puntuacin y gramtica para documentos basados en te$to. 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 ambigDedad.
La funcin se prueba para descubrir errores "ue indican falta de conformidad con los re"uerimientos del
cliente. -ada funcin del sistema se valora en su correccin! inestabilidad y conformidad general con
estndares de implantacin adecuados (por ejemplo! estndares de lenguaje Eava o %E%F).
La estructura se valora para garanti+ar "ue entrega adecuadamente el contenido y la funcin de la
aplicacin! "ue es e$tensible y "ue puede soportarse conforme se agregue nuevo contenido o
funcionalidad.
La usabilidad se prueba para asegurar "ue la interfa+ soporta a cada categora de usuario y "ue puede
aprender y aplicar toda la sinta$is y semntica de navegacin re"uerida.
La navegabilidad se prueba para asegurar "ue toda la sinta$is y la semntica de navegacin se ejecutan
para descubrir cual"uier 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 "ue el sistema responde a la interaccin con el usuario y "ue maneja la carga e$trema 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 "ue sean especficos de una configuracin
anfitrin )nico.
La :nteroperabilidad se prueba para garanti+ar "ue el sistema tiene interfa+ adecuada con otras
aplicaciones yCo bases de datos.
La seguridad se prueba al valorar las vulnerabilidades potenciales e intenta e$plotar cada una. -ual"uier
intento de penetracin e$itoso se estima como un fallo de seguridad.
)rrores dentro de un entorno webapp
Los errores "ue se encuentran como consecuencia de una prueba e$itosa de una webapp tienen algunas
caractersticas )nicas0
*uesto "ue muc#os tipos de pruebas de webapps descubren problemas "ue se evidencian primero en el
lado del cliente (es decir! mediante una interfa+ 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.
*uesto "ue 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 "ue originalmente se
encontr.
%un"ue algunos errores son resultado de dise2o incorrecto o codificacin >&9L (u otro lenguaje de
programacin) impropia! muc#os errores pueden rastrearse en la configuracin de la webapp.
ado "ue las webapps residen dentro de una ar"uitectura cliente@servidor! los errores pueden ser
difciles de rastrear a travs de tres capas ar"uitectnicas0 el cliente! el servidor o la red en s.
%lgunos errores se deben al entamo operativo esttico (es decir! a la configuracin especfica donde se
reali+a la prueba mientras "ue 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 "ue 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 muc#os 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 cual"uier conte$to) es un anatema para algunos desarrolladores
web "ue no planifican4 slo arrancan! con la esperan+a de "ue surja una webapp asesina.
/n enfo"ue ms disciplinado reconoce "ue la planificacin establece un mapa de ruta para todo el
trabajo "ue va despus. Gale la pena el esfuer+o.

E$cepto por el ms simple de los sitios web! rpidamente resulta claro "ue es necesaria alguna especie
de planificacin de pruebas. -on demasiada frecuencia! el n)mero inicial de errores encontrados a partir
de una prueba ad #oc es suficientemente grande como para "ue no todos se corrijan la primera ve+ "ue
se detectan. Esto impone una carga adicional sobre el personal "ue prueba sitios y webapps.
;o slo deben idear nuevas pruebas imaginativas! sino "ue tambin deben recordar cmo se ejecutaron
las pruebas anteriores con la finalidad de volver a probar de manera confiable el sitioCwebapp! y
garanti+ar "ue se removieron los errores conocidos y "ue no se introdujeron algunos nuevos.
Las preguntas "ue deben plantearse son0 Hcmo se (idean nuevas pruebas imaginativas( y sobre "u
deben enfocarse dic#as pruebasI Las respuestas a estas preguntas se integran en un plan de prueba
"ue identifica0 ') el conjunto de tareasJ "ue se van a aplicar cuando comiencen las pruebas! J) los
productos de trabajo "ue se van a producir conforme se ejecuta cada tarea de prueba y 8) la forma en la
"ue se eval)an! registran y reutili+an los resultados de la cuando se reali+an pruebas de regresin. En
algunos casos! el plan de prueba se integra con el plan del proyecto. En otros! es un documento
separado.
Resumen
La meta de la prueba de software es ejercitar cada una de las muc#as dimensiones de calidad! con la
intencin de encontrar errores o descubrir conflictos "ue 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 "ue ocurren
conforme se dise2a el sistema y pruebas "ue se llevan a cabo una ve+ "ue se implanta el mismo.
La estrategia de prueba de software ejercita cada dimensin de calidad al e$aminar inicialmente
(unidades( de contenido! funcionalidad o navegacin. /na ve+ validadas las unidades individuales! la
atencin se cambia #acia pruebas "ue ejercitan el software como un todo. *ara lograr esto! muc#as
pruebas se derivan desde la perspectiva del usuario y se activan mediante la informacin contenida en
casos de uso. ,e 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 "ue afectan la precisin del contenido o la forma en la "ue se
presenta al usuario final. La prueba de interfa+ ejercita los mecanismos de interaccin "ue permiten al
usuario comunicarse con el software y valida los aspectos estticos de la interfa+. La intencin es
descubrir errores "ue resultan a partir de mecanismos de interaccin pobremente implantados o de
omisiones! inconsistencias o ambigDedades en la semntica de la interfa+.
Las pruebas de navegacin aplican casos de uso! derivados de la actividad de modelado! en el dise2o
de casos de prueba "ue ejercitan cada escenario de uso contra el dise2o de navegacin. Los
mecanismos de navegacin se ponen a prueba para garanti+ar "ue cual"uier error "ue impida completar
un caso de uso se identifi"ue y corrija. La prueba de componente ejercita las unidades de contenido y
funcionales dentro del software. La prueba de configuracin intenta descubrir errores yCo problemas de
compatibilidad "ue son especficos de un entorno cliente o servidor particular. Entonces se reali+an
pruebas para descubrir errores asociados con cada posible configuracin. Las pruebas de seguridad
incorporan una serie de pruebas dise2adas para e$plotar las vulnerabilidades en de software y su
entorno.
La intencin es encontrar #uecos de seguridad. La prueba de rendimiento abarca una serie de pruebas
"ue se dise2an 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