Web Testing

“Aspectos teóricos y prácticos”

Catherine Bidart F. Jorge Mujica A.

<cbidart@inf.utfsm.cl> <jmujica@inf.utfsm.cl>

Profesor
Dr. Marcello Visconti Z.
<visconti@inf.utfsm.cl>

Universidad Técnica Federico Santa María

Departamento de Informática
Programa de Magister en Informática

21 de Noviembre de 2002

1
 Resumen

El testing para aplicaciones web, o Web Testing, agrega técnicas y

modelos adicionales a los vistos en un modelo clásico. En este sentido,
se hace necesaria la inclusión de nuevos factores de calidad que
permitan, sin un significante esfuerzo adicional, determinar la verdadera
calidad del sitio web a probar.
Se presenta una investigación con los aspectos generales del Web
Testing, tanto en un marco teórico como práctico.

2
1. Introducción _______________________________________________ 4
2. Marco teórico ______________________________________________ 5
2.1. Conceptos de Ingeniería Web y Testing____________________________ 5
2.2. Testing clásico v/s Web testing __________________________________ 6
2.2.1. Diferencias de enfoques ______________________________________ 6
2.2.2. Dificultades del Web testing____________________________________ 8
2.3. Clasificación de sitios web _____________________________________ 10
2.4. Proceso de Web testing________________________________________ 11
2.4.1. Testing preliminar y establecimiento de requerimientos _____________ 11
2.4.2. Tipos de testing ____________________________________________ 12
2.4.2.1. Testing de unidad _____________________________________________ 12
2.4.2.2. Testing de integración __________________________________________ 12
2.4.2.3. Testing del sistema ____________________________________________ 13
2.4.2.4. Testing de validación___________________________________________ 13
2.4.2.5. Testing de regresión ___________________________________________ 14
2.4.2.6. Testing funcional ______________________________________________ 14
2.4.2.7. Testing de desempeño _________________________________________ 14
2.4.2.8. Testing de usabilidad __________________________________________ 15
2.4.2.9. Testing de compatibilidad _______________________________________ 16
2.4.2.10. Testing de seguridad ___________________________________________ 16
2.4.2.11. Testing de escalabilidad ________________________________________ 17
2.4.2.12. Testing de aceptación visual _____________________________________ 17
2.4.2.13. Testing de disponibilidad de servicio. ______________________________ 17
2.4.2.14. Testing de idioma _____________________________________________ 18
2.4.2.15. Testing de motores de búsqueda _________________________________ 18
2.4.2.16. Testing de accesibilidad ________________________________________ 18
2.4.2.17. Testability Testing _____________________________________________ 18
2.4.2.18. Testing de script (scripting testing) ________________________________ 19
2.4.3. Proceso de Web testing ______________________________________ 20
2.4.4. Estructura de un plan de Web testing ___________________________ 23
2.5. Calidad en aplicaciones Web ___________________________________ 24
2.5.1. Criterios de calidad _________________________________________ 24
2.5.1.1. Confiabilidad _________________________________________________ 24
2.5.1.2. Usabilidad ___________________________________________________ 24
2.5.1.3. Seguridad ___________________________________________________ 25
2.5.1.4. Disponibilidad ________________________________________________ 25
2.5.1.5. Escalabilidad _________________________________________________ 25
2.5.1.6. Mantenibilidad ________________________________________________ 25
2.5.1.7. Time to market________________________________________________ 25
2.5.2. Esquema de clasificación de casos de prueba ____________________ 26
3. Marco práctico ____________________________________________ 27
3.1. Testing automatizado__________________________________________ 27
3.1.1. Ventajas y desventajas ______________________________________ 27
3.1.2. Tipos de herramientas _______________________________________ 28
3.2. Utilización de herramientas en un caso practico ___________________ 28
3.2.1. Herramientas plug-in ________________________________________ 29
3.2.2. Herramientas post-desarrollo__________________________________ 29
4. Conclusiones _____________________________________________ 32
5. Referencias _______________________________________________ 34

3
1. Introducción

Un efecto natural de la globalización es la utilización de un máximo de tecnología con el objeto

de interconectar culturas, descubrir detalles en las distintas formas de pensar y, en general,
comunicar personas. Esta idea se puede reflejar en el lema “… la comunicación es un aspecto
inherente en el ser humano y social”.
Internet es el fiel ejemplo de este concepto. Quizás sus creadores (recordar que Internet fue
pensada primeramente como un mecanismos de intercomunicación académico) jamás
pensaron que alcanzaría la influencia que hoy se conoce.
La llegada del Web ha modificado el concepto que hoy se tiene de una aplicación (en relación a
una aplicación convencional de escritorio que se instala, necesita de bibliotecas especiales
en el sistema operativo, y es estático). Así, se habla de aplicación Web a aplicaciones
desplegables en un browser, y que utiliza un conjunto de estándares que permiten su
visualización en forma relativamente independiente.
Diversos son los cambios de enfoque entre estos dos tipos de aplicaciones, desde su forma de
desarrollo, hasta la forma en que se aplican pruebas a ellas. Este último punto es el que se
desea abordar a fondo en el presente documento.
Preguntas como ¿Qué pruebas debo hacer a un sitio para poder afirmar que éste es seguro?,
ó, ¿En que etapas debo aplicarlas? Desean ser respondidas en este informe, de tal forma de
comprender el ámbito de trabajo, y sus diferencias con el ámbito clásico.

La primera parte presenta un estudio teórico detallado respecto al Web Testing y sus
principales diferencias con el Testing convencional. Paralelamente, se presenta un proceso de
Testing en Web y los factores de calidad que principalmente inciden sobre el correcto
funcionamiento del sistema. La segunda parte se centra en un estudio práctico mostrando una
clasificación de las herramientas automatizadas existentes en el mercado y algunos ejemplos.

Finalmente la última sección presenta conclusiones y comentarios de interés al lector.

4
2. Marco teórico

2.1. Conceptos de Ingeniería Web y Testing

Murugesan et al. [MUR01], promotores iniciales del establecimiento de la Ingeniería Web como
una nueva disciplina, dan la siguiente definición de ingeníera Web:

Web engineering is the establishment and use of sound scientific, engineering and
management principles and disciplined and systematic approaches to the successful
development, deployment and maintenance of high quality Web-based systems and
applications.

Lo cual conlleva a pensar que en este nuevo contexto de la Ingeniería de Software, es

necesario la utilización de enfoques disciplinados y sistemáticos, herramientas y metodologías
robustas y flexibles para construir y evaluar aplicaciones Web. Según Olsina en su tesis
Doctoral [OLS99], tales estrategias, metodologías y herramientas deben tener en cuenta
aspectos específicos de este nuevo medio como:
1) El nivel de orientación a la documentación versus el nivel de orientación a la funcionalidad
de la aplicación de software;
2) La multiplicidad de los perfiles de usuarios y sus distintos comportamientos;
3) Características y atributos de calidad que respondan a las necesidades de las diferentes
audiencias en consideración de las peculiaridades del medio Web;
4) Diferentes tipos de habilidades y conocimientos de los participantes en un proyecto
centrado en la Web;
5) Procesos de desarrollo de rápida generación de productos pero flexibles y robustos, en
cuanto a la evolución tanto de la estructura y contenido, como de la funcionalidad asociada.

