Perfiles de dispositivo en móvil, tablet y escritorio

El recorrido importa más que el tamaño de pantalla

Una página para teléfono no es una página de escritorio más estrecha. La entrada táctil cambia la respuesta de los controles. El teclado en pantalla reduce el espacio disponible alrededor de los formularios. La orientación afecta a la navegación y al contenido multimedia. Las convenciones de la plataforma influyen en menús, cargas, permisos y transiciones entre aplicaciones. Una prueba útil mantiene unidos estos comportamientos.

BotBrowser utiliza familias de dispositivos respaldadas por perfiles. El perfil seleccionado proporciona una base coherente para pantalla, entrada, contenido multimedia, identidad de plataforma y comportamiento de la familia de navegador. El mismo caso autorizado puede repetirse en una estación de trabajo, un runner de CI o un servidor administrado sin reconstruir el dispositivo mediante ajustes aislados.

El punto de partida debe ser el recorrido del cliente. Usa un perfil de teléfono para una compra móvil, uno de tablet para un panel táctil y uno de escritorio para un flujo de oficina. Registra la elección junto al caso. Así, otra persona puede reproducir las condiciones y entender qué representa la evidencia.

Coherencia del dispositivo y privacidad

El contenido web puede observar características generales del dispositivo y de la sesión. Por separado, una disposición de pantalla o un modo de entrada son habituales. En conjunto, pantalla, interacción, gráficos, contenido multimedia, idioma y contexto de red pueden facilitar la correlación a largo plazo. Un perfil mantiene estas familias alineadas y evita que una revisión autorizada mezcle de forma accidental el host con el dispositivo objetivo.

La coherencia también mejora la investigación. Un fallo de diseño observado con un perfil de tablet documentado resulta más fácil de repetir que otro provocado por ajustes temporales. Lo mismo ocurre con diálogos de consentimiento, controles de accesibilidad, pagos, recuperación de cuentas y casos de soporte. Una base estable ayuda a separar un problema de la aplicación de un cambio inexplicado en el entorno.

La gobernanza sigue siendo necesaria. Usa cuentas de prueba aprobadas, destinos autorizados, datos controlados y una política de retención para capturas y registros. La cobertura debe responder a un objetivo escrito de QA. Una lista pequeña vinculada a requisitos reales suele ser más valiosa que un catálogo amplio sin propietario.

Familias de comportamiento que deben permanecer juntas

Un perfil representa una condición completa de prueba:

• Pantalla: área útil, densidad visual, orientación, pantalla completa y diseño adaptable.
• Entrada: toque, puntero, teclado, foco, selección, arrastre y controles gestuales.
• Formularios: efecto del teclado en pantalla, validación, autocompletado, fechas y selección de archivos.
• Contenido multimedia: imágenes adaptables, reproducción, permisos de captura y presentación apropiada.
• Identidad de plataforma: familia de navegador y sistema operativo como una identidad coherente.
• Gráficos y texto: representación adecuada al perfil y al contenido revisado.
• Contexto regional: idioma, zona horaria y ubicación de red definidos por el plan autorizado.

Usa estas categorías para observar la aplicación: si un control sigue visible, si el formulario termina, si se respeta el consentimiento y si el perfil produce un resultado estable. La automatización de producción puede centrarse en el recorrido y su resultado esperado.

Seleccionar un conjunto representativo

Parte de datos que la organización pueda usar. Las métricas del producto pueden mostrar la proporción general de teléfono, tablet y escritorio. Soporte puede identificar un flujo móvil que genera problemas frecuentes. Accesibilidad puede exigir condiciones táctiles y de teclado. Estas fuentes permiten definir un conjunto compacto y justificable.

Cada perfil debe tener una razón. Un teléfono puede representar el recorrido móvil principal. Otro puede cubrir una clase de pantalla o entrada materialmente distinta. Una tablet cubre diseños que no aparecen en teléfono ni escritorio. Los perfiles de escritorio deben representar condiciones habituales, no cada monitor posible.

