Webtest Checklist

Enviado por xacobe el 6 January, 2010 - 20:51.

1) Test de Funcionalidad
2) Test de Usuabilidad
3) Test de Interface
4) Test de Compatibilidad
5) Test de Rendimiento
6) Test de Seguridad


--------------------------------------------------------------------------------------------------
Testear
todos los enlaces en la página web, conexiones a las bases de datos,
formularios en la página para enviar o recoger información del usuario,
testear "cookies". 

Checkear todos los links:
  • Testea los enlaces salientes de todas las páginas desde un dominio.
  • Testea todos los enlaces internos.
  • Testear enlaces que saltan en la misma página.
  • Testea enlaces usados para enviar un email al administrador u otros usuarios.
  • Test to check if there are any orphan pages. Testea enlances para ver si hay alguna página huerfana.
  • Testear que todos los enlaces anteriores funcionan, conocidos como enlaces rotos.

 
Aplicaciones para testear los links Link Valet (está bien para el chequeo de unas pocas páginas) , Xenulink o  linktiger.com

Testear formularios en todas las páginas:

Los
formularios son parte integral de cualquier web site. Son usados para
recoger información de los usuarios y mantener interacción con ellos. 

  • Chequear todas las validaciones en cada campo.
  • Chequear los valores por defectos de los campos.
  • Wrong inputs to the fields in the forms. Introducir data errónea en los formularios
  • Opciones para crear los formularios si existen, borrar formulario, ver o modificarlos. 

Testear los Cookies:
Las
cookies son pequeños archivos almacenados en el ordenador del usuario.
Básicamente son usados para mantener la información de la sesión del
usuario. 

  • Testea la aplicación activandolos y desactivandolos en tu explorador. 
  • Testea si están correctamente encriptados antes de almacenarse en el ordenador del usuario.
  • Chequea las sesiones de usuarios

See
if appropriate messages are displayed to user like “For smooth
functioning of this site make sure that cookies are enabled on your
browser”.


Validatar el HTML/CSS:

Chequear si el sitio es indexable por diferentes buscadores
Asegurarse que se usan correctamente los encabezados h1, h2...
Esto puede ser hecho con validadores como: W3C validator o WDG validator.

Base de datos tests:
La
consistencia de los datos es muy importante para una aplicación web.
Chequea la integridad de los datos y errores mientras editas, borras y
modificas formularios en la web. SI es necesario chequea que todas las
querys a la base de datos se están ejecutando correctamente, si los
datos proporcionados son correctos y actualizados.

Otros test seria la carga en la base de datos, esto lo veremos en "performance test"


JavaScript Tests. Desactivar JavaScript
Muchos
sitios dependen -sin necesidad real.  JavaScript para la navegación,
con el resultado de que la falta de lectores de JavaScripts el sitio se
vuelve inusable
Evitar
expresiones sin sentido como "Necesitad JavaScript para ver este
sitio". Si tienes algo que merezca la pena enseñarse, di al usuario que
por ejemplo "Activa el Javascript para ver esta animación de Inteligais
technologies"

Mensajes de advertencia: User
input should get verified at system level according to business rules
and error/warning messages should be flash to user for incorrect inputs.
La
entrada de datos de los usuarios debería verificarse a nivel del
sistema respetando las reglas de la empresa. Los mensajes de
error/advertencia deberían aparecer cuando el usuario introduzca datos
erróneos. 



2). Test de Usuabilidad:

Test de Navegación:
Navegación
se refiere como el usuarios navega por las páginas web, los diferentes
controles como botones, cajas o cómo el usuario utiliza los enlances en
la página para navegar por el sitio.
Test de usuabilidad incluye:
  • El sitio web debería se fácil de usar. Instrucciones deben ser claras. 
  • Chequear si las instrucciones son correctas y cumplen con su objetivo.
  • El menú principal debería de estar en cada página y ser consistente.

Chequeo del Contenido: 

  • El contenido deberá ser  lógico y fácil de entender. 
  • Chequear los errores gramaticales y ortográficos.
  • Todos los textos anclados deberán funcionar correctamente
  • Las imágenes en su sitio con tamaños correctos.

Otra información para la ayuda del usuario :
Como
opciones de búsqueda, mapa del sitio, archivos de ayuda. Mapadel sitio
debería estar presente con todos los links en el sitio web con una
vista de navegación en arból
Opciones
de búsqueda ayudará al usuario a encontrar páginas que ellos buscan de
manera fácil y rápida. Esto son elementos opcionales que si presentes
deberían ser validados.