En vista de las características de la Web y de las aplicaciones basadas en ella, surge un

ambiente multidiciplinario en el cual es necesario considerar áreas como: interacción hombre
máquina, interfaces usuarias, análisis y diseño de sistemas, ingeniería de software, ingeniería
de requerimientos, multimedia, ingeniería de la información, testing, modelamiento, simulación,
gestión de proyectos, sociología y diseño gráfico.

5
 Figura 1: Ingeniería Web

Directamente relacionado con lo anterior, el proceso de testing que debe ser aplicado en todo
el ciclo de desarrollo, no surge como una simple extensión de los métodos tradicionales de
testing, sino más bien como una reformulación de la aplicación de tales técnicas, ya que en
este sentido, el testing debe incluir todos los aspectos que la misma ingeniería Web necesita.

2.2. Testing clásico v/s Web testing

2.2.1. Diferencias de enfoques

Las principales diferencias entre la el proceso de testing convencional y el web testing radica
básicamente en los distintos enfoques que una aplicación Web posee respecto a una
aplicación standalone.
La naturaleza dinámica de una aplicación Web agrega nuevos elementos o factores que hacen
al testing más tedioso de aplicar, y con menos posibilidades de obtener resultados confiables.
Esta diferencia nace desde el desarrollo de un proyecto orientado al Web, la Figura 2 ilustra
este hecho. Se puede apreciar que las fases de análisis y diseño presentan una diferencia
sustancial: en el caso de una aplicación clásica estas fases se efectúan en forma separada,
mientras que en el marco de una aplicación Web, estas son tareas paralelas (generalmente).
Por otra parte, la fase de testing posee la característica que se basa en probar la funcionalidad
deseada en el caso de una aplicación Web, en lugar de ser un proceso netamente destructivo
como ocurre con una aplicación convencional.

6
 Aplicación clásica Aplicación Web
Actividad
Requerimientos Basado en general en detalladas En general, son menos estrictas y se
especificaciones basan en notas, discusiones o ideas.
Planning Basadas fuertemente en experiencia. Basadas preferentemente en
disponibilidad de tiempo.
Análisis/Diseño Procesos separados formalmente. En general, se efectúan en
paralelo.
Implementación Desarrollo secuencial de componentes Transiciones iterativas de Web Sites
Integración Ensamblado de componentes (legacy Web Services
components)
Testing Se prueba la funcionalidad en contra Se basa preferentemente sobre la
las especificaciones (probar que esta funcionalidad deseada.
malo).
Release Transferencia de información a un Transferencia a un Web Server.
instalable (CD/DVD)
Mantención En promedio, 1 a 3 años En promedio, 4 a 6 meses.

Figura 2. Diferencias fundamentales entre las fases de desarrollo de una aplicación web v/s una aplicación
convencional [MAC00].

Robert L. Glass, editor general del Software Practitioner newsletter, en un artículo denominado
“Has Web Development Changed the Meaning of Testing?”, presenta un interesante estudio
comparativo respecto a la filosofía de una aplicación convencional respecto a una aplicación
web ([GLA00]).

En su opinión, estas diferencias se resumen en el siguiente listado:

· Por lo general, una aplicación web posee requerimientos livianos, esto debido a que
cualquier requerimiento solicitado se restringe por la reducida tecnología que un
browser posee. No se debe olvidar que es el browser la verdadera interfaz (o el
contenedor de la interfaz) que una aplicación web posee.
· El desarrollo de una aplicación web es rápido y poco granular. En general, la cantidad
de herramientas de desarrollo web existentes impulsan un desarrollo simple y rápido,
dejando en el olvido los editores de texto con los que se podía editar “a mano” código
HTML.
· Los proyectos web son cortos. En promedio, el autor sostiene que un proyecto web no
demora en promedio mas de tres meses y posee un equipo de, en promedio, cuatro
personas.
· El testing aplicado a un sitio web nunca es lo suficientemente minucioso, aun cuando
existen herramientas que automatizan el proceso. Si bien es cierto estas herramientas
son de buena calidad, algunas son de alto costo por lo que no son adquiridas por los
desarrolladores.

7
· En una aplicación web no se cuenta con una interacción directa entre el cliente y el
servidor, esto es, no se posee una certeza absoluta de quién es el cliente que esta
interactuando con el sistema.
· Un proyecto web es altamente dinámico, estando siempre en proceso de testing. La
idea central es que resulta simple modificar un script, o parte de un código HTML en
lugar de modificar código Visual Basic de una aplicación compilada y ejecutable.
· Una aplicación web es altamente orientada al contenido y la visualización. En términos
generales, deben existir en el testing en web técnicas que determinen una aceptación
visual por parte del usuario. Este punto será abordado en el transcurso del presente
documento.
· Finalmente, el desarrollo de una aplicación web involucra el fenómeno de “rapid
development” donde se prima un desarrollador rápido por sobre profesionales del
software, aspecto altamente cuestionado por el mundo de la ingeniería de software.

Con este listado de diferencias, se puede asumir que la aplicación de web testing involucra una
serie (no menor) de nuevos factores a probar. Estos factores conllevan la creación nuevas
técnicas de pruebas, las cuales deben ser aplicadas en las distintas fases del ciclo de vida del
proyecto.
Estas pruebas o técnicas poseen características particulares que serán explicadas a lo largo
del presente documento, brindando por ende dificultades adicionales que deben ser abordadas.

2.2.2. Dificultades del Web testing

No basta con comprender las diferencias entre web testing y testing convencional sin entender
las dificultades adicionales que el primero agrega. Estas nuevas dificultades se pueden resumir
en lo siguiente [NGU00]:

· Cuando se ve una inconsistencia en un browser, solo se esta viendo el síntoma del

error y no el error en sí. Esto es, si se observa esta inconsistencia, ¿Cómo saber el
origen de esta?, ¿Esta en el cliente (y en ese caso, en que parte)? ¿o estaá en el
servidor?. Un ejemplo claro puede ser el recibir algún mensaje como el siguiente:
Microsoft OLE DB Provider for ODBC
Drivers error '80040e14'

Se puede pensar en primera instancia que se trata de un error desde el sistema, sin
embargo, se trata de un error de mala configuración de javascript que no permite la
visualización de un objeto ActiveX en el browser. En este caso, un usuario sin
conocimientos no habría podido dar con la solución.

8
 · Resulta difícil determinar si un error es independiente o dependiente del entorno.
Supóngase que se esta probando el proceso de ingresar a un sistema de correo
(webmail), donde una prueba básica es ingresar el nombre de usuario y su
contraseña. Naturalmente que un usuario con una conexión de MODEM de 28K,
versus uno que posee conexión dedicada obtendrá distintos resultados. En este caso,
esta prueba es dependiente altamente del entorno y se asocia preferentemente a los
tiempos de respuesta.
Una prueba independiente, por otro lado, es mas simple de reproducir y se relación
básicamente a la funcionalidad del sitio, mas específicamente, al hecho de que el sitio
haga lo que tiene que hacer.
· ¿Como detectar si una inconsistencia proviene de un error de codificación o uno de
configuración? Esto es, supóngase que ocurre un problema similar al expuesto
(también desde una visión de un servidor Microsoft Personal Web Server):

