Saltar al contenido principal
Página

Tema 2.3 - Pruebas de UI

Ahora veremos un resumen de algunas de las pruebas que a nivel de UI se deben tener en cuenta, teniendo en cuenta los controles HTML y el tipo de dato que almacenará.

 

Links:

Para este tipo de elementos es necesario verificar que los vínculos a los diferentes lugares o páginas del sitio, redirigen correctamente, es decir que no hay links rotos, este tipo de prueba se puede realizar de forma manual o automatizada.

Comúnmente este tipo de prueba hace parte del conjunto de pruebas de regresión, ya que es bastante frecuente que los enlaces dejen de funcionar por diversos motivos.

 

Botones

Este tipo de controles normalmente se usan para desencadenar una acción o funcionalidad, de manera que a nivel de UI se debe probar que, al dar clic sobre él, se desencadene el proceso para el cual está destinado, por ejemplo, realizar operaciones CRUD de la base de datos, abrir una nueva ventana, etc, sin llegar a los detalles de cómo lo hace, ya que es este sentido estaríamos hablando de pruebas funcionales.

 

Input

A nivel de campos de texto veremos más a detalle algunos de los diferentes casos de prueba que se deben tener en cuenta para este tipo de controles.


1. Obligatoriedad

Se debe validar que en los formularios sean diligenciados todos aquellos campos que sean obligatorios; éstos deben ser marcados de alguna manera que permita a los usuarios entender que son requeridos.



2.   Valores permitidos 

 Debemos asegurarnos que los datos ingresados están siendo correctamente validados, y en el caso de recibir valores no permitidos indicar de manera explícita el error, veamos algunos escenarios:

 

Para campos que sólo reciben valores de tipo texto, es necesario hacer pruebas ingresando números y caracteres especiales, aunque esto depende de la naturaleza de la información que el campo almacena, por ejemplo, un campo que almacena direcciones, debería permitir el ingreso de letras, números y algunos caracteres especiales, en este punto, es de vital importancia validar con el desarrollador si se está haciendo uso de expresiones regulares, en caso que no sea así se recomienda su implementación.






3.    Longitud

Los campos de texto y los textarea tienen un límite, es decir, la longitud máxima de los textos ingresados que es soportada, dependiendo de la forma en la que haya sido desarrollada esta validación podremos observar alguno de los siguientes escenarios al sobrepasar el valor límite permitido:

  • Que no sea posible seguir agregando más caracteres, en cuyo caso la validación funciona, pero deberemos evaluar que dicho límite es suficiente para su propósito.
  • Que sea posible seguir tipeando caracteres, pero que al momento de enviarlos la cadena sólo contiene una parte de la cadena original.
  • Que no haya validación alguna y sea posible enviar una cadena de cualquier longitud, haciendo que el error no sea contenido en el front sino en el back de la aplicación, esto es de vital importancia si pensamos que los campos de las bases de datos, tienen tamaños fijos, de manera que al insertar un dato en la BD cuya longitud es mayor a la definida, se presentará un error en su inserción, este tipo de controles deberían hacerse directamente desde el front de la aplicación, para evitar o minimizar su impacto al negocio.

 

4. Encoding

El encoding o codificación de caracteres, es el método que permite convertir un carácter de lenguaje natural en un símbolo de otro sistema de representación. Para el idioma español el estándar de codificación es el UTF-8 ya que este incluye todos los símbolos usados en el idioma. La forma de probar esto es ingresando cadenas de texto que contengan acentos (á,é,í,ó,ú), diéresis ( ¨ ) y/o la letra ñ en ellas.




5.   Mensajes de error

Se deben validar todos los mensajes de validación que arroja la aplicación, los cuales deben indicar con claridad la naturaleza del error, no deben mostrarse mensajes de error técnicos, éstos deben estar reservados para la trazabilidad de errores en el log de la aplicación.




6.  Espacios

Para campos obligatorios probar que no se permite el ingreso de espacios consecutivos.

Otro tipo de input, son aquellos que almacenan contraseñas, en estos casos se debe tener en cuenta  :


   6.1   Seguridad de la contraseña

Se debe comprobar que la contraseña cuenta con los parámetros de seguridad establecidos (letras mayúsculas, letras minúsculas, caracteres especiales o números), además de ocultar el valor que se introduce en el campo (por ejemplo, con puntos o asteriscos) para impedir que otros puedan leerlo.



           6.2  Longitud de la contraseña
Verificar la operación del campo contraseña ingresando un número de caracteres inferior al estipulado.



Verificar la operación del campo contraseña ingresando un número de caracteres inferior al estipulado.

1.    Estructura

Validar la estructura con la que se ingresa un correo electrónico, es decir, que identifique cada una de las partes que lo componen: Nombre, símbolo @ y dominio; por lo tanto, no debería aceptar cadenas que no cumplan con esta estructura, normalmente se valida por medio del uso de expresiones regulares.



2.    Longitud
Al igual que para los campos de tipo texto, se deben realizar validaciones de la longitud permitida.

             
            2.1 Campos Numéricos (para hacer cálculos):