3). Test de la Interfaz (GUI Testing):
Las interfaces principales son:
Servidor web y aplicaciones de la interfaz del servidor
Apliaciones del servidor y la interfaz de la base de datos en el servidor.

Comprobar
si todas las interacciones entre los servidores se están ejecutando
correctamente. Los errores son manejados correctamente.

SI
la base de datos devuelve mensajes de error por algún query hecho por
otra aplicación del servidor este deberá recogerse y mostrarse estos
mensajes de error apropiadamente al usuario. 

Comprobar que pasa si el usuario interrupte una transacción a medias?

Comprobar que sucede si la conexión al servidor web es reseteada en la mitad del proceso?

a. Los textos han de estar correctos.


b. El texto alrededor de la fotos deberá fluir correctamente.

c. Instructions
used in web pages should be correct (i.e. if you follow each
instruction does the expected result occur?) Las instrucciones  usadas
en la páginas deberá ser correcta (ej. si sigues cada instrucción
¿consigues el resultado deseado?

d.Comprobar
las especificaciones de tamaño en imagenes: Comprobar si al menos el
texto de la página aparece rápidamente y si no lo hace es probablemente
no están especificadas el HEIGHT y  WIDTH en algunas de la imágenes.

e.Ver
la página en un explorador de texto (text browser) o un emulador
(http://www.seo-browser.com). Comprobar cada página. Esto te ayudará a
ver los textos ALT mal seleccionados o que falten. También como ven tu
sitio los motores de búsqueda. Esto se puede hacer con el addno de
Firefox "web developer". El navegador de Opera tiene incluido uno.

f.Desactivar
las imagenes:  Muchos usuarios desactivas las imágenes -dispositivos
móviles, conexiones lentas- . Comprobrar si el sitio es accesible y
navegable, particularmente, comprobar si un texto explicativo se ha
puesta en cada imágen.
g. Check sensible page titles: Check that the page titles (i.e. the contents of the 

h.Cambio de resolución y sus efectos en la página.

i. Espacio entre imágenes para verificar que se están mostrando con el texto correcto.

j. Imprimir– Las impresiones deberán ser correctas.

Para más información sobre el testeo de la interfaz (GUI testing) ver --> http://puretest11.blogspot.com


a. La
información mostrada en el navegador deberá encajar con la información
en el servidor. Para testear el navegador y la interfaz del servidor,
ejecutar querys en la base de datos para asegurarse que la transacción
de datos está empezando a ser devuelta y almacenada correctamente.

b. Control
de los error: Make sure system can handle application errors Asegurarse
del que el sistema puede manejar los errores de la aplicaciones.


4).Test de compatibilidad:
La compatibilidad de un sitio web es un aspecto del testing muy importante. Hay distintos test de compatibilidad:


  • Navegadores.
  • Sistema operativo -OS
  • Navegación móvil
  • Opciones de impresión

Compatibilidad entre los Navegadores:
Diferentes navegadores tienen diferentes configuranciones que cada página web debería tratar.

El código debería ser multiplataforma. 

- Firefox, como el que mejor compila los estándares y el segundo navegador más usado.

- Internet Explorer para Windows – (IE6, IE7, IE8) actualmente el navegador más usado. - 
-
Opera and Chrome – growing in popularity due to its speed and pretty
good standards compliance. creciendo en popularidad gracias a su
velocidad y buena aceptación de los estándares


Compatibilidad del OS:
Alguna de la funcionalidad de tu aplicación web puede no ser compatible con todos los sistemas operativos.
Todas
las tecnologias nuevas usadas en el desarrollo web, como graficos,
interfaces llamando a diferentes API´s puede que no estean disponibles
en todos los sistemas operativos.

Navegación Móvil:
Cada vez más presente, la navegación a través de dispositivos móviles se convierte en un deber.

Opciones de Impresión:
Testear
como son impresas la página. Tanto si se imprime desde la opciones del
navegador o (con más motivo) desde la página web. Debería encajar el
tamaño del papel, tipografía, gráficos..



Test de accesibilidad

Esto
es especialmente para personas con algún tipo de discapacidad, pero
tambiién para aquellos que usan un navegador de texto, sin imágenes por
una conexión lenta. Ver el  Web Content Accessibility Guidelines.

Tampoco está de más comprobar algunas páginas a través de un chequeador como Bobby orAccessibility Valet  para familiarizarse con los problemas relacionados y hacer la mejoras oportunas.


5). Test de Performance:
Apliaciones web deberían aguantar cargas pedadas. Deberian incluir:

Web Load Testing
Web Stress Testing

Testea la aplicación en conexiones con distintas velocidades 

En web load testing testear
si muchos usuarios acceden a la misma página. Can system sustain in
peak load times? Puede el sistema aguantar picos altosSite should
handle many simultaneous user requests, large input data from users,
Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing: Generalmente
stress significa llevar un sistema más allá de los limites
especificados. Web stress testing is llevado a cabo para "romper" el
sitio provocando stress y comprobar como el sistema reacciona y se
recupera de una caída.

Stress
es generado a través de la entrada de datos, login y sign up areas. En
los test de rendimiento web comprobamos la funcionalidad de un sitio en
diferentes sistemas operativos. 

Normal testing. Si una silla está diseñada para 100 kg y mi peso es 70, es un test normal
Load testing. Si mi peso es 100 kg, es un loading test
Stress testing. Si mi pero es de 120 kg, es un stress testing

+ info sobre las diferencias entre normal, load , y stress testing en Performance testing


Step 6 - Test de rendimiento (Performance testing)

b. Largos periodos de uso: Es el sitio capaz de funcionar durante largos períodos sin caerse.
Más información sobre Load testing, ver: http://puretest.blogspot.com/2009/11/performance-testing-1.html

c.Rendimiento de la página web (speed) Web page performance

Apliación para comprabor la velocidad de carga de la página :
"Page
Speed" genera su resultado basado en el estado de la página en el
momento que ejecutas la aplicación. Para asegurarse del resultado más
preciso, se deberá esperar hasta que la página termina de cargarse
totalmente antes de ejecutar PageSpeed


6). Test de Seguridad:
Comprobar los siguientes con casos para la seguridad web:
  • Testear
    si pegando url internas directamente en la barra del navegador sin
    logear. Página internas no deberían de abrirse. Pegar una URL interna
    directamente en el navegador (barra de direcciones) sin estar
    registrado. Páginas internas no deberían abrirse
  • Si
    estas logeado usando un usuario y contraseña y navegando las páginas
    externas con url tipo ID=123, intenta cambiar en la url el parametro
    ID. Accesso debería ser negado.
  • Intentar poner datos falsos en campos como usuario y contraseña, cajas de texto. Chequear como reacciona el sitio.
  • Las carpetas web y archivos no deberían ser accesibles directamente a excepción de las opciones de descarga dadas.
  • Testear los CAPTCH para los scripts de logeado automático
  • Comprobar
    si el SSl es usado en zona de seguridad. Si el mensaje correcto es
    mostrado cuando el usuario pasa de una conexión segura a un sin
    seguridad y viceversa.
  • Todas
    las transacciones, mensajes de error, intento de romper la seguridad
    deberían registrarse en la base de datos, archivos logs en algún lugar
    del servidor. 
  • Cada
    directoria tendrá un archivo index.html o mail.html, de manera que no
    aparecerá un listado del directorio en dicha dirección.
  • 6.3 Archivos Log
    A. Registra el servidor cada transacción.
    B. Registra los intentos no logrados de logear 
    C.(IP address and User name). ¿Que registra de cada transacción? (número IP y Nombre de Usuario)
  • 6.4 SSL
  • C. Hay un límite de tiempo?
    D. Qué pasa si el usuario intenta una trasacción una vez superado el límite de tiempo? 