Microsoft OLE DB Provider for ODBC

Drivers error '80040e14'

Resulta ser que este problema puede surgir por dos razones particulares. En primer
lugar, puede estar incorrectamente desconfigurado la opción de exploración de
directorios virtuales (y por ende el no acceso a recursos web), esto en Administrador de
Servicios Internet de Microsoft IIS. Sin embargo, por otra parte, se tiene que este
mensaje puede ser provocado por un error de programación al indicar erróneamente un
path virtual en el archivo asp (Active Server Page).

Estas dificultades hacen del Web testing una actividad no trivial que requiere de la aplicación
correcta y detallada de un conjunto de técnicas en el marco de un plan de trabajo.

9
2.3. Clasificación de sitios web

Resulta interesante clasificar los sitios web en alguna estructura que permite determinar que
pruebas son aplicables.
Thomas A. Powell, 1988, propuso la siguiente clasificación basada en el tipo de interacción
usuario-sistema ([RYD00]):

1. Sitios Web Estáticos: Corresponde al tipo mas simple de sitio web, esto es, un
documento HTML sin dinamismo donde la única opción de pagina es efectuando clicks.

2. Sitios Web Estáticos con Formularios: Formularios son utilizados para recopilar
información del usuario, por ende, esta orientado a mecanismos de recolección de
información.

3. Sitios Web con Acceso Dinámico de Datos: Se utiliza el sitio web simplemente como un
front-end de datos, los cuales están almacenados en un repositorio externo. Los
resultados son archivos HTML generados por algún motor específico.

4. Sitio Web Dinámicamente Generado: La interfaz gráfica, y cada una de las páginas
retornadas por el servidor son generadas dinámicamente. Esto es, no se retorna un
archivo sino que un simple flujo de código interpretable por el navegador.

5. Aplicaciones de Software Web: Conjunto de funcionalidad y componentes que utilizan

ambientes web (mediante métodos estándar) como medio de difusión.

Se puede apreciar que a cada uno de estos tipos es posible aplicar un conjunto de pruebas de
diferentes. Por ejemplo, un motor de búsqueda necesita de un Formulario para poder efectuar
consultas, por lo que se ubica en la segunda clasificación. Por ende, una prueba de motor de
búsqueda puede ser aplicada desde el segundo nivel en adelante.
.

10
2.4. Proceso de Web testing

2.4.1. Testing preliminar y establecimiento de requerimientos

Antes de comenzar el proceso de testing es necesario tener en consideración ciertos aspectos

como [WTP00]:
1. Reunir el equipo de testing.
2. Preparar documentación que incluya: requerimientos que fueron aceptados por el
cliente y el equipo de testing, el completo diseño funcional y especificaciones internas
del diseño, entre otros.
3. Creación de un plan de proyecto, con la identificación de los aspectos de alto riesgo.
4. Diseño del ámbito del testing, en el cual se determina los tiempos para cada fase así
como una priorización de los elementos a ser probados.
5. Verificar el ambiente de testing: hardware y software
6. Crear test scripts
7. Desarrollar un método para el seguimiento de un problema
8. Decidir el número de iteraciones a realizar.

Un aspecto muy importante a considerar, es el claro establecimiento de los business

requirements (requerimientos de negocio), que ayudarán a entender la funcionalidad del la
aplicación Web. Estos requerimientos son un conjunto de peticiones de todas las personas
interesadas en el proyecto, es decir, son los objetivos de alto nivel de la organización. Estos
objetivos responden a la visión y el ámbito del proyecto. Existen herramientas disponibles para
asistir en la disposición de los requerimientos, tales como por ejemplo: Requisite Pro de
Rational.

11
2.4.2. Tipos de testing

El testing de una software va directamente relacionado con los aspectos de calidad que sean
prioritarios para los usuarios, sin embargo, para cualquier tipo de aplicación es necesario
aplicar los siguientes tipos de testing, los cuales también podrían ser catalogados como etapas
a seguir en un proceso continuo de testing.

2.4.2.1. Testing de unidad

Pressman et al. [PRES97] explica que las pruebas de unidad centran el proceso de verificación
en el módulo, el cual es la menor unidad del diseño de software. En este tipo de pruebas
siempre se utilizan las técnicas de white-box y se pueden llevar a cabo en paralelo para
múltiples módulos.
Las pruebas que se dan como parte de la prueba de unidad comprenden: interfaces de los
módulos, estructuras locales, condiciones límites, caminos independientes y manejo de errores.
Normalmente, se considera a este tipo de prueba como algo adjunto al paso de codificación. El
diseño de los casos de prueba, comienza una vez que se ha desarrollado, revisado y verificado
la sintaxis del código a nivel de fuente.
Debido a que un módulo no es un programa independiente, se debe desarrollar para cada
prueba de unidad un software que controlo y/o resguarde. Los conductores y los resguardos
son una sobrecarga de trabajo, ya que deben desarrollarse aun cuando no forman parte del
producto final.

2.4.2.2. Testing de integración

La prueba de integración es una técnica sistemática para construir la estructura de un

programa mientras que, al mismo tiempo, se lleva a cabo pruebas para detectar errores
asociados con la interacción. El objetivo es tomar los módulos que han sido probados como
unidades, y construir una estructura del programa dictado por el diseño. Existen 2 tipos de
estrategias para realizar esta integración:

· Big Bang: se combinan todos los módulos por anticipado y se prueba el programa en
conjunto. La corrección es difícil, puesto que es complicado aislar las causas al tener que
analizar el programa completo. Al corregir se introducen nuevos errores y el proceso
continúa sin fin.
· Incremental: este tipo de estrategia se divide a su vez en:
o Descendente (Top-down testing): se integra los módulos moviéndose hacia
abajo por la jerarquía de control, comenzando por el módulo de control
principal. Los módulos subordinados al módulo principal se van incorporando a
la estructura ya sea por primero-en-profundidad o bien de forma primero-en-
anchura. Se llevan a cabo pruebas cada vez que se integra 1 módulo, hasta
completar el programa completo.

12
 o Ascendente(Buttom - up testing): empieza la construcción y la prueba con los
módulos atómicos (nivel mas bajo). Dado que los módulos se integran de abajo
hacia arriba, el proceso requerido de los módulos subordinados a un nivel
dado, siempre están disponibles eliminándose la necesidad de resguardo. Sin
embargo, al combinar grupos de módulos con funciones especificas, es
necesario crear controladores para coordinar las entradas y salidas de los
casos de prueba.
o Combinación de ambos tipos (sandwich testing).

2.4.2.3. Testing del sistema

Son una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el
sistema basado en computadora. Se consideran pruebas como:
· Recuperación: es una prueba que fuerza el fallo del software de muchas formas y verifica
que la recuperación se efectúe apropiadamente.
· Seguridad: intenta verificar que los mecanismos de protección incorporados en el sistema lo
protegerán de accesos impropios.
· Resistencia: estas pruebas están diseñadas para enfrentar a los programas con situaciones
anormales.
· Rendimiento: permiten probar el rendimiento del software en tiempo de ejecución, dentro del
contexto de un sistema integrado.

