IntroducciónBloque 1Bloque 2Bloque 3Bloque 4Bloque 5Bloque 6Bloque 7

IntroducciónBloque 1Bloque 2Bloque 3Bloque 4Bloque 5Bloque 6Bloque 7Referencias

Testing de desarrollos web

Introducción
Actualmente, muchos de los sistemas con los cuales interactúa el hombre a diario son sistemas interconectados que ofrecen un
complejo arreglo de contenido y funcionalidad, y que permiten ser accedidos desde cualquier terminal con conexión a internet.

Por las nuevas tecnologías de desarrollo, la mayoría de los sistemas utilizan ingeniería web y son desarrollados con lenguajes que
soportan la implementación web.

Luego de haber expuesto los conceptos fundamentales sobre las pruebas de sistemas, surge la siguiente inquietud: ¿se está en
condiciones de probar sistemas web? ​

Los siguientes interrogantes son los que pueden venir a la cabeza de cualquier probador a la hora de enfrentarse a un proyecto de
prueba de un sistema con tecnología web.

¿Qué significa probar una aplicación web?

¿Qué es necesario conocer?
¿Qué características de los sistemas web toman relevancia al momento de las pruebas?
¿Es un nivel de pruebas?
¿Requiere otro proceso de pruebas? ¿Se considera una técnica?

Estos y otros más son los interrogantes que se intentará responder dentro de esta unidad.

1. Diferencias entre aplicación convencional y aplicación web

Una aplicación convencional tiene estas características fundamentales que la diferencian de una aplicación web:

Se instala
Necesita bibliotecas especiales
Es estática

Por el contrario, una aplicación web, como tal, tiene las siguientes características distintivas:

Es desplegable en browsers
Presenta un conjunto de objetos que se visualizan y operan en forma independiente
Es dinámica

Y en cuanto a los aspectos específicos, se pueden citar:

Multiplicidad de perfiles de usuarios.

Diferentes comportamientos de esos perfiles.
Atributos de calidad que responden a necesidades de diferentes audiencias.
Diferentes tipos de habilidades y conocimientos del equipo de proyecto.
Procesos de desarrollo de rápida generación.
Alto nivel de orientación a la funcionalidad del sistema.