No elijas solo por novedad o popularidad. La selección debe reflejar la aplicación, las regiones atendidas y los compromisos de soporte. Revísala con regularidad. Retira condiciones sin requisito activo e incorpora una nueva cuando el uso o un cambio visible para clientes lo justifique.

Revisión en teléfono

Prueba tareas completas. Una captura de la portada no demuestra que alguien pueda iniciar sesión, aceptar una opción de privacidad, recuperar su cuenta, cargar un documento o finalizar una compra. Recorre el camino desde la entrada hasta el resultado y conserva el mismo perfil.

Observa controles en la parte inferior, navegación fija, diálogos y formularios con varios pasos. El área útil puede cambiar al enfocar un campo. El control activo, su etiqueta y la acción principal deben seguir siendo comprensibles y alcanzables. Revisa vertical y horizontal solo si el producto admite ambas orientaciones.

La revisión táctil no elimina la accesibilidad. Verifica orden de foco, etiquetas, recuperación de errores y preferencias de movimiento cuando formen parte del compromiso del producto. Muchos problemas móviles de privacidad y accesibilidad comparten una causa visible: opciones ocultas, estado poco claro o controles ligados a un único método de entrada.

Revisión en tablet

Las tablets suelen quedar entre las suposiciones de móvil y escritorio. El sitio puede pasar a varias columnas mientras la interacción sigue siendo táctil. La navegación puede convertirse en una barra lateral persistente. Tablas y diálogos ganan espacio, pero no la precisión de un ratón.

Usa perfiles de tablet cuando este estado intermedio sea relevante. Paneles, inventario, herramientas de campo, educación y medios son ejemplos habituales. Revisa vistas divididas, diálogos grandes, arrastre, teclado virtual y rotación. El ancho adicional no debe mostrar controles de escritorio difíciles de usar con el dedo.

Una tablet necesita sus propias capturas esperadas y notas de interacción. Si el producto admite teclado externo o puntero, regístralo como otra condición en vez de mezclar métodos de entrada en la misma ejecución.

Revisión en escritorio

El escritorio sigue siendo importante aunque el tráfico móvil sea mayor. Los flujos de oficina incluyen formularios largos, varias ventanas, descargas, cargas, teclado y mucha información. El perfil debe corresponder a la familia de navegador y plataforma cubierta por el requisito.

Prueba cambios de tamaño dentro del rango admitido, pero conserva una base documentada para comparar. Un tamaño aleatorio en cada ejecución dificulta interpretar capturas. Si se admiten portátiles compactos y estaciones amplias, define ambos como casos con nombre.

El escritorio también sirve como referencia para hallazgos móviles. Si un diálogo falla solo en teléfono, la investigación se acota. Si falla en todas las familias, puede pertenecer a lógica compartida. Compara el comportamiento visible y el estado final del mismo recorrido.

Formularios y teclado en pantalla

Los formularios merecen una pasada móvil específica. Prueba acceso, dirección, pago, búsqueda, recuperación y editores con el perfil seleccionado. El campo enfocado, la etiqueta, el error y la siguiente acción deben seguir visibles o ser fáciles de alcanzar.

Completa la secuencia. Corrige un error, abre y cierra un diálogo y vuelve a la página. Confirma que el desplazamiento sea predecible y que la posición resulte útil cuando desaparezca el teclado. Una captura del primer enfoque no demuestra que el formulario funcione.

BotBrowser puede representar comportamiento sensible al teclado en flujos móviles compatibles. Utiliza la configuración documentada del producto y evita imponer desde el framework otra condición de pantalla. El perfil debe seguir siendo la fuente del dispositivo durante toda la prueba.

Toque, puntero y teclado

La evaluación de entrada debe centrarse en resultados. Confirma que un toque active el control correcto, que el desplazamiento no dispare una acción cercana, que los tiradores sean utilizables y que los menús se cierren. Cuando se admita puntero o teclado físico, pruébalo como caso independiente.

El framework ejecuta interacciones aprobadas, pero no debe redefinir el dispositivo. Deja que el perfil establezca la familia y utiliza la automatización para seguir el recorrido. Esto mantiene el entorno comprensible.