2.4.2.4. Testing de validación

Luego de la prueba de integración, el software está completamente ensamblado como un

paquete; se han encontrado y corregido los errores, y se puede comenzar a realizar las
pruebas validación. La validación del software se consigue mediante una serie de pruebas de
caja negra que demuestran la conformidad con los requisitos detallados en la especificación de
requerimientos. Un elemento importante del proceso de validación es la revisión de la
configuración. La intención de la revisión es asegurarse de que todos los elementos de la
configuración del software se han desarrollado apropiadamente, se han catalogado y están
suficientemente detallados para soportar la fase de mantenimiento. Por último, se llevan a cabo
las pruebas de aceptación, para permitir que el cliente valide todos los requisitos. Las realiza el
usuario final en lugar del responsable del desarrollo de sistema y pueden variar en cuanto a
rigurosidad y duración, según las necesidades y los recursos existentes. En este ámbito están
las llamadas pruebas alfa y beta. Las pruebas alfa son aquellas que se llevan acabo en el lugar
de desarrollo pero por un cliente. Usa el software de manera natural con el desarrollador con
observador, el cual registra los problemas y errores encontrados. Las pruebas beta son
efectuadas por los usuarios finales y en el lugar de trabajo. Normalmente el desarrollador no

13
esta presente, dándole el carácter de una simulación en vivo del software. El usuario es el que
registra los errores y se los comunica al desarrollador.

2.4.2.5. Testing de regresión

La detección de errores involucra correcciones del software, provocándose cambios en la

configuración de software ya sea en la documentación, el programa o los datos. El testing de
regresión es la actividad que ayuda a asegurar que los cambios (debido a pruebas u otros
motivos) no introduzcan un comportamiento no deseado o errores adicionales. Este tipo de
pruebas pueden ser realizadas manualmente, volviendo a realizar un subconjunto de todos los
casos de prueba o utilizando herramientas automáticas de reproducción de captura. Estas
herramientas permiten capturar casos de prueba y los resultados para la siguiente
reproducción y comparación.

Los tipos de testing señalados anteriormente, son aplicables a todo tipo de software. Los que
se nombran a continuación son aplicables, junto con los anteriores, al desarrollo de
aplicaciones Web.[DIB99]

2.4.2.6. Testing funcional

El testing funcional involucra una evaluación de todos los aspectos del sitio donde existe código
o scripts involucrado, desde la búsqueda de links defectuoso hasta probar formularios Web y
scripts. Dos estrategias utilizadas para probar los primeros son el ingreso de información real
(real-world data) y el ingreso de información errónea (denominada “extreme” data), donde la el
primer tipo hace referencia a aquella que podría ser ingresada por un usuario, mientras que la
segunda consiste en información deliberadamente aislada, para mostrar problemas
relacionados la sitio.

2.4.2.7. Testing de desempeño

El desempeño de un sitio Web es afectado principalmente por la configuración del servidor, la

configuración del cliente, por la red y por la frecuencia de peticiones. Sin embargo, dos son los
factores que siempre influyen en la variación de la configuración del servidor: fallas no
planificadas de componentes del sistema, y mantención.
La idea central es que si se esta ofreciendo un sistema de alto desempeño, existe la necesidad
de simular algunas fallas inesperadas para determinar si el sitio cumple con los requerimientos
globales de desempeño. En este caso, resulta útil y necesario diseñar pruebas que simulen las
fallas de los componentes principales de la arquitectura del sitio y del servidor (desconectar un
procesador, desconectar un cable, pagar el servidor, desahabilitar los servicios HTTP o FTP,
entre otros). Para la mantención del sistema, resulta una buena práctica el simular un proceso
de mejora a los componentes de la arquitectura, como por ejemplo, el mejorar la versión del
servidor Web o desconectar temporalmente el sistema para efectuar un respaldo.

14
Las pruebas de desempeño deben ser diseñadas con diferentes configuraciones, esto es,
pruebas con diferentes velocidades de máquinas, diferentes browsers, diferentes métodos de
acceso a internet y diferentes velocidades de conexión.

2.4.2.8. Testing de usabilidad

El testing de usabilidad desarrolla experimentos para obtener información específica acerca del
diseño de la aplicación. Involucra identificar y entender todas las respuestas y problemas que
un usuario pueda tener trabajando con la aplicación. La usabilidad es una amplia disciplina que
debe tener en consideración aspectos de diseño, facilidad de uso y facilidad de aprendizaje,
entre otros. De la misma manera necesita conocer los requerimientos mínimos del usuario
como: funcionalidad mínima requerida; limitaciones como: ancho de banda, tipo de navegador,
nuevas interfaces, plataformas, pluggins; preferencias del usuario en cuanto a gráficos y textos;
hábitos del usuario; sistemas existentes e información específica del tipo de usuario como:
edad, nivel de estudios, etc. Las herramientas mas utilizadas son las siguientes [HOR96]:
· El Card sort: se trata de lo que miran primero los usuarios.
· La entrevista: diálogo con el usuario sobre el sitio web.
· Cuestionario: listado de preguntas hacia los usuarios. Es rápida y se obtiene bastante
información.
· Test clásico de usabilidad: es un test empírico de porciones y usos concretos de la web. Es
lo mas avanzado, caro y complejo.
· Evaluación heurística: lo realiza un experto a partir de unos estándares
· Prototipado: en fases iniciales del sitio.
· Estudio de campo: periodo semi estructurado de información de usuarios en su entorno
natural.
· Sesión automatizada: esto se realiza con un navegador automático.
· Focus group: sesiones informales.
· Pensamientos en voz baja: sirve para captar momentos de confusión, errores y
preconcepciones del usuario.

En general el test de usabilidad se utiliza a través del ciclo de vida del desarrollo del producto.
En las etapas tempranas del proceso de desarrollo, el test de una versión previa o del producto
de un competir proporciona referencias muy útiles al equipo de diseño. En las etapas medias,
el test valida el diseño e informa sobre las posibilidades de refinamiento del mismo. En etapas
posteriores, el test asegura que el producto alcanza los objetivos del diseño.

15
2.4.2.9. Testing de compatibilidad

Este tipo de testing asegura que el sitio Web funciona correctamente en todo tipo de clientes,
browsers, versiones de browser, plataformas y diferentes maquinas. Desgraciadamente, el
esfuerzo de normalización de los diferentes estándares, desde HTML al DOM, todavía no
garantiza un comportamiento igual entre los browsers y requiere un esfuerzo de test adicional.
Es imprescindible que el sitio Web ofrezca el mismo grado de funcionalidad con todos los
browsers del mercado, o al menos las versiones más habituales de Netscape e Internet
Explorer.
Es también realidad que los browsers no se comporten de manera igual en Windows, MacOS o
UNIX. Es por esto necesario probar el sitio con la mayoría de las plataformas del mercado y
todas sus versiones (Windows, MacOS, Linux, Solaris, HP-UX, AIX, Irix, etc).

2.4.2.10. Testing de seguridad

El aspecto de seguridad es uno de los más importantes, debido a la magnitud de las