Se deben probar los valores máximos, mínimos e incrementos (si incrementa de 1 en 1 o hay un valor establecido), las técnicas de valores límite y clases equivalentes son muy útiles para el diseño de estas pruebas.

  • Se debe probar que no se acepten letras o caracteres extraños.
  • Se debe validar si el campo acepta separador de punto flotante (coma o punto) y la precisión soportada.


    2.2 Campos de números telefónicos:

  • Se debe validar el número de teléfono válido, esto dependerá del país a la que pertenezca la aplicación, las reglas pueden cambiar tanto para números fijos como de celular. Para el caso particular de Colombia se debe tener en cuenta que:

o   Los números fijos tienen 7 dígitos.

o   Los números celulares tienen 10 dígitos.

o   Los números de celular inician con 3.

o   Existe una lista de prefijos válidos para cada operador celular:

§  Claro: 310, 311, 312, 313, 314

§  Movistar: 315, 316, 317, 318

§  Tigo: 300, 301, 302

Debido a esto un número de celular con prefijo 399 XXX XX XX no sería un número válido.

o   Se deben tener en cuenta los indicativos de ciudad y de país.

 

    2.3 Campos de fecha:

  •  Se deben tener en cuenta las fechas mínima y máxima para el caso de los campos de tipo fecha.
  • Se deben tener en cuenta las horas mínima y máxima para el caso de los campos de tipo hora.
  • En algunos casos, no debería ser posible seleccionar una fecha anterior a la actual.
  • Se debe validar que no se acepte el valor cero (0).
  • Que al seleccionar una fecha del datepicker, el dato almacenado en el inputbox sea el correcto.
  • Si se permite el ingreso del dato desde el teclado, verificar con fechas erróneas, por ejemplo, para el campo día ingresar un 32, para meses en formato de número ingresar mes 13 o año 0000.



 

 

Checkboxes

Los checkbox son otro campo de tipo input. Como ya vimos, se caracterizan por que permiten la selección de una a varias opciones de un grupo de opciones, para este tipo de campos a nivel de UI es necesario verificar que se permita al usuario la selección de distintas opciones al mismo tiempo, sin que esto implique que otras se marquen o desmarquen.





Radio Buttons


Este tipo de control es otra variante de los campos de tipo input, similar a los checkbox pero se caracteriza porque sólo permite la selección de una opción del grupo de opciones, para verificar su funcionamiento nos debemos asegurar que, en el momento de hacer clic en el botón de opción, este permite elegir solo una de las opciones y no haya ninguna otra seleccionada.





Botones de Interacción:
 

Si se cuenta con botones interactivos que permiten imprimir, eliminar información, cerrar ventanas, enviar información, agregar información, enviar una página a un amigo, etc. se debe validar que estos estén realizando correctamente la acción indicada.





Eventos del mouse, métodos abreviados y teclas de función

Se deben verificar las opciones de copiar y pegar texto con el mouse o todas las que sean permitidas y accesibles desde el menú contextual que sale al dar clic derecho sobre un elemento, en algunos caso, de acuerdo a las necesidades del negocio es necesario restringir estas opciones, de manera que se debe verificar en estos casos que dichas funcionalidades no estén disponibles.


De igual forma, es necesario validar que la interacción con los distintos elementos de la página por medio del teclado, es decir, se deben tener en cuenta los índices de tabulación para desplazarse por la página, uso de métodos abreviados y teclas de función (F1, F2, etc...)  o en caso que deban estar restringidos que no se permita su uso.

      
 
Ortografía

Asegúrese de que cualquier texto en el sistema no hay errores de ortografía, incluso los mensajes de alerta.


 
Evaluación de elementos de diseño

Verificar la correcta aplicación de elementos de diseño como lo son colores, fuentes, tamaños de fuente, etiquetas, cuadros de texto, formato de texto, títulos, listas, iconos, enlaces.



 



Reingreso y Corrección de Datos

Para mejorar la interacción del Sitio Web, cuando tras el ingreso y envío de los datos de un formulario (después de la validación local del formulario) el usuario presiona el botón Back de su programa visualizador para volver atrás y modificar algún campo, se le deben presentar todos los datos que hayan sido ingresados, de esta manera se aprovecha la información ingresada previamente, evitando la frustración del usuario por tener que escribir nuevamente el contenido completo del formulario.

 
 
Multiplataforma

Se debe comprobar que los formularios funcionan en diferentes versiones de programas visualizadores (browsers), de sistemas operativos y de tipos de conexión a Internet (conmutado, banda ancha y dedicado), dado el crecimiento del mercado y de usuarios que poseen smartphones y tablets, es altamente recomendable realizar también estas comprobaciones en estos dispositivos móviles.


       Pagina vista desde una Tablet.


Página abierta desde un Google Chrome y en un pc.



Página abierta desde un celular.



Página abierta desde Internet Explorer.



Página abierta desde Mozilla Firefox.



Sistemas de Búsqueda

Si se cuenta con ellos, se debe validar que efectivamente permitan encontrar documentos existentes en el sitio; en este sentido se deben ingresar documentos específicos y luego buscarlos de manera de asegurarse que la funcionalidad está operando adecuadamente, si el sistema de búsqueda tiene una versión de búsqueda avanzada, se debe asegurar de que las opciones ofrecidas encuentren los documentos de la manera en que se ofrezca, el formulario para hacer la búsqueda debe ser intuitivo, evitándose el lenguaje técnico y específico que impida entender su funcionamiento entre usuarios con menores conocimientos de los temas abordados en la institución.




Última modificación: miércoles, 23 de marzo de 2022, 09:54