Step 5 - Test de Seguridad

Limitar el número de intentos: ¿Hay un máximo de intentos fallidos antes de que el servidor bloquee al usuario.

b. Verificar las normas para la selección de contraseña

e. Testear el  CAPTCHA donde haya formularios y campos con entrada de datos.

f. Limpiar el  Cache: Asegurarse de limpiar el caché del navegador, incluyendo las cookies, antes de cada test.

i. SQL injection
(SQL
injection is an attack in which malicious code is inserted into strings
that are later passed to an instance of SQL Server for parsing and
execution.)

j. Cross-site
scripting (XSS):Buscar áreas donde la aplicación permita la entrada de
datos al usuario, como una página donde el usuario puede enviar su
feedback o reviews de un producto, por ejemplo.

Intenta enviado lo siguiente:
1. >"'><script>alert(‘XSS')</script>
2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
3.
>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5. %22%2Balert(%27XSS%27)%2B%22
6. <table background="javascript:alert(([code])"></table>
7. <object type=text/html data="javascript:alert(([code]);"></object>
8. <body onload="javascript:alert(([code])"></body>  

Si ese texto se muestra donde recargas la página, entonces tu sitio tiene un vulnerabilidad XSS
(Ataques
Cross-site scripting ocurren cuando una persona maliciosa, el atacante,
puede forzar un usuario desconocido, la víctima, para ejecutar
"client-side script" de la selección de atacante. El término
"cross-site scripting" es un poco confuso, porque no solo es sobre
"scripting" y no sucede solo "cross-site". Es un nombre que fué acuñado
porque fué descubierto y así quedó. 

k. Si
tu aplicación tiene un identificador numérico de sesión en la URL ,
desciende el número por uno  (-1) y recarga la página. La aplicación
tiene una vulnerabilidad "sessión hijacking" si la aplicación te vee
como un usuario diferente.
(Sessión
hijacking, también conocida como TCP sessión hijacking, es un método de
tomar el control de la sesión de un usuario, obteniendo la sessión ID y
enmáscarado como el usuario autorizado. Una vez que la sesión de
usuario ID ha sido accedida (a través de una sesión de predicción), el
atacante puede enmascarase como ese usuario y hacer todo lo que el
usuario es autorizado ha hacer en la red.)



-------------------------------------------------

1    Todos los campos de entrada de datos tiene el atributo HTML SIZE usado correctamente.
2    Todos los campos de entrada de datos tiene el atributo HTML
MAXLENGTH (MAXLENGTH is used to specify the maximum number of
characters a user can enter es usado para especificar el número máximo
de carácteres que un usuario puede introducir). 
3    Si controles Radio son usado, uno ha de estar seleccionadopor defecto. 
4   Todos los campos obligatorios usan una pista visual para indicarlo
5
  En los formularios "drop-down", las opciones son ordenadas
apropiadamente y los campos son suficientemente profundos para mostrar
todas las opciones.
6    Los datos no son perdidos cuando el usuario
hace click en el boton "back" del navegador (y consecuentemente
"foward") en los distintos formularios del sitio. Y viceversa
8    La información no se pierde cuando el usuario usa los botones Go/History para revisar los formularios anteriores.
9 Los datos no son perdidos cuando el usuario hace click en el boton  bookmark/Favourite del navegador en los distintos formularios del sitio
10   Los datos no son perdidos cuando el usuario hace click en el boton  "reload" del navegador en los distintos formularios del sitio
11   Los datos no son perdidos cuando el usuario cambia el tamaña de la ventana de navegador.
12
  Duplicate data is not added to the dtatabase when a user presses any
combination of Forward,Back,GO/History,Bookmark/Favourite,Reload, or
Resize buttons midway through a series of forms.
Datos
duplicados no son adheridos a la base de datos cuando el usuario
presiona cualquier combinación de los botones Foward, Back, Go/Hystory,
Bookmark/Favourite, Reload, or Resize. 
13  El navegador coloca el cursor en el campo/control más apropiado cuando el formulario aparece por primera vez.
14
 Usando la tecla "Tab" permite al usuario navegar a través de los
campos de un formulario en un orden de arriba-a-abajo,
izquierda-a-derecha.
15  If the form's data is sent back to the Web
server using the HTTP  GET commaned,the data is not truncated. Si los
datos de un formulario son enviados de vuelta al servidor Web usando
HTTP GET comandos, la data no está truncada.



Herramientas que pueden tener un papel importante a la hora de hacer el testing :

a. Fireshot (Usado para tomar pantallazos mientras se informa de errores): Pantallazos
pueden ser salvados en los formatos: (PNG, GIF, JPEG, BMP), impresos
(NEW), copiados al clipboard, enviados por mail o enviar a un editor
externo.

b. Selenium (Usado para test de funcionalidad):
URL: http://seleniumhq.org/download/ (Download Selenium IDE)
Cuales son los componentes de selenium ?
Selenium IDE - Plugin para Firefox para grabar y hacer tests en firefox.
Selenium
RC- Allows playing of exported test in different platform/OS. Permite
hacer test exportados en diferentes plataformas/OS
Selenium Grid - Permite el control de multiples selenium machines

c. Firebug (Usado para GUI tests): Integrado
con Firefox proporciona un colección de herramientas de desarrollo a
tus manos en tu navegador. Puedes editar, debug, y monitorizar CSS,
HTML, y JavaScript en vivo en cualquier página web.




RESOURCES:
La mayor parte de lo escrito aquí ha sido resumido y traducido libremente de:


http://forums.sureshkumar.net/qa-testing-concepts/30514-what-web-testing-what-should-you-test-web-testing.html






----------------------
a bit off topic:
http://puretest.blogspot.com/2009/11/severity-vs-priority.html
Explicación sobre los conceptos severidad y prioridad, y como se deben
tratar por un equipo. La severidad sería dada por los testers y la
prioridad por el test-lead or project manager.

Bookmark/Search this post with