transacciones que se realizan sobre Internet. Es por eso que en el desarrollo del producto, es
vital cubrir un conjunto mínimo de condiciones de seguridad que engloben tanto la privacidad
del usuario como la estabilidad del servicio.
Mecanismos como el intercambio de claves publicas, más algoritmos de encriptación han
permitido cubrir el primer punto. La estabilidad del servicio debe ser cubierta generales por el
uso de sistemas de respaldo y redundancia de información (sistemas RAID en otros niveles).
Testing de seguridad vela por el cumplimiento de estas primitivas de funcionamiento, las cuales
se pueden resumir en:

· Autenticación: Validar que quien hace las acciones sea efectivamente quien dice ser
(ingreso a un sistema).
· Integridad: La información debe ser correcta independiente de errores o inconsistencias
externas.
· Privacidad: La información debe ser visible solo por los usuarios autorizados.
· Non-repudiation: El servicio debe estar en línea, mas aun si se trata de servicios críticos
(un banco en línea por ejemplo).
· Disponibilidad: El servicio debe estar disponible aun en presencia de fallas (uso de
sistemas RAID, clusters, entro otros)

Esta categoría de testing engloba un conjunto de técnicas y pruebas aplicables entre las que
destacan:

16
 · Pruebas de validación de algoritmos, donde la idea es verificar los pasos en la
generación de claves publicas y firmas electrónicas (algoritmos RSA, DES, entre otros).
· Pruebas de penetración, en los que se desea simular los mecanismos habituales de
penetración por parte de un atacante (man-in-the-middle atacas), y
· Pruebas de servicios web, en los que es deseable probar los mecanismos de seguridad
del servicio web (autorización de path virtuales, listado de archivos de directorio,
acceso a script asp o php, entre otros).

2.4.2.11. Testing de escalabilidad

Los tests de escalabilidad ayudan a caracterizar el sistema, a identificar cuándo y cómo se

degrada el acceso al sitio WEB en función del número de accesos. Para esto es posible crear
escenarios de navegación basados en casos de uso reales y con la ayuda de herramientas se
simula hasta miles de transacciones simultáneas. La idea es buscan el punto de ruptura del
sistema y los cuellos de botella a fin de ayudar a dimensionar mejor la arquitectura. También se
mide el volumen de datos intercambiados, las tasas de fallo o el tiempo total de transacción
para darle una imagen real de la experiencia de un usuario.

2.4.2.12. Testing de aceptación visual

Este tipo de testing asegura que el sitio tiene la apariencia deseada. Esto incluye revisar la
integración gráfica, así como la simple confirmación de que el sitio “se ve bien”. En este punto
es importante probar que entre las paginas del sitio exista consistencia visual y gráfica.
Las pruebas deben ser realizadas en distintos entornos como: distintas tarjetas gráficas,
frecuencias de refresco, resolución de colores (256, 32 y 16 bits) y de pantalla (1024*768,
800*600, etc.), entre otras.
Es importante señalar, que esta es una de las primeras pruebas que el usuario
inconscientemente efectúa puesto que, en teoría, este puede retener un numero fijo de
conceptos. Diversos son los ejemplos de sitios web sobrecargados de componentes que
provocan el rechazo inmediato por parte del usuario.

2.4.2.13. Testing de disponibilidad de servicio.

Se simula durante un periodo amplio de tiempo un tráfico regular, sin sobrecarga. Las pruebas diseñadas
permiten comprobar cuánto tiempo el sistema trabajará con un rendimiento óptimo, o si el servicio esta
sufriendo una degradación lenta.

17
2.4.2.14. Testing de idioma

Un aspecto que muchas veces se le da poca importancia es al idioma en que será utilizada la
aplicación. Es por eso importante realizar pruebas reales en los idiomas que se desea, donde
no sólo exista una prueba superficial sino que se prueben las funcionalidades del sitio en
condiciones de uso reales, con el sistema operativo y el browser de los idiomas seleccionados.

2.4.2.15. Testing de motores de búsqueda

En caso que el sitio Web posea un motor de búsqueda, es necesario probar si entrega los
resultados correctos y los más semejantes al patrón de búsqueda. Para esto las pruebas deben
estar orientadas las expresiones regulares aceptadas por el motor. Otro factor a probar es la
velocidad de procesamiento del motor.

2.4.2.16. Testing de accesibilidad

Este tipo de testing [AQA02] está orientado a que personas con discapacidades pueden
navegar y ejecutar las acciones deseadas en el sitio Web. Para analizar los problemas de
accesibilidad que las páginas de un sitio web van a generar en estos usuarios, se intenta
simular el modo en que ellos van a acceder a las mismas. Para ello, se emplean los mismos
navegadores alternativos que estas personas usan, o un programa que simule su
funcionamiento.
La accesibilidad no es de interés únicamente para las personas con discapacidad sino que
mejora el acceso a la Web en general. Con el fin de facilitar el acceso y la navegación en estas
y otras condiciones, el WAI (Web Accessibility Initiative) perteneciente al W3C desarrolló un
conjunto de pautas o reglas básicas de accesibilidad, que deben ser revisadas y probadas.

2.4.2.17. Testability Testing

Este tipo de testing hace referencia a la capacidad de un sistema de poder ser probable,
después de sufrir una serie de cambios importantes en su configuración. Por ejemplo, si a un
sitio Web (que ya pudo haber sido probado) se le efectúa un proceso de mejora a un
componente importante, es vital que el proceso de testing aplicado a la versión anterior (antes
del cambio) soporte esta acción; o que el proceso de mejora sea compatible y consistente con
el plan de testing.

18
2.4.2.18. Testing de script (scripting testing)

Los elementos de script asociados a una pagina web, y por ende a un sitio web, se pueden
clasificar en tres categorías:
· Código visible: el cual es accesible públicamente por los usuarios desde el browser. Por
ejemplo: HTML, Javascript y VBscript.
· Código generador: el cual es ejecutado en el servidor web y tiene como salida código
visible (asp, php, perl, jsp), y no puede ser accesado en forma directa por el usuario.
· Componentes incrustados: los cuales son ejecutables en el browser (con alguna extensión
o plug-in previamente instalada), sin que el usuario tenga acceso a su código fuente. Por
ejemplo: applet de java, video Quicktime o un archivo de Realmedia.

Para la primera categoría es factible aplicar técnicas de caja blanca, por contar con el código
de forma directa. Esto también es aplicable al código generador en caso con contar acceso a
él, aun así, un usuario podría aplicar técnicas de caja negra al recibir como salida código visible
ante ciertos parámetros de entrada. Los componentes incrustados, por otra parte, solo pueden
recibir pruebas de caja negra por no contar con el código fuente.

19
2.4.3. Proceso de Web testing

Para realizar testing es necesario entenderlo no como una etapa dentro del proceso de
desarrollo de software, sino como un proceso que se desarrolla en forma paralela al ciclo de
desarrollo.

Figura 3: Proceso de testing

El diagrama V, es una forma de mirar el flujo del software y analizar el desarrollo de un sitio
web. En el lado izquierdo se muestra la secuencia de descomposición y diseño del sistema,
mientras que en el lado derecho del diagrama, se presenta la secuencia de integración,
verificación, validación del software e implementación [WTP00].

Figura 4: Diagrama V