La revisión manual sigue aportando valor. Un script confirma presencia y finalización. Una persona puede detectar un menú demasiado denso, una explicación de permiso confusa o una opción de privacidad difícil de alcanzar tras rotar. Combina ambas evidencias en flujos de alto impacto.

Orientación y diseño adaptable

Prueba la rotación donde el usuario realmente pueda necesitarla. Vídeo, documentos, mapas, gráficos y algunas herramientas de tablet suelen requerir ambas orientaciones. Un pago oficialmente vertical puede no necesitar la misma matriz.

Cuando la rotación esté incluida, verifica continuidad. La página debe conservar estado, mantener la tarea visible y no reabrir diálogos descartados. El contenido multimedia debe seguir controlable y los formularios no deben perder datos.

Captura antes y después con el mismo perfil. No combines la rotación con cambios de idioma, red o cuenta. Una sola variable controlada facilita entender el resultado.

Contenido multimedia y permisos

Cámara, micrófono, ubicación, notificaciones y archivos combinan presentación del navegador y consentimiento de la aplicación. Usa cuentas autorizadas y datos aprobados. La página debe explicar el motivo, aceptar una negativa y permitir cambiar la elección cuando el producto lo admita.

Mantén el mismo perfil durante la solicitud, la respuesta y cualquier reintento. Revisa el recorrido visible en lugar de recoger detalles del navegador. En contenido multimedia, confirma vista previa, silencio, cancelación y recuperación. En cargas, comprueba que las indicaciones y avisos de privacidad sean legibles.

Los permisos pueden persistir en el directorio de datos. Define una política deliberada. Un estado limpio sirve para la primera visita y uno conservado para el retorno. Etiqueta la evidencia para que el revisor conozca la condición.

Idioma y contexto de red

La familia de dispositivo es solo una parte. Idioma, zona horaria y región de red pueden cambiar contenido, formato, consentimiento y rutas de soporte. Selecciona estos valores desde el plan autorizado y mantenlos coherentes con el escenario.

No asumas que un perfil móvil exige un tipo concreto de red. Desarrollo, CI, oficina y redes de prueba administradas tienen restricciones distintas. La ruta debe estar aprobada, documentada y ser suficientemente estable. Mantén credenciales fuera de capturas y registros compartidos.

Ejecuta las variantes regionales como casos separados. No mezcles casualmente un cambio de idioma con otra cuenta, perfil y ruta. Los límites claros reducen la recolección innecesaria y facilitan repetir un fallo.

Evidencia útil para ingeniería

Registra familia de perfil, versión del navegador y de la aplicación, clase de cuenta, idioma, orientación y recorrido. Captura el fragmento mínimo que explique el resultado y elimina datos personales antes de compartir.

Los registros requieren la misma prudencia. Consola, trazas de red y diagnósticos pueden contener identificadores. Recoge solo lo necesario, limita el acceso y aplica la política de retención. Más datos no significan mejor evidencia.

Nombra las bases con claridad. Debe distinguirse un pago en teléfono, un panel en tablet y un caso de soporte en escritorio sin consultar otra hoja. Los nombres coherentes reducen errores cuando varios perfiles se ejecutan en paralelo.

Una matriz sostenible

Separa una puerta de lanzamiento pequeña de una cobertura programada más amplia. La primera contiene familias y recorridos cuyo fallo bloquea la entrega. Las ejecuciones programadas cubren más diseños, idiomas y rutas menos frecuentes.

Asigna propietario. Debe conocer el resultado esperado, el origen de los datos y la ruta de escalado. Una cuarentena debe ser temporal, indicar causa, conservar un caso diagnóstico menor y tener fecha de revisión. No aceptes silenciosamente capturas cambiantes ni reintentos repetidos.

CI e infraestructura administrada

Los runners necesitan el mismo perfil, navegador, recursos y estado de aplicación que la base aprobada. Distribuye estos elementos mediante los controles habituales de secretos y artefactos. No descargues un perfil diferente en cada ejecución salvo que la rotación sea el objeto del caso.

Evita que el framework sustituya la condición de pantalla. La automatización inicia el entorno, sigue la tarea y recoge evidencia de producto. La preparación del host pertenece a infraestructura, no a la identidad del dispositivo.