(Uninotas, 2017, https://bit.ly/2PmQswL)

Por todo ello, la ingeniería web requiere enfoques sistemáticos y disciplinarios para construir y evaluar aplicaciones web, y emplea
herramientas y metodologías robustas pero flexibles.

La ingeniería web se desarrolla en un ambiente multidisciplinario, e involucra áreas como:

Ingeniería de Sistemas e Ingeniería de Software

Interfaces usuarias
Multimedia
Modelado
Simulación
Prueba
Gestión de Proyectos
Sociología
Diseño Gráfico.

(Uninotas, 2017, https://bit.ly/2PmQswL)

Dimensiones de calidad para pruebas de aplicaciones web

“Tal como lo expresa Pressman (2006) la calidad que se incorpora en una aplicación web depende del diseño” (Uninotas, 2017,
https://bit.ly/2PmQswL). El mismo se debe evaluar aplicando revisiones técnicas que valoran varios elementos del diseño y también
aplicando pruebas.

En ambos casos se deben examinar ciertas dimensiones de calidad inherentes al desarrollo web. Entre las que se
pueden destacar, están:

Navegabilidad: vínculos rotos, inadecuados o erróneos.

Interoperabilidad: que realiza interfaces adecuadas con otras aplicaciones o bases de datos.
Seguridad: valorar el nivel de vulnerabilidad.
 Facilidad de uso: para cada perfil de usuario involucrado.
Contenido: tanto en semántica (consistencia, ambigüedades, exactitud de la información presentada) como en
sintáctica (ortografía, puntuación, gramática).
Estructura: que entrega adecuadamente contenido y función, y que puede ser extensible.

(Uninotas, 2017, https://bit.ly/2PmQswL)

Considerando estas dimensiones de calidad, la búsqueda de errores representa un desafío significativo para los probadores, en
adelante, probadores web.

2. Proceso de desarrollo web

En el desarrollo de sistemas con tecnología web, el proceso mismo de desarrollo muestra algunas diferencias generales, entre las
que se puede mencionar:

Requerimientos livianos: no hay una especificación de requerimientos detallada, sino que está restringida a la
reducida tecnología de un browser.
El desarrollo es simple y rápido.
Por ello es que los proyectos se caracterizan por ser cortos.
Las pruebas son poco minuciosas, dinámicas, altamente orientadas al contenido y a la visualización.

(Uninotas, 2017, https://bit.ly/2PmQswL)

Comparativamente, en las fases de desarrollo se presenta de manera resumida el siguiente cuadro:

Tabla 1: Proceso de desarrollo web

Desarrollo de Desarrollo de
aplicación aplicación Web
convencional
Basado en detalladas Más liviano, menos
Requerimientos especificaciones estricto, se basa en
notas, ideas, entre otros
Planificación Experiencia Disponibilidad de
tiempo
Análisis y Procesos separados En paralelo
diseño
Implementación Desarrollo secuencial de Transiciones iterativas a
componentes sitios web
Integración Ensamblado de Web services
componentes
Pruebas Se prueba la Se basa además sobre
funcionalidad contra las la funcionalidad
especificaciones deseada
Instalación y Transferencia a un Transferencia a un web
entrega instalable server
Mantenimiento De 1 a 3 años De 4 a 6 meses
Fuente: elaboración propia.

Elementos diferenciales del desarrollo web

Con todo lo ya expuesto, a continuación, se muestra un gráfico con las diferencias sustanciales de la ingeniería web en cuanto a
proceso, calidad, usuarios y equipo de proyecto.

Figura 1: Diferencias sustanciales de ingeniería web

Fuente: elaboración propia.

3. El desafío de las pruebas

“Pasando puntualmente a las pruebas, se presentan una serie de dificultades a la hora de detectar un error durante las pruebas de
aplicaciones web” (Uninotas, 2017, https://bit.ly/2PmQswL).

En muchas ocasiones, por ejemplo, con una inconsistencia en el browser, se está viendo el síntoma y no el error en sí.

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’

¿Dónde está el problema? ¿En el cliente o en el servidor?

A simple vista parece un error del sistema, pero es una mala configuración de JavaScript que no permite la visualización de un
objeto ActiveX en el browser.

Es muy difícil independizar un error del entorno

Una prueba con una conexión por modem de 56K, resulta muy diferente, o de resultados diferentes a una
prueba con conexión dedicada. Como una aplicación web es implementada en varias configuraciones y ambientes
distintos, puede ser muy difícil y hasta imposible reproducir un error fuera del ambiente en el que se lo encontró.
¿Cómo saber si un error determinado es un error de programación o de configuración?
El rastreo de un error puede ser difícil a través de las tres capas de arquitectura: cliente, servidor, red.
El ambiente desempeña un papel importante en el diagnóstico de los errores que se descubran durante las
pruebas o más allá de las pruebas, de las aplicaciones web. (Uninotas, 2017, https://bit.ly/2PmQswL)

Todas estas dificultades hacen de la prueba una actividad no trivial, que requiere adecuación de las técnicas tradicionales y de otras
técnicas también.

4. Clasificación de los sitios web

Al clasificar el sitio, se pueden determinar en parte qué pruebas realizar.

Estáticos: es el tipo más simple de sitio, donde la única opción de la página es hacer clic.
Estáticos con formularios: son usados para recopilar información de usuarios, orientados a recolección de datos
con acceso dinámico de datos: front-end de datos, almacenados en un repositorio externo. Los resultados son
archivos HTML generados por algún motor específico.
Dinámicamente generado: la interfaz gráfica y cada una de las páginas retornadas por el servidor son generadas
dinámicamente. No retorna un archivo, sino un flujo de código.
Aplicaciones web: conjunto de funcionalidades y componentes que usan ambientes web.

​(Uninotas, 2017, https://bit.ly/2PmQswL)

Si bien el desarrollo de los contenidos de esta unidad está dentro del último tipo de sitios (aplicaciones web), varios aspectos
característicos son compartidos por otros tipos de sitios y también aplican para la prueba de páginas web del tipo estáticos o
estáticos con formulario.

5. Estrategia de pruebas web

Pressman (2006) propone una estrategia de prueba de varios pasos que se basa en los principios básicos de cualquier prueba de
sistemas y aplica técnicas tradicionales de pruebas, además de adaptar ciertos tipos de pruebas con sus técnicas asociadas en
función de las dimensiones de calidad para evaluar.

A los pasos del enfoque de Pressman (2006) se los puede agrupar en un grupo de revisiones (pruebas estáticas), otro de pruebas
dinámicas y el tercero de pruebas con usuarios reales:

1) Revisiones de determinados modelos o diseños para encontrar errores:

Modelo de contenido. Es el bosquejo o estructura de todo el contenido que se presenta.

Modelo de interfaz. Detalla la estructura y organización de la interfaz del usuario.
Diseño de navegación. Muestra el flujo de navegación entre los objetos de contenido para todas las funciones.

2) Pruebas de:

Revisión del modelo de diseño de la WebApp en busca de errores de navegación.

Se prueba la interfaz de usuario para descubrir errores en la presentación o los mecanismos de navegación.
Componentes funcionales seleccionados se prueban en forma individual.
Se prueba la navegación a través de toda la arquitectura.
La WebApp se implementa en diversas configuraciones ambientales y se prueba su compatibilidad con cada
configuración.
Se realizan pruebas de seguridad con el objetivo de explotar vulnerabilidades en la WebApp o dentro de su
ambiente.
Se llevan a cabo pruebas de desempeño.
Se prueba la WebApp en una población controlada y monitoreada de usuarios finales buscando errores
relacionados con la facilidad de uso, la compatibilidad, confiabilidad y desempeño en de la WebApp. (Aillón, 2011,
https://bit.ly/2SvfQ5i

Pruebas de seguridad y accesibilidad

Existen tres dominios que pueden recibir ataques: del lado del cliente, en el ambiente del servidor y en las comunicaciones de red
entre el ambiente del cliente y del servidor.
Dentro del lado del cliente, una vulnerabilidad es el acceso no autorizado a cookies [1] colocadas dentro del navegador, y con esa
información poner en juego la privacidad del usuario. Del lado del servidor, una vulnerabilidad puede ser el ataque de negación del
servicio o acceso sin autorización a bases de datos. En lo que se refiere a las comunicaciones de red, la vulnerabilidad más
destacada es el spoofing [2] .

Las pruebas de seguridad apuntan a probar vulnerabilidades en estos tres dominios. La prueba de seguridad es la de mayor
importancia.

Las condiciones de seguridad a cubrir son, por un lado, la privacidad de usuario a través de algoritmos de encriptación y, por otro, la
estabilidad del servicio, usando sistemas de respaldo y redundancia de información.

​Puntos comprendidos por la seguridad:

☰ Integridad
La información debe ser correcta independientemente de los errores o las inconsistencias externas. Por lo que la información debe
estar protegida de una posible destrucción o modificación accidental o intencional.
☰ Autenticación
Se debe validar que quien hace las acciones sea quien dice ser al momento del ingreso al sistema y de todo el proceso que el
usuario realice. La seguridad de la red comprende tanto la protección física de los dispositivos como también la integridad,
confidencialidad y autenticidad de las transmisiones de datos que circulen por ésta.

​La siguiente lista resume los puntos que comprende la seguridad de una red:

​La información debe estar protegida de una posible destrucción o modificación accidental o intencional
(integridad).
Los datos no deben estar disponibles a los accesos no autorizados (privacidad).
Las transacciones no deben ser modificadas en su trayecto y se debe asegurar que quien las generó es quien dice
ser (integridad, autenticidad y no repudio).
Se debe mantener la integridad física de los dispositivos de red como servidores, switches, etc.
El uso de la red no debe ser con fines que no estén contemplados por las políticas de utilización.
La red debe estar disponible siempre y con la eficiencia necesaria, aún ante fallos inesperados (disponibilidad).
(Gómez Fernández, 2008, https://bit.ly/2Poiact)

Entre las técnicas que incorporan las pruebas de seguridad están:

Análisis de vulnerabilidades: examina la robustez respecto de la seguridad de cada uno de los sistemas y dispositivos ante
ataques. Es decir que incluye tanto los sistemas como la parte física también.
Pruebas de penetración: se hacen las pruebas mediante la simulación de los mecanismos habituales de atacantes.
Pruebas de accesibilidad: son las pruebas que se realizan midiendo la facilidad del acceso y la navegación en cualquier
condición.
Pruebas de servicios web: son las pruebas sobre mecanismos de seguridad del servicio web (autorización de path virtuales,
listado de archivos de directorio, acceso a script asp, php).
Pruebas de validación de algoritmos: se verifican los pasos empleados en la generación de claves públicas y firmas
electrónicas (algoritmos RSA [Rivest, Shamir y Adleman], DES [Data Encryption Standard]).

Análisis de vulnerabilidades

Es el proceso de evaluar la seguridad de los sistemas, los cuales son analizados exhaustivamente con el fin de encontrar fallos de
seguridad, tanto en el diseño como en la implementación de la aplicación.

Es una técnica que le permite a un analista en seguridad examinar la robustez y seguridad de cada uno de los sistemas y
dispositivos ante ataques y, a partir de allí, obtener la información necesaria para analizar cuáles son las contramedidas que se
pueden aplicar con el fin de minimizar el impacto de un ataque. (Gómez Fernández, 2008, https://bit.ly/2Poiact)

¿Cuándo debe realizarse el análisis de vulnerabilidades?

Toda vez que se produzcan cambios en el diseño o que se realicen actualizaciones de dispositivos de red, pero, aunque estas
situaciones no se den, el análisis de vulnerabilidades debe ser algo que se debe ejercitar periódicamente.

Las vulnerabilidades provienen de diferentes ámbitos y se pueden clasificar en vulnerabilidades de implementación, configuración,
dispositivo, protocolo, aplicación.

Retomando los enfoques de caja negra y caja blanca vistos para la prueba de sistemas tradicionales, estos pueden presentarse en
las pruebas de aplicaciones web.

El análisis de vulnerabilidades puede ser realizado con el enfoque de caja negra. Dentro de este enfoque, al analista se le
proporciona sólo la información de acceso a la red o al sistema (podría ser solo una dirección IP [Internet Protocol] y a partir de esta
información, el analista debe obtener toda la información posible.

Dentro del enfoque de caja blanca, el analista de seguridad tiene una visión total de la red a analizar, así como acceso a
todos los equipos con los más altos permisos de usuario. Este tipo de análisis tiene la ventaja de ser más completo y
exhaustivo. (Gómez Fernández, 2008, https://bit.ly/2Poiact)

​Dentro de las herramientas que se pueden utilizar para realizar un análisis de vulnerabilidades, están:

escaneo de puertos;
detección de vulnerabilidades;
analizador de protocolos;
passwords crackers [3];
 trashing [4].

[1] Las funciones de una cookie son: cuando un usuario introduce su nombre de usuario y contraseña, se almacena una cookie para
que no tenga que estar introduciéndolas para cada página del servidor. Conseguir información sobre los hábitos de navegación del
usuario, e intentos de spyware, por parte de agencias de publicidad y otros.
[2] Simulación: un sitio que simula ser el legítimo servidor con la intención de robar contraseñas e información de propiedad del
usuario.
[3] Utilidades y herramientas para descubrir passwords (contraseñas) de programas, webs, accesos remotos, sistemas operativos.
[4] Dentro de los esfuerzos para romper la seguridad, están el carding, que consiste en el uso (o generación) ilegítimo de las tarjetas
de crédito (o sus números) pertenecientes a otras personas con el fin de obtener los bienes realizando fraude, y el trashing, con el
fin de rastrear en las papeleras en busca de información, contraseñas o directorios.

Pasos para el análisis de vulnerabilidades

☰ 1. Acuerdo de confidencialidad entre las partes

Es de fundamental importancia, ya que a lo largo del desarrollo del análisis se puede obtener información que es crítica para la
organización analizada. Desde el punto de vista de la organización, debe existir confianza absoluta con la parte analizadora.

El acuerdo de confidencialidad ofrece un marco legal sobre el cual trabajar. Es un respaldo formal a la labor.
☰ 2. Establecer las reglas de juego
Antes de comenzar con el análisis, es necesario definir cuáles van a ser las tareas para realizar y cuáles serán los límites, permisos
y obligaciones que se deberán respetar.

Durante el análisis, deben estar informadas la menor cantidad de personas, de manera que la utilización sea normal, evitando
cambios en la forma de trabajo.
☰ 3. Reunión de información
Se debe tener claro el objetivo y se debe informar la técnica.

Si la prueba es de caja negra, el proceso de análisis será muy similar al proceso seguido por un atacante. En cambio, si la prueba
es de caja blanca, se debe recopilar y otorgar la información de acceso a servicios, hosts y dispositivos, información de
direccionamiento, y todo lo que consideres necesario.
☰ 4. Prueba interior
Para esta prueba, se requiere la provisión de una computadora típica, un nombre de usuario y una clave de acceso de un usuario
común. La prueba consiste en tratar de demostrar hasta dónde se puede llegar con los privilegios de un usuario típico dentro de la
organización.

¿Qué pruebas se hacen?:

- Revisión de privacidad;
- Pruebas de detección de intrusos;
- Descifrado de contraseñas;
- Pruebas de denegación de servicios;
- Evaluación de políticas de seguridad.
☰ 5. Test exterior
Consiste en acceder en forma remota a los servidores de la organización y obtener privilegios o permisos que no deberían estar
disponibles.

¿Qué pruebas se hacen?:

- “Sondeo de Red
- Identificación de los Servicios de Sistemas
- Búsqueda y Verificación de Vulnerabilidades”. (Muñoz, 2002, https://bit.ly/2Qfmtwb)
☰ 6. Registración e informe
Como finalización del análisis de vulnerabilidades, se debe presentar un informe donde se detalle cada una de las pruebas
realizadas y los resultados asociados. El informe debe incluir:
- “Una lista de las vulnerabilidades probadas.
- Una lista de las vulnerabilidades detectadas
- Una lista de los servicios y dispositivos vulnerables
- El nivel de riesgo que involucra cada vulnerabilidad encontrada”. (Muñoz, 2002, https://bit.ly/2Qfmtwb)

También como anexo se deben incluir los resultados de los programas utilizados.

Pruebas de penetración

Durante el test de penetración se simula ser un atacante. Desde esta posición, se realizan varios intentos de ataques a la red,
buscando debilidades y vulnerabilidades. Es similar al análisis de vulnerabilidades, pero con simulación de ser un atacante.

¿Cómo se realizan las pruebas de penetración?

Estudio de la red externa

Análisis de servicios disponibles
Estudio de debilidades
Análisis de vulnerabilidades en dispositivos de red
Análisis de vulnerabilidades de implementaciones y configuraciones
Denegación de servicio.
El resultado del test de penetración mostrará una idea general del estado de la seguridad de los sistemas frente a
los ataques (Análisis de vulnerabilidades, metodologías, hacking ético y pruebas de intrusión, s.f.)
Un informe que contenga:

pruebas de seguridad realizadas en las pruebas;

lista de vulnerabilidades y debilidades encontradas;
referencia técnica a estas vulnerabilidades y sus contramedidas;
recomendaciones.

A continuación, se dan una serie de estándares que existen para llevar adelante las pruebas de seguridad. Se desarrollarán
mínimamente, pero a la hora de aplicarlos en la práctica, deberán ser consultados para tomarlos en su versión última.

Metodología OSSTMM (2003): Open Source Security Testing Methodology Manual

Manual de la metodología abierta de pruebas de seguridad
Es un estándar de referencia creado por el ISECOM para llevar adelante las pruebas de seguridad en forma ordenada y
de calidad profesional. (Torre García, 2014, https://bit.ly/2rnP8jy)

Dimensiones de seguridad alcanzadas por la metodología:

seguridad de la información;
seguridad de los procesos;
seguridad en las tecnologías de internet;
seguridad en las comunicaciones;
seguridad inalámbrica;
seguridad física.

Metodología ISSAF: Information System Security Assessment

Framework

Proyecto del OISSG (Open Information System Security Group, 2005)

Constituye un framework detallado respecto de las prácticas y conceptos relacionados a las tareas para conducir pruebas de
seguridad. Puede involucrar desde Administración de Proyectos de Pruebas de Seguridad, hasta técnicas tan puntuales como la
ejecución de pruebas de Inyección de Código SQL (SQL Injection) o como las Estrategias del Cracking de Contraseñas.

La información está organizada alrededor de lo que se ha dado en llamar “Criterios de Evaluación” que se componen de los
siguientes elementos:​​

Una descripción del criterio de evaluación.

Puntos y Objetivos a cubrir.
Los pre-requisitos para conducir la evaluación.
El proceso mismo de evaluación.
El informe de los resultados esperados.
Las contramedidas y recomendaciones.
Referencias y Documentación Externa.

Metodología OTP: OWASP Project Testing (2011)

El OTP pertenece a la Open Web Application Security Project: organización de voluntarios.
Primera parte:

principios y alcance del testeo;

explicación de las técnicas de testeo;
explicación general acerca del framework de testeo OWASP.

Segunda parte:
Se planifican todas las técnicas necesarias para testear cada paso del ciclo de vida del desarrollo de software.

Pruebas de accesibilidad

Las pruebas de accesibilidad tienen los siguientes aspectos a cubrir y se hacen empleando simuladores:

facilitar el acceso y la navegación en cualquier condición;

intentar mejorar el acceso a la web de los usuarios en general;
también garantizar el acceso a la web de personas con discapacidad en particular.

El Consorcio World Wide Web (W3C) es una comunidad internacional donde las organizaciones Miembro, personal a
tiempo completo y el público en general trabajan conjuntamente para desarrollar estándares Web. Estableció un
estándar técnico recomendado, el WCAG: Web Content Accessibility Guidelines (Sánchez-Heredero Pérez, 2011,
https://bit.ly/2BWk3JX).
​Las normas a cumplir para conseguir la Accesibilidad de un sitio están separadas en tres áreas a las que se les
asigna diferente nivel de Prioridad. Estas son consecutivas y pueden certificarse individualmente:
Prioridad 1:
Los puntos de verificación de esta prioridad tienen que ser satisfechos, porque, de lo contrario, uno o más grupos de
usuarios encontrarán imposible acceder a la información del documento. Satisfacer este punto de verificación es un
requerimiento básico para que algunos grupos puedan usar estos documentos Web.
Prioridad 2:
Los puntos de verificación de esta prioridad deben ser satisfechos, porque, de lo contrario, uno o más grupos tendrán
dificultades en el acceso a la información del documento. Satisfacer este punto de verificación eliminará importantes
barreras de acceso a los documentos Web.
 Prioridad 3:
Los puntos de verificación de esta prioridad pueden ser satisfechos, porque, de lo contrario, uno o más grupos de
usuarios encontrarán alguna dificultad para acceder a la información del documento. Satisfacer este punto de verificación
mejorará la accesibilidad de los documentos Web (Guía para desarrollo de sitios web, s.f. p.57)

6. Ejemplos

Ejemplo de un checklist de seguridad

En este ejemplo se presentan una serie de puntos que deben ser verificados para determinar si el sitio web que se analiza cumple
con las características de seguridad aconsejadas. Se marca sí o no y se espera que el objeto bajo prueba cumpla con todos o la
mayoría de ellos. Es solamente demostrativo de cómo se lo puede construir, no puede ser usado como completo ni con fines
estadísticos.

¿Funciona correctamente y no presenta fallas al navegar por sus páginas o utilizar sus servicios?
¿Todos los vínculos tienen una página asociada y el contenido adecuado al vínculo señalado?
Frente a una búsqueda, ¿los resultados se muestran correctamente?
¿Los servicios ofrecidos son realizados a través de canales de transacción seguros?
¿En los temas que requieren de accesos restringidos, provee algún medio para validar el acceso, solicitando
usuario y clave?
¿Se evita que sea visto, el nombre de los programas y los directorios?
¿Los datos privados, ingresados por los usuarios, son guardados de manera reservada? (Guía digital, s.f.
https://bit.ly/2E5hCpU)

Ejemplo de un checklist de accesibilidad

Se presenta un ejemplo de los puntos que podría contener un checklist de accesibilidad para evaluar si el sitio web que se analiza
cumple con las características de accesibilidad aconsejadas. De la misma manera que el anterior, se marca sí o no y se espera que
el objeto bajo prueba cumpla con ellos. Es solamente demostrativo de cómo se lo puede construir, no puede ser usado como
completo ni con fines estadísticos.

¿La información transmitida a través de los colores también está disponible sin color?
¿El documento está escrito en un lenguaje adecuado?
¿Las páginas que utilizan nuevas tecnologías como los plug-ins de Flash, siguen funcionando cuando dicha
tecnología no está presente?
Para todo elemento no textual como imágenes, ¿se proporciona un texto equivalente para explicar su contenido a
discapacitados visuales?
¿Puede el usuario activar elementos de las páginas, usando cualquier dispositivo como el mouse o el teclado y no
sólo uno en particular?
¿Se ofrecen elementos de navegación claros? (Guía digital, s.f. https://bit.ly/2E5hCpU)

7. Pruebas

Pruebas heurísticas

Las pruebas heurísticas consisten en un análisis hecho por expertos con criterio respecto de las pantallas que se están ofreciendo a
los usuarios. Son complementarias a las pruebas de usabilidad, que son realizadas o bien por usuarios o con orientación a usuarios.

Consistencia y cumplimiento de estándares: la prueba mide si se cumplen los estándares que se usan en la Internet
“Esta evaluación detecta aproximadamente el 42% de los problemas graves de diseño y el 32% de los problemas menores,
dependiendo del número de evaluadores que revisen el sitio” (López Cisternas, 2012, p.16)
Los evaluadores trabajan individualmente.
Se recomienda una recorrida completa al menos 2 veces antes.
Las sesiones duran 1 o 2 horas.
Se confecciona lista de problemas analizados separadamente.
Se realiza una jerarquización de los problemas detectados.

“Los factores que miden la gravedad de los problemas son:

Frecuencia: ¿es común que ocurra o poco frecuente?

Impacto: cuando sucede, ¿es fácil o no superarlo?
Persistencia: ¿es resuelto o se vuelve a presentar?” (Centro de investigación de la comunicación, 2007, p.87)

Jacob Nielsen (1995) estableció diez principios aplicados universalmente respecto de la usabilidad y que se entienden como el
conjunto más adecuado para medir las características de usabilidad de un software, sitio web o portal.

Visibilidad del estado del sistema: la prueba mide si el usuario siempre sabe qué está haciendo el sistema. Se revisa si existen
los diferentes elementos que ayudan a esto:
Indicación gráfica de donde se encuentra (ruta de acceso desde portada)
Indicación de que ha visto (marcar los enlaces visitados)
Indicción de que hay un proceso en marcha (anunciando estado de avance...)
Indicación de cuántos pasos faltan para terminar (como en el caso de que ya a un proceso de registro en el Sitio Web
Similitud entre el sistema y el mundo real: la prueba mide si el sitio se expresa de una manera comprensible para el usuario.
Para ello se revisa si se emplean las convenciones habituales y que le permiten operar en el Sitio Web.
Control y libertad del usuario: la prueba mide si los usuarios que se equivocan al hacer algo tienen forma de recuperarse de
esos errores. Se revisa si existen formas de hacerlo. Por ejemplo: ¿Se puede deshacer una operación? ¿Se puede rehacer
una operación?
en el Sitio Web. Para ello se debe validar y revisar el sitio con las herramientas que se ofrecen en http://www.w3c.org para
HTML y CSS.
 Prevención de errores: la prueba permite validar si se cuenta con mecanismos que aseguren que el ingreso de cualquier
información, por parte del usuario, permite evitarle errores.

Para ello, se verifica si en las áreas en que los usuarios deben interactuar con el sistema, se les explica claramente lo que se
espera de ellos.
Por ejemplo:

Uso de Javascript para validar formularios: para que todos los campos obligatorios sean llenados, para que el número de RUT
sea ingresado correctamente, etc.
Uso de elementos destacados en los formularios: indicar los campos obligatorios con asteriscos (*) o, bien, campos
obligatorios marcados con color.
Preferencia al reconocimiento que a la memorización: la prueba permite revisar si el Sitio Web ayuda al usuario a recordar
cómo se hacía una operación, o bien le obliga a aprenderse los pasos cada vez que ingresa. Para conseguir este objetivo se
verifica la existencia de una línea gráfica uniforme en todo el Sitio Web (mediante la cual el usuario entiende lo que se le
ofrece con sólo mirarlos) y si se cuenta con un sistema de navegación coherente.
Flexibilidad y eficiencia de uso: la prueba permite revisar si se ofrecen soluciones diferentes de acceso a los contenidos, a los
usuarios novatos respecto de los expertos. Por ejemplo, se puede contar con botones para los primeros y atajos de teclado
para el experto. También es importante medir en esta prueba la carga rápida de los sitios mediante una buena construcción
del código.
Estética y diseño minimalista: la prueba pide que los elementos que se ofrezcan en la pantalla tengan una buena razón para
estar presentes. Se verifica la existencia de elementos irrelevantes (texto, sonido e imagen), que no aportan ni ayudan a que
el usuario distinga lo importante de lo superfluo.

Para ello se verifica la existencia de:

Jerarquías visuales: que permiten determinar lo importante con una sola mirada.
Tamaño de imágenes: que no afectan la visión general de la información del Sitio Web; se verifica tanto tamaño como peso.
Ayuda ante errores: se verifica que el usuario sepa cómo enfrentar problemas en una página tanto online como offline; entre
los elementos que se miden se cuentan: - Mensaje 404 personalizado, con el fin de ofrecer una información y navegación
alternativa cuando una página no es encontrada. - Mensaje de falla ofrece una alternativa offline (teléfono, mesa de ayuda)
que permite que el usuario mantenga su confianza en la institución.
Ayuda y documentación: se revisa que el Sitio Web ofrezca ayuda relevante de acuerdo al lugar en que el usuario esté
visitando; también se revisa la existencia de sistemas de búsqueda que permiten al usuario encontrar los elementos de ayuda
que sean relevantes de ofrecer (preguntas frecuentes; páginas de ayuda). (Guía para el desarrollo de sitios web, s.f., p.61-62)

Pruebas de usabillidad

Para Jacob Nielsen (1995) la usabilidad es la propiedad de un sistema según su facilidad en relación a la usabilidad, utilización y
aprendizaje.

Para la ISO 9126 (2001), es la “capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en
condiciones específicas de uso” (Ecured, s.f. https://bit.ly/2QDbBY7).

Y la ISO 9241 (2008) la define como “la eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a
usuarios específicos en un contexto de uso específico” (UTM, s.f. https://bit.ly/2UsfBcW).

​La usabilidad es una amplia disciplina comprometida con los problemas de los usuarios al trabajar con la aplicación y que
considera:

aspectos de diseño;
facilidad de uso;
facilidad de aprendizaje.

Las pruebas de usabilidad, entonces, revisan una serie de factores con el fin de establecer si cumplen con las necesidades de los
usuarios. Son realizadas con usuarios o bien con orientación a usuarios.

Para hacer las pruebas de usabilidad, es necesario conocer:

Funcionalidad mínima requerida: ¿Qué es lo mínimo que necesita saber un usuario para trabajar con el sitio web? Empezar
con un diseño sencillo y luego si es preciso añadir cosas.
Limitaciones del usuario: limitaciones de ancho de banda tipo navegador nuevas interfaces (PDA, WAP, WebTV) pluggins
plataformas.
Preferencias de usuarios.
Hábitos del usuario.
Sistemas existentes: con los que interactúan habitualmente los usuarios de teléfonos, formularios, sistemas mecánicos,
paneles de control.
Lo que no le gusta al usuario: respuesta lenta del servidor, excesivo tiempo con las descargas de gráficos.
Datos personales: edad, nivel de conocimientos de internet, nivel de estudios, sitios que más usan, son clientes actuales o
potenciales del sitio sobre el que vamos a estudiar su usabilidad, dónde viven, cuántos ordenadores tienen en casa. (Cueva,
s.f. p.6)

Herramientas utilizadas

Se pueden emplear una serie de herramientas que permitan conocer aspectos respecto de las preferencias y hábitos de los tipos de
usuarios para llevar adelante las pruebas de usabilidad, pues no es lo mismo probar un sistema para el cobro de jubilaciones en
línea que para la inscripción a exámenes universitarios. El primero está orientado a personas jubiladas y el segundo a estudiantes
universitarios. Existen diferencias de edades, como así también de niveles de estudio y familiaridad con sistemas informáticos.

Las herramientas que se pueden usar para responder a estas preguntas pueden ser (son meramente enunciativas, ya que pueden
emplearse cualquiera que persiga el mismo fin):
1) Card sort: también llamado ordenamiento de tarjetas, apunta a descubrir lo primero que miran los usuarios. Es una técnica para
la clasificación de contenidos de manera que un usuario pueda clasificar la información según su estructura mental, facilitándole la
interacción. Es crear desde el diseño categorías organizadas que se aproximen a la estructura mental del usuario. El proceso puede
ser abierto cuando es totalmente libre, o bien, cerrado cuando las categorías vienen predefinidas.

Tiene las ventajas de ser de fácil realización, de bajo costo y permite a los usuarios involucrarse directamente en el diseño. La
ventaja es que se pueden obtener resultados muy disímiles. En esos casos la solución es combinar esta técnica con otras técnicas
de usabilidad.

Los pasos que se siguen en esta técnica son:

Se crean las tarjetas en un número controlado y con nombres cortos.

Se seleccionan los participantes entre los usuarios reales.
En la sesión de card sorting, se brindan los objetivos de manera clara. A veces, es necesario un ensayo.
Se analizan los resultados agrupándolos según sean cualitativos o cuantitativos.

2) Entrevistas con los usuarios: diálogos con los usuarios sobre el sitio web.
3) Cuestionarios.
4) Test clásico.
5) Evaluación heurística: realizada por expertos a partir de estándares.
6) Prototipado.
7) Estudio de campo.
8) Sesión automatizada: se realiza con navegador automático.
9) Pensamientos en voz baja: captura en momentos de confusión.
Tipos de pruebas de usabilidad

Las pruebas de usabilidad deben realizarse a lo largo de todo el ciclo de vida de desarrollo. En etapas tempranas, consiste en una
prueba de una versión previa o también puede ser una prueba sobre un competidor, ya que va a agregarle valor al diseño. En
etapas intermedias, valida el diseño y aporta posibilidades de refinamiento del diseño. Y en etapas posteriores, asegura que el
producto alcanza los objetivos de diseño (Hom, 1996).

Consisten en:

Pruebas de aceptación visual: implica revisar la integración gráfica, probar que entre las páginas del sitio exista consistencia
visual y gráfica. Las pruebas deben ser realizadas en distintos entornos como: distintas frecuencias de refresco, resolución de
colores y de pantalla, entre otros. (Ciolli, 2007, https://bit.ly/2L3h85h)
Pruebas de idioma: resulta 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. (Ciolli, 2007, https://bit.ly/2L3h85h)
Pruebas de contenidos: es una prueba básica para revisar si el desarrollo incluye todos los contenidos que se han
especificado.

Los elementos para considerar en las pruebas de contenidos son:

“Verificación de ortografía y redacción

Verificación de enlaces principales
Verificación de imágenes y gráficos
Verificación de existencia de archivos adjuntos” (Guía digital, s.f. https://bit.ly/2zLZqhU)

Clasificación de las técnicas: sondeo, inspección y auxiliares

Dentro de las técnicas y herramientas utilizadas en las fases de desarrollo para construir la usabilidad de un producto, se puede dar
una innumerable lista. Algunas ya han sido nombradas y descriptas, y todas contribuyen a la calidad de la usabilidad, ya sea al
momento del diseño, de la construcción o de las pruebas.

Se presenta una clasificación que permite ordenar esta lista, pero lejos está de quedar cerrada, ya que cada organización
desarrolladora de aplicaciones web y tradicionales también (que requieran una cuidada interfaz de usuario) puede crear y diseñar
sus propias técnicas para los puntos que le hagan falta afrontar.

Se las agrupa en tres categorías, a saber:

1) Técnicas de sondeo:
Son las que tienen el objetivo de averiguar lo correcto en el momento correcto.

Encuestas de Contexto
Estudio Etnográfico u Observación de campo: consiste en la observación de la forma de operar de los usuarios con el sistema
bajo análisis, pero en su propio entorno de trabajo, no en laboratorio.
Entrevistas a Grupos Objetivo o focus group: son entrevistas a grupos completos de usuarios, formalmente programadas y
organizadas, a los que:
Se plantean cuestiones sobre aspectos concretos que preocupan.
Se fomenta el intercambio de ideas y la discusión.
Se extraen conclusiones. (Hom, s.f., https://bit.ly/2RFi5mH)

Se pueden aplicar en cualquier momento del proyecto, pero al final del desarrollo se aplican para evaluar el nivel de satisfacción del
grupo de usuarios.

Encuestas personales o cuestionarios: Son entrevistas a usuarios que responden a un cuestionario de preguntas establecidas,
pudiendo comentar las respuestas y recogiendo tanto los comentarios del usuario como la manera en que éste se expresa al
respecto, y también lo que no expresa. (Hom, s.f., https://bit.ly/2RFi5mH)
Si bien son parecidas a las encuestas de contexto y cuestionarios, las diferencias con los primeros es que no están estructuradas y
con los segundos es que son interactivas.

Sesiones capturadas o logs auto-reportados: Son pruebas que se realizan a distancia, grabando las acciones que realizan
durante su operativa sobre una maqueta del web bajo análisis. Para el caso de los logs auto-reportados los usuarios describen
en formularios en papel específicamente diseñados la secuencia de acciones llevadas a cabo para realizar cada una de las
tareas a analizar. Tienen la ventaja que permiten expresar al usuario consideraciones subjetivas sobre su experiencia personal
al realizar cada acción. (Hom, s.f., https://bit.ly/2RFi5mH)

2) Técnicas de inspección

Evaluación heurística que mantiene los mismos principios ya explicados.

Ensayo cognitivo: hace referencia a elaborar escenarios de tareas para realizar a partir de las especificaciones de una
maqueta y tomando el rol de un usuario que simula realizar dichas tareas recorriendo el interfaz de usuario propuesto.
Mientras se hace cada tarea, se recoge paso a paso lo que un usuario haría. Aquellos pasos en los que el usuario se bloquea
y no consigue terminar una tarea se registran, ya que son puntos que marcan que es necesario que se revise la interfaz para
que simplifique la ejecución de la tarea.
Inspecciones formales de usabilidad: llevadas a cabo como cualquier inspección dentro de las pruebas estáticas.
​Inspección de características, de consistencia, de estándares y de todo lo que se quiera evaluar: llevadas a cabo como
cualquier inspección dentro de las pruebas estáticas.
Guías de consulta y checklist de usabilidad: las guías de consultas describen aquellos principios para tener en cuenta en el
diseño y desarrollo de una aplicación web o sitio web para garantizar su usabilidad.

3) Técnicas auxiliares

Prototipado: existen varios tipos de prototipado:

Prototipado rápido.
Prototipado o evolutivo: se utiliza un gran esfuerzo durante la implementación de la maqueta inicial de manera que
posteriormente sea fácilmente transformada en el producto final.
Prototipado modular (o incremental): se añaden partes a la maqueta según el ciclo de desarrollo avanza.
Prototipado horizontal: la maqueta cubre múltiples funcionalidades, pero solo alguna de ellas está operativa para las
pruebas. Permite una visión completa.
Prototipado vertical: la maqueta cubre muy pocas funcionalidades, pero funcionan y se pueden probar.
Prototipado de baja fidelidad: la maqueta se diseña con lápiz y papel con explicaciones. Es rápido y barato. Sería un
croquis en lo que es un proyecto de una casa.
Prototipado de alta fidelidad: se diseña la maqueta lo más parecida al producto final.
Diagramas de afinidad: es un método de categorización en el que los usuarios clasifican varios conceptos en categorías. Se
utiliza cuando se tienen que organizar un gran número de conceptos según las relaciones naturales entre ellos.
Votación ciega.
Card Sorting, también ya explicado.

Referencias
Aillón, P. (2011). Pruebas de aplicaciones web. Recuperado de: https://es.slideshare.net/paulinaaillon/pruebas-de-aplicaciones-
web-8452773

Ciolli, M. E. (2007). Testing de migración de aplicaciones distribuidas a entornos Web. Recuperado de:
http://sedici.unlp.edu.ar/bitstream/handle/10915/4148/Documento_completo.%20Elena.pdf?sequence=1

Ecured (s.f.) Usabilidad. Recuperado de: https://www.ecured.cu/Usabilidad

Guía digital (s.f.) Checklist de Seguridad para Sitios Web. Recuperado de: http://www.guiadigital.gob.cl/articulo/seguridad.html

Guía para desarrollo de sitios web – Gobierno de Chile. Diseño web y estándares. Recuperado de:
http://www.guiadigital.gob.cl/guiaweb_old/guia/archivos/Capitulo_III.pdf

Gómez Fernández, E. (2008). Seguridad y comercio electrónico. Recuperado de:

https://www.iit.comillas.edu/pfc/resumenes/48c93b4367829.pdf

Hom, J. (1996). Conceptos Generales acerca del Test de Usabilidad. Recuperado de:
https://www.sidar.org/recur/desdi/traduc/es/visitable/test/gcusa_test.htm

International Organization for Standardization. (2001). Software engineering -Product quality - Part 1: Quality model (ISO/IEC
9126-1). Recuperada de https://www.iso.org/standard/22749.html

International Organization for Standardization. (2008). Ergonomics of human-system interaction - Part 151: Guidance on World
Wide Web user interfaces (ISO/IEC 9241-151).

López Cisternas, M. (2012). Métodos de evaluación de usabilidad para aplicaciones web transaccionales. Recuperado de:
http://opac.pucv.cl/pucv_txt/txt-3000/UCF3276_01.pdf

Muñoz Razo, C. (2002). Auditoria en sistemas computacionales. Recuperado de_

https://cdryst.files.wordpress.com/2009/10/aussist.pdf

Nielsen, J. (1995). 10 Usability Heuristics for User Interface Design. New York, NY: Prentice Hall.

Nielsen, J. (1995). 10 Usability Heuristics for User Interface Design. Recuperado de http://www.nngroup.com/articles/tenusability-
heuristics/

Open Information System Security Group. (2005). Information Systems Security Assessment Framework. Recuperado de
http://www.oissg.org/issaf

Open Web Application Security Project. (2011). Metodología OWASP Testing Guide v4. Recuperado de
https://www.owasp.org/index.php/Category:OWASP_Testing_Project

Pressman, R. (2006). Ingeniería de Software. Un enfoque práctico (6.ta ed.). México: McGraw-Hill.

Sánchez Heredero Pérez, A. (2011). Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5. Recuperado de:
https://e-
archivo.uc3m.es/bitstream/handle/10016/13193/PFCAlbertoSanchezHerederoPerezJulio2011.pdf;jsessionid=96BD7A6DEC220711D7
sequence=1

Torre García, S. (2014). Análisis de la seguridad en el entorno virtual pWnOS. Recuperado de:
http://dspace.uclv.edu.cu/bitstream/handle/123456789/1344/Saimy%20Torre%20Garc%C3%ADa.pdf?sequence=1&isAllowed=y

Uninotas (2017). Las pruebas que comprueban la corrección del código fuente de una aplicación son. Recuperado de:
https://www.uninotas.net/las-pruebas-que-comprueban-la-correccion-del-codigo-fuente-de-una-aplicacion-son-2/

Universidad Católica Andrés Bello (2007). Temas de comunicación. Recuperado de: https://goo.gl/sG1MQQ

UTM (s.f.) Usabilidad. Recuperado de: http://www.utm.mx/usabilidad.html

W3C. (1999). Introducción a las Pautas de Accesibilidad al Contenido en la Web (WCAG). Recuperado de https://www.w3c.es/

Zambrano, L. (2017). Hacking Etico. Recuperado de: https://es.scribd.com/document/338972366/Hacking-Etico