20
Este diagrama muestra con claridad que las etapas del lado izquierdo entregan los principales
escenarios para ser probados en las etapas posteriores. De esta forma, se observa que la
estrategia de testing presenta una cronología inversa a la que a la que se da en el desarrollo de
software. En el caso puntual del análisis y captura de requerimientos, se obtienen todas las
especificaciones del usuario que serán contrastadas en la etapa de testing de aceptación.
Sucede de manera análoga con el diseño, el cual entregará las pautas y escenarios para
probar que el sistema responde a las especificaciones de diseño establecida. En la etapa del
diseño del hardware y software, se provee los escenarios que serán probados en la etapa de la
integración de los módulos, para finalmente legar al testing unitario que prueba cada modulo
por separado.

Es importante destacar, que esta estructura es flexible, ya que depende de las características
del software a desarrollar el número específico de iteraciones que se realicen para alcanzar la
completitud del proceso de testing. Junto con esto será variable el tipo de testing a aplicar en
cada etapa.

A continuación se propone una clasificación de los tipos de testing según la fase del proceso en
que se aplica.

21
 y

de

de
implementación
Requerimientos

Implantación

Mantención
Integración

Integración
Fases

módulos

sistema
Análisis
Diseño
Testing de unidad ü ü
Testing de integración ü ü
Testing de sistema ü ü ü
Testing de validación
ü1 ü ü
Testing de regresión ü
Testing funcional
ü1 ü ü
Testing de desempeño
ü1 ü ü
Testing de usabilidad ü ü
Testing de escalabilidad ü ü ü ü
Testing de aceptación de usuario
ü2 ü1 ü ü
Testing de disponibilidad de servicio ü ü
Testing de idioma ü ü
Testing de motor de búsqueda ü ü ü ü ü
Testing de accesibilidad ü ü
Testability Testing ü ü ü ü ü
Scripting Testing ü ü
Testing de Seguridad ü ü ü
Testing de Compatibilidad ü ü ü

1
Se asume en esta etapa que el sistema esta empaquetado debidamente (aun no esta en línea) por lo
cual puede aplicarse un testing de validación.
2
Un enfoque de captura de requerimientos consiste en mostrar al cliente un prototipo semi-funcional con
lo cual validar los deseos de este. Se puede aplicar un testing de aceptación de usuario en este caso.

22
2.4.4. Estructura de un plan de Web testing

La estructura general de un plan de testing tiene la siguiente estructura [WTP00]:

1. Introducción
2. Objetivos y tareas
3. Riesgos
3.1. Identificar y priorizar áreas de riesgo: por ejemplo, cuando los casos de prueba no
sean documentados.
3.2. Identificar dependencias de pruebas sobre actividades externas: en caso de estar
relacionadas con hitos del mismo proyecto.
3.3. Planes de contingencia para los riesgos: cursos de acción a seguir en caso de
problemas.
4. Estrategia de testing
4.1. Testing funcional: contempla aspectos como el procedimiento para diseñar casos
prueba, definir condiciones y validación de estos casos.
4.2. Testing de GUI: es necesario considerar aspectos como: botones, menús, toolbars,
formularios, fuentes, etc.
4.3. Testing de usabilidad: aspectos navegacionales, ayuda, links, desempeño del sistema,
seguridad, entre otros.
5. Requerimientos de hardware y software: en cuanto browser, sistemas periféricos, software
antivirus, etc.
6. Requerimientos del entorno: principalmente se refiere a realizar pruebas en 2 tipos de
workstation: primero en aquellas que no poseen ningún software aparte de la aplicación
que se desea probar y segundo, en otras workstation donde existan otros tipos de
aplicaciones, de manera de probar las interacciones entre ellas.
7. Planificación de pruebas y del proyecto
8. Recurso: humanos, financieros y temporales.
9. Procedimiento de pruebas: tipos de estrategia a seguir
10. Procedimiento de control
11. Resultados de pruebas
12. Aprobación :criterios de aceptación.

23
2.5. Calidad en aplicaciones Web

2.5.1. Criterios de calidad

Como consecuencia de las diferencias que existen entre el desarrollo tradicional y el desarrollo
en Web, hay una serie de factores, del enfoque tradicional, que no serán relevantes al
momento de medir la calidad en el desarrollo en Web. De los atributos tradicionales, los
considerados más relevantes son:

1. Corrección: Si satisface las especificaciones del cliente en forma correcta.

2. Fiabilidad: Si el programa lleva a cabo las funciones con la presición requerida.
3. Eficiencia: Cantidad de recursos y código requerido para que el programa realice sus
funciones.
4. Integridad: Grado en que puede controlarse el acceso al software a los datos.
5. Facilidad de Uso: Es de gran importancia dado que la cantidad de usuarios es mayor que
la de un software normal.
6. Facilidad de Mantenimiento: Ya que los sitios Web son constantemente modificados o
actualizados.
7. Portabilidad: A pesar de que en la mayoría de los casos el producto Web es portable,
existen casos que, por falta de estándares, escapan a esta posibilidad.
8. Reusabilidad: Debido a las características objetuales del desarrollo se torna muy fácil
reutilizar componentes.

Específicamente el éxito de las aplicaciones Web está basado en considerar los siguientes
crietrios de calidad [OFF02]:

2.5.1.1. Confiabilidad

Actualmente la importancia de las transacciones que se realizan en el Web, hace indispensable

que los usuarios tengan confianza en la utilización de tales servicios. Transacciones a nivel
B2C, B2B, entre otras, involucran, grandes montos de dinero con consecuencias desatrosas en
caso de fallas.

2.5.1.2. Usabilidad

La usabilidad en aplicaciones web, involucra aspectos de ingeniería de facilidad de uso, diseño,

psicología y muchas otras áreas que son necesarias considerar de manera que los usuarios
sean capaces de entender y usar el sitio web. En este sentido será vital diferenciar los tipos de
usuarios y como será la capacidad de aprendizaje de ellos, ya que de no ser asi poco interesan
otros aspectos de desempeño, si el sitio web no es usado.

24
2.5.1.3. Seguridad

Los detalles inherentes de un sitio web involucran un critico aspecto de seguridad, el cual se
transforma en un factor vital de calidad.
En estricto rigor, la seguridad de calidad esta relacionado con cumplir los parámetros básicos
de autenticidad, privacidad e integridad y, por ende, la correcta utilización de los algoritmos de
claves publica, firmas digitales y encriptación necesarios para efectuar correctas transacciones
electrónicas.

2.5.1.4. Disponibilidad

La disponibilidad puede ser definida como la cantidad de tiempo que el sitio web permanece
accesible. La idea es que los usuarios puedan acceder a ella en cualquier instante que lo
deseen: 24/7/365, donde las limitación físicas y temporales dejan de existir. De ser de otra,
manera fácilmente un usuario puede cambiar la pagina e irse a otro proveedor del mismo
servicio. La disponibilidad puede ser descompuesta en varios tipos: disponibilidad de host,
servicio y red. Otro aspecto importante es la inacsequibilidad de la red que puede ser por
motivos de desperfectos de la red, mantención o actualizaciones.

2.5.1.5. Escalabilidad

Se entiende por escalabilidad a la medida de la capacidad de una aplicación de ofrecer mejor