Planifica capacidad con tus páginas. Un panel multimedia y un formulario simple consumen recursos distintos. Comienza con poca concurrencia, observa finalización y margen, y fija un límite para esa carga. Repite la medición tras actualizaciones importantes.

Cuándo usar hardware físico

Usa dispositivos reales cuando el criterio dependa de cámara, radio, biometría, diálogos del sistema, transición a una aplicación nativa, políticas administradas o rendimiento de batería y temperatura. También corresponde cuando un contrato exige certificación en hardware.

BotBrowser puede cubrir antes la privacidad, el diseño, la interacción y la regresión, de modo que el laboratorio se reserve para lo que realmente depende del equipo. Si el resultado esperado necesita hardware o un servicio fuera del navegador, confírmalo en el dispositivo objetivo.

Revisión después de actualizaciones

El navegador, los perfiles, el framework y la aplicación pueden afectar al caso. Cambia una capa cada vez cuando sea posible. Ejecuta primero la puerta de lanzamiento y compara con una base de la misma familia y orientación.

Revisa consentimiento, permisos, recuperación, cargas, pagos y otros flujos con datos personales. Confirma que la negativa siga funcionando y que la aplicación no pida acceso adicional. Etiqueta las bases con la versión correspondiente y conserva solo lo necesario.

Decisión de despliegue

Elige perfiles cuando necesites QA repetible en móvil, tablet y escritorio dentro de CI o infraestructura administrada. Encajan en privacidad, diseño adaptable, accesibilidad, soporte y regresión.

Elige hardware cuando la aceptación dependa del equipo o del sistema operativo. Usa emulación adaptable sencilla durante el diseño temprano si solo importa el ancho. Muchos equipos combinan las tres opciones y asignan a cada una el requisito que puede representar con fidelidad.

Antes de ampliar, confirma propietario, uso autorizado, manejo de datos, retención, capacidad y escalado. Estas decisiones operativas importan más que el número de dispositivos del catálogo.

Preguntas habituales

¿Puede un perfil cubrir todos los móviles?

No. Representa una familia y una condición. Elige un conjunto pequeño según uso, soporte y diferencias materiales de diseño o interacción.

¿Debe el framework fijar su propia pantalla?

Mantén desactivadas las sustituciones cuando el perfil controle el dispositivo. Un tamaño especial debe ser un caso separado y documentado.

¿Pueden teléfono, tablet y escritorio compartir sesión?

Usa instancias separadas para identidades distintas. Así, estado, evidencia y fallos pertenecen al perfil previsto.

¿Cómo se valida la interacción táctil?

Completa tareas representativas con automatización aprobada y revisión manual. Comprueba alcance, desplazamiento, foco, diálogos, recuperación y finalización.

¿Con qué frecuencia deben revisarse los perfiles?

Revísalos cuando cambie el uso del producto, se modifiquen los compromisos de soporte o una actualización del navegador y la aplicación afecte de forma material a la prueba. Una revisión periódica de propiedad también evita acumular casos sin uso.

¿Sustituye esto a las pruebas de accesibilidad?

No. Los perfiles aportan condiciones. La accesibilidad requiere semántica, teclado, tecnologías de asistencia cuando corresponda, contraste, foco y revisión especializada.

¿Qué debe guardarse?

La evidencia mínima para explicar el resultado, con perfil, versiones, recorrido, idioma, orientación y estado. Elimina datos personales y aplica la política de retención.

Mantener una base documentada

Las pruebas de dispositivo funcionan cuando cada caso tiene propósito, perfil aprobado y resultado esperado a nivel de producto. Esa disciplina mantiene comparables las evidencias de móvil, tablet y escritorio entre desarrollo, CI, soporte y lanzamiento.

Descarga BotBrowser para ejecutar perfiles aprobados o revisa las funciones de coherencia de plataforma antes del despliegue. Para planificación móvil, consulta pruebas de perfiles Android. Coherencia de pantalla y ventana trata el diseño adaptable y perfiles multiplataforma explica las opciones de host.