Este es el último post del conjunto de artículos dedicados al testing del Service Pack 2 de Windows Vista y Windows Server 2008. En esta ocasión voy a hablar sobre Internet Explorer. El navegador es la llave para abrir la Web, si el mismo presenta fallas y la experiencia de usuario es frustrante, los usuarios/sesarrolladores se alejarán e incluso peor, no desarrollarán aplicaciones que se ejecuten en forma optimizada. Internet Explorer no es una aplicación más, es en sí una platafoma ya que es el navegador que más APIs expone para el uso de terceras partes y esto hace que cada vez la simbiosis que tiene con Windows sea más profunda y que los chicos malos(Unión Europea y Opera) se enojen cada vez más. De heccho es asombrosa la cantidad de aplicaciones de escritorio que como requerimiento necestian una versión determinada de Internet Explorer previa a su instalación.
Pero antes de tratar a Internet Explorer, quiero hablar un momento sobre la importancia de reportar bugs. Es realmente fácil y cómodo sentarse usar un programa descubrir un bug y pensar «Es Microsoft, no lo van a arreglar» o «Esto no sucede en….». Lo importante es hacer llegar este bug, ya que si hay mucha gente que reporta un problema en escenarios semejantes, este escenario toma protagonismo, los bugs son agrupados y es priorizado por Microsoft. Por ello es necesario nuestra participaión activa para ayudar a cubrir cosas que no se saben o desconocen.
Volviendo al tema que nos convoca, una de las nuevas características tanto de de IE7 e IE8 son las extensiones TLS. TLS es el sucesor de SSL, y como se imaginan es de vital importancia en transacciones comerciales en la Web por eso es necesario que opere efectivamente. Las extensiones TLS son una manera de comunicar informacion adicional en el handshake SSL, y hay algunos servidores dando vueltas por ahí que no manejan esto correctamente. Si este es el caso Microsoft trata de contactar a estos sitios para que actualicen su software de servidor y manejen bien las extensiones TLS. De todos modos es importante reportar todos aquellos sitios que no funcionen con la opción TLS. Si se deshabilita TLS y el sitio funciona correctamente, es necesario reportarlo a Microsoft y al mismo sitio.
Otro problema que aparece frecuentemente es que muchos sitios explícitamente bloquean la cadena de User Agent de IE7, es el caso en el que un sitio reporta que no soporta su navegador y que se actualice a IE 5 o IE6. Esto se arregla contactando a Microsoft y al propietario del sitio solicitando que soporte IE7. Adicionalmente podemos modificar el registro de manera que IE7 impersone en el sitio como IE6, para ello hay un script en http://www.fiddlertool.com/useragent.aspx que automáticamente setea eso por nosotros y podremos navegar ese sitio sin problemas. Ahora si luego de impersonar como IE6 el sitio no funciona correctamente, reportar un bug.
Respecto de CSS, muchos sitios usan CSS hacks para lograr la apariencia deseada, sin embargo a veces esto no alcanza en IE7, y se reporta el bug como un screenshot y la dirección de la pagina a revisar. Siempre es importante resaltar qué parte del screenshot no se renderiza como se espera, esto es fácil ya que con cualquier editor de imágenes podemos destacar el área desprolija lo cual ayuda mucho a focalizarse en la parte de la página a examinar para corregir el bug.
También es importante disponer de información sobre la configuración de IE7, ya que hay clases de bugs que suceden cuando hay ciertos Add-ons intalados y no suceden cuando estos no están. Los Add-ons impactan profundamente en el estado de IE(especialmente las toolbars de Google, Yahoo y MSN), por eso también es útil enviar una captura de la ventana «Manage Add-ons» con las siguientes columnas de datos como muestra la imagen:
Internet Explorer 7 en Windows Vista ofrece una característica conocida como «Potected Mode», que incluso cuando ejecutamos IE7 como administradores, IE7 no se ejecuta con priviliegios de administrador, sino con el menor privilegio posible. Lo bueno es que cualquier vulnerabilidad de seguridad que surja y trate de ser explotada, está contenida, o sea el daño que puede hacer es minimizado o nulo. La parte desagradable es que hay muchos sitios, Add-ons y escenarios de uso que asumen que tienen privilegios totales(sí como en MS-DOS) en nuestro ordenador, aunque no sean sitios maliciosos están diseñados con otro criterio de seguridad. Por eso es necesario que siempre ejecuten IE7 en modo protegido y reporten bugs sobre problemas que surjan en ese modo.
Internet Explorer 7 soporta OpenSearch(desarrollado por el equipo A9 de Amazon), que permite agregar proveedores de búsqueda al combo de búsqueda de la esquina superior derecha, sin tener que ejecutar ni instalar código externo en nuestro ordenador. La idea es desarrollar proveedores de búsquedas, escribiendo descriptores OpenSearch de nuestros sitios favoritos utilizando la documentación disponible en http://www.opensearch.org/Specifications/OpenSearch/1.1. Aparentemente esta nueva forma de proporcionar Add-ons para navegadores basándose en descriptores o manifiestos en XML en vez de código compilado que tiene que ser descargado está teniendo mucha aceptación. Sin embargo no significa que esté excenta de bugs ya que todo lo que usa XML tiene sus problemas del encoding/overflow/parsing, etc y es necesario considerar eso al momento de testear. Finalmente la búsqueda en un navegador es sobre los usuarios y sobre cómo los usuarios quieren buscar en Internet y no sólamente para un par de grandes motores de búsquedas. Por eso he desarrollado un Search Provider para Geeks.ms el cual es descubierto automáticamente por IE7/IE8 cuando ingresan a este blog, ya que el combo de búsqueda cambia a color naranja como lo muestra la siguiente imagen:
Luego, al hacer click en el combo, pueden observar el nuevo proveedor de búsqueda destacado, para agregarlo simplemente hacemos click en «Geeks.ms» desde el submenú «Add Search Providers», luego click en «Add Provider» y estamos listos para buscar en Geeks.ms desde Internet Explorer.
Hoy por hoy todos los navegadores detectan feeds RSS y proporcionan una representación para la misma. Al testear RSS, es importante filtrar por categorías, fechas, tags, etc y ver como funciona y se adapta a la representación elegida. Por ejemplo una buena prueba sería hacer una búsquedda en Ebay, obtener el RSS correspondiente y probar todas las posibles maneras de filtrar, ordenar y buscar ese feed RSS. La otra parte de RSS en Internet Explorer es Windows RSS Platform, es una API que que permite que nos suscribamos y manipulemos una feed RSS con Internet Explorer. Al ser una API pública que agrega valor a Windows, cualquier otra apicación puede hacer uso de esta API sin recurrir a librerías de terceros o a una implementación propia. Empleando esta API, hay oportunidad para escenarios de sincronizacion en la nube, etc. Es desafío es ver qué programas podemos escribir contra esa API que hagan cosas asombrosas como así reportar cualquier bug en la misma.
Espero que estos 4 posts sobre testing hayan abierto la cabeza o desarrollado un criterio adicional sobre la naturaleza del software(concretamente un sistema operativo) y sobre cómo el mismo está conectado en un ecosistema del cual se nutre y debe nutrirlo para que exista un equilibrio aceptable y todos ganemos.
Fernik