rendimiento a medida que se le asignen mas recursos (memoria, procesos o equipos).
Generalmente se trata de una medida de la tasa de cambio del rendimiento, con respecto al
número de procesadores.

2.5.1.6. Mantenibilidad

Actualmente el rápido cambio de tecnologías, metodología de diseño y de implementación,

hacen necesarios la mantenibilidad de las aplicaciones web, ya que de no ser así, rápidamente
quedaran obsoletas interfaces, modelos, estructuración de información, y muchos otros
aspectos relacionados con el hardware y software existentes..

2.5.1.7. Time to market

Este concepto es clave en los negocios sobre la web, ya que junto con los estándares de
calidad, se exige rapidez para estar a disponibilidad de los usuarios, ya que de nos ser así
rápidamente puede aparecer otro competidor que ocupara el lugar deseado.

25
2.5.2. Esquema de clasificación de casos de prueba

Según el artículo “A Quality - Driven Approach to Web Testing” se platea un esquema para
organizar y clasificar casos de prueba en función de tres dimensiones: aspectos de calidad,
características del sistema y fases del desarrollo [RAM99].

Desde un punto de vista del testing, es posible distinguir que los aspectos de calidad y las
características del sistema son ortogonales., ya que pueden ser entendidas como 2
dimensiones del testing. Mientras la primera dimensión esta en función de los aspectos de
calidad del sistema que será probado, la segunda dimensión se focaliza en las características
de ese sistema. Esta idea de tratar por separado a los aspectos y a las características, enfatiza
que las características son principalmente los objetos de prueba, mientras los aspectos de
calidad son mas bien las metas de las pruebas. Ambas dimensiones son necesarias para
describir un caso de prueba. Esta visión ayuda bastante a identificar que muchas veces no
todas las características pueden igualmente afectarlos aspectos importantes de calidad.
Además se propone una tercera dimensión que muestra en la fase en la cula esoso aspectos
de calidad son probados. Esta tercera dimensión es útil para describir cuando son realizados
los casos de pruebas y para tener una visión general de que aspectos son mas críticos en cada
etapa.
Los aspectos de mayor detalle de esta metodología son explicados en el artículo señalado.

26
3. Marco práctico

Una segunda parte de la investigación realizada consistió en estudiar, de forma practica, un

conjunto de herramientas para conocer el funcionamiento de métodos automatizados de
testing. Primeramente, resulta clave comprender, ¿Hasta que punto conviene la utilización de
automatización en el testing, y mas aun, en el web testing?

3.1. Testing automatizado

El testing automatizado consiste en la aplicación de herramientas que, tras una configuración

debida, permite la recolección de información desde un sitio web desde una serie de puntos de
vista.
Naturalmente que la aplicación de estas herramientas puede ser cooperativa o independiente.
La forma cooperativa consiste en la utilización de diversas herramientas para fines específicos,
en este caso, se requiere de una herramienta que genere un batch de ejecución para obtener
resultados consistentes. Se puede entender esta utilización como vertical.
Una estrategia horizontal consiste en la utilización de herramientas con el objeto de confirmar
resultados prácticos, es decir, comparar todas las herramientas respecto a una misma prueba y
decidir una resultado a partir de estos datos.

3.1.1. Ventajas y desventajas

Una desventaja natural [RYD01] recae en el hecho que al tratarse de un programa o aplicación,
esta es susceptible de poseer errores, por esta razón, se debe estar continuamente revisando
una historia de errores o bugs. Resulta irónico pensar que una herramienta de testing posee
errores!
Sin embargo, la gran ventaja recae en poder efectuar una mayor cantidad de pruebas en un
menor periodo de tiempo que efectuarlas en forma manual (este ultimo hecho puede resultar
impracticable en algunos sitios con cientos de miles de líneas de código HTML). Algunas
herramientas de hecho permiten generar casos de prueba flexibles que vayan variando con el
objeto de probar parámetros de cambio.
Aun teniendo las mejores herramientas, siempre existirá parte de las pruebas que se deberán
efectuar en forma manual. Una prueba de aceptación de usuario es directa, aun cuando podría
utilizarse alguna herramienta que lo guié en las pruebas, mas no en su automatización.

Una consideración adicional, y no en si una desventaja, es que no se puede pensar que las
herramientas automatizaran todo el proceso de prueba. Siempre deberá existir una
dependencia de los requerimientos que definirán, posteriormente, los casos de pruebas
aplicables por el cliente.

27
Quizás la consideración mas importante es que no se puede confiar en plenitud de las
herramientas de testing, esto, no porque la herramienta no arroje errores quiere decir que el
sitio no los posea.

3.1.2. Tipos de herramientas

Las herramientas analizadas se pueden clasificar en 7 categorías, según el tipo de función que
efectúan en el proceso de testing.

· Validadores de código: Basados explícitamente en verificar la consistencia del código

HTML o script implementados o generados automáticamente.
· Verificadores de componentes: Consistentes en probar la funcionalidad y consistencia
de componentes incrustables en una pagina web (applets de java, componentes de
video, entre otros).
· Verificadores de enlaces: Estas herramientas buscan referencias (no necesariamente
de HTML) hacia documentos o componentes. Se puede considerar como dentro de la
validación de código HTML.
· Probadores de desempeño. Analizan el tiempo de descarga y los tiempos de
funcionamiento generales de un sitio web.
· Analizadores de log. Los cuales estudias cuantitativamente la actividad llevada a cabo
en el servidor web con el objeto de sugerir configuración que atiendan los
requerimientos de carga reales.
· Técnicas funcionales y de regresión. Se trata de herramientas que pruebas en modo de
caja negra la funcionalidad el sitio web. Deben poseer una capacidad alta de
configuración.

3.2. Utilización de herramientas en un caso practico

Una macro-clasificación propuesta por la experiencia llevada a cabo, hace suponer dos tipos
de herramientas:

· Plug-ins en herramientas de desarrollo, las cuales permiten probar el código

desarrollado hasta cierta parte del proceso.
· Herramientas post-desarrollo, las cuales toman el producto terminado y le aplican
pruebas predefinidas.

Para cada una de estas opciones, se estudiaron dos casos para un mismo sitio, La Tercera de
Chile (http://www.tercera.cl).

28
3.2.1. Herramientas plug-in

3
La herramienta utilizada fue Macromedia Dreamweaver MX , la cual posee extensiones para
efectuar ciertas pruebas al código implementado.
La interfaz de la herramienta puede ser visualizada en la Figura X, se puede apreciar el informe
del archivo HTML analizado, la línea del error y una descripción básica de este.
Esta herramienta encontró en total un serie de 140 errores basados únicamente en detalles de
código, y 10 errores de compatibilidad.
Aun cuando la herramienta es bastante rápida en efectuar las pruebas, esta se dedica
únicamente a resolver testing de scripting y de compatibilidad de browsers, dejando fuera otras
técnicas más complejas.

Figura 5. Testing en Macromedia Dreamweaver MX.

3.2.2. Herramientas post-desarrollo

Entre las herramientas estáticas estudiadas, una que arrojo excelentes resultados fue
DoctorHTML, en su versión online. La ventaja en la utilización de esta versión es el poder
efectuar pruebas desde el navegador (sitio oficial del proveedor de la herramienta) hacia un
sitio completo con un alto grado de confiabilidad.
Al aplicar las pruebas sobre el mismo sitio mencionado (La Tercera de Chile), se obtuvieron
resultados de alta calidad y variedad.

3
Esta herramienta se utiliza preferentemente para la creación de paginas web con colores para código javascript,
VBScript y otros.

29
Una primera prueba tuvo relación con el código HTML generado (scripting testing), el cual
arrojo un total de 156 errores (mas que los detectados por Macromedia Dreamweaver).
Otras pruebas desarrolladas fueron: testing de idioma, encontrando una serie de palabras no
reconocidas o mal escritas, testing de compatibilidad, detectando una serie de
incompatibilidades con los browsers Netscape Navigator versión 2.1, y testing de ambiente
operativo, detectando inconsistencias con plataformas MacOS.
Algunas pruebas interesantes son relacionadas a las pruebas de desempeño, arrojando un
tiempo de carga total de 4,3 [seg], desglosado por componentes (imágenes, applets de java por
ejemplo).

En suma, se puedo constatar que el uso de herramientas post-desarrollo permite la obtención

de errores en forma más fiel y detallada, siendo posible aplicar verificaciones más rápidas e
intuitivas.
La Figura 6 muestra la interfaz de funcionamiento de DoctorHTML.

30
Figura 6. Interfaz WEB para DoctorHTML.

31
4. Conclusiones

Tras los fundamentos expuestos en el transcurso de este documento, surgen las siguientes
conclusiones y comentarios:

· Las diferencias entre el Web testing y el testing de aplicación convencional surge

primitivamente de la forma de desarrollar aplicaciones en estas filosofías. Las
diferencias expuestas agregan a una aplicación Web un conjunto de nuevos factores
(latencia, seguridad, alta concurrencia, entre otros) que deben ser probados para
asegurar un funcionamiento óptimo.

· En esta misma línea, estos nuevos factores agregan un efecto combinatorial que no
puede ser estudiado en forma separada. Esto es, un caso de prueba (ingresar a un
sistema de correo por ejemplo) debe ser ejecutado considerando la influencia del
entorno (hora de ingreso, navegador, sistema de validación, entre otros). Este hecho
muestra la fuerte dependencia que existe entre las acciones llevada a cabo por los
usuarios y el entorno de ejecución.

· Un browser se puede entender como un contenedor donde las paginas son

desplegadas mas que una interfaz de per-se. Aun así, la forma de manipular la
información en el browser hace suponer la presencia de dos niveles de interfaz que
deben ser probados por técnicas: pruebas de aceptación visual (para el caso probar el
sitio propiamente tal), y pruebas de usabilidad que, además de probar el uso del sitio,
verifiquen un uso cómodo del navegador.

· Surgen nuevos factores de calidad que son sumados a los existentes (asociados a las
aplicación convencionales). Latencia, tiempo de respuesta y petición, y desempeño de
descarga resultan habituales para juzgar la calidad de un sitio Web.

· La mantención de una aplicación web es altamente dinámica, permitiendo afirmar que

cuesta distinguir el concepto de release, hablando más de un idea de deploy. Con esto
en mente, en esta fase se puede aplicar el conjunto de pruebas mencionadas en el
presente documento.

32
· El modelo V muestra en forma cómoda el carácter temporal inverso aplicado al testing.
Esto es, los primeros casos de prueba (deducibles desde los requerimientos) son los
últimos en ser ejecutados. Esto, por otra parte, permite clasificar los tipos de testing
según la etapa o fase del proceso en la que debe (o puede) ser aplicado. Se ha
presentado una matriz que resume este estudio.

· Desde un punto de vista práctico, es posible encontrar una serie de herramientas para
automatizar el proceso de Web testing (y de testing en general). Aun cuando este
hecho de practico para algunas pruebas, la vasta cantidad de herramientas obliga a
generar una clasificación, encontrando herramientas para la validación de scripts
(HTML, asp, entre otros), hasta un correcto despliegue visual (contenido, imágenes,
texto).

· Una conclusión final se puede resumir en el hecho de que el Web testing no es en

extremo diferente que el testing convencional (según el concepto de necesitar
identificar inconsistencias para después repararlas). La diferencia radica en la inclusión
de nuevos factores de calidad, nuevas formas de interacción entre el usuario y el
sistema y, por ende, la suma de nuevas técnicas de prueba, traducidas en el
ofrecimiento de herramientas particulares de testing.

33
5. Referencias

[MUR01] San Murugesan, Yogesh Deshpande, Steve Hansen and Athula Ginige.
"Web Engineering: A New Discipline for Development of Web-Based Systems".
S. Murugesan and Y. Deshpande (Eds.): WebEngineering 2000, LNCS 2016, pp.3-13, 2001
http://www-itec.uni-klu.ac.at/~harald/proseminar/web11

[OFF02] Jeff Offutt. "Quality Attributes of Web Software Applications".

IEEE Software: Special Issue on Software Engineering of Internet Software,
pp: 25-32, March/April 2002.
http://www.ise.gmu.edu/~ofut/rsrch/papers/swe-websoftware.pdf

[MCD01] Andrew McDonald y Ray Welland, “Web Engineering in Practice”

Department of Computing Science, 2001
http://www.dcs.gla.ac.uk/~andrew/webe2001.pdf

[WTP00] The Web Testing Process, Chapter 1

http://www.wileyeurope.com/cda/cover/0,,0471414352%7Cexcerpt,00.pdf.

[PRES97] Ingeniería del software, un enfoque práctico

Roger S. Pressman
McGraw – Hill, 4º edición 1998

[MAC00] Andrea MacIntosh, Wolfang Strigel, “The Living Creature”

Testing Web Applications

[STO01] Diane Stottlemyer, “Automated Web Testin Toolkit: Expert methods for testing and
managing Web Aplications”
http://www.wileveurope.com

[RAM99] Rudolf Ramler, Edgar Weippl, Mario Winterer, Wieland Schwinger y Josef
Almann.
“A Quality - Driven Approach to Web Testing”
Software Competence Center Hagenberg 1999

34
[OLS99] Luis Antonio OLSINA
“Metodología Cuantitativa para la Evaluación y Comparación de la Calidad de Sitios Web”
La Plata, Noviembre de 1999
Facultad de Ciencias Exactas, Universidad Nacional de La Plata - Argentina
http://di002.edv.uniovi.es/~cueva/investigacion/tesis/WebsiteQEM.pdf.

[GLA00] Robert L. Glass

“Has Web Development Changed the Meaning of Testing?”
http://www.stickymind.com
December, 2000

[NGU00] Hung Nguyen

“Testing Web-Based Applications”
Testing & Quality
May/Jun 2000

[RYD01] Jesper Ryden

“Web Application Testing, A Methodoly with Tools and Considerations”
Pär Svensson
2001

[DIB99] Rhonda Dibachi

“Testing E-Commerce”
Software Testing And Quality Engineering
March/April 1999

[AQA02] AQA Focus Document

“Use of Automated Tools for Testing Web Sites Accesibility”
Oct, 2002

[HOR96] James Horn

“General Concepts about Usability Testing”
1996
http://www.sidar.org/visitable/Test/gcusa-test.htm

35