Pruebas de perfiles de dispositivo: móvil, tablet y escritorio

¿Necesitas demostrar que un checkout móvil o un panel para tablet funciona sin reservar un laboratorio de hardware para cada revisión? BotBrowser puede repetir la condición de pantalla, entrada, multimedia y plataforma que ve el navegador desde un perfil aprobado, pero no demuestra sensores reales, diálogos del sistema operativo ni rendimiento del dispositivo; usa hardware físico para esos criterios de aceptación.

Resumen

Usa un perfil aprobado para un recorrido nombrado, registra el perfil y el resultado observado, y pasa a hardware físico cuando la aceptación dependa de equipo o de un comportamiento del sistema operativo fuera del navegador.

Contenido

• Empieza por el recorrido
• Elige familias de dispositivo
• Revisa formularios y tacto
• Controla orientación y permisos
• Conserva evidencia de publicación
• Escala a hardware físico
• Conclusión práctica

Empieza por el recorrido, no por el ancho de pantalla

Una página en el teléfono es más que una página de escritorio estrecha. La entrada táctil cambia la respuesta de los controles. El teclado en pantalla modifica el área útil alrededor de los formularios. La orientación afecta a la navegación y al contenido multimedia. Las convenciones de la plataforma influyen en los menús, las cargas de archivos, los permisos y en cómo el navegador entrega una tarea a otra aplicación. Una buena prueba de dispositivo mantiene juntos todos estos comportamientos.

BotBrowser usa familias de dispositivos respaldadas por perfiles para este trabajo. Un perfil seleccionado ofrece una base coherente para la pantalla, la entrada, el contenido multimedia, la identidad de plataforma y el comportamiento de la familia de navegador. Los equipos pueden repetir la misma prueba autorizada en una estación de trabajo, en un ejecutor de CI o en un servidor administrado sin reconstruir la descripción del dispositivo a partir de ajustes sueltos.

El punto de partida práctico es el recorrido del cliente: elige un perfil de teléfono para un pago desde el móvil, un perfil de tablet para un panel táctil y un perfil de escritorio para un flujo de estación de trabajo. Registra esa elección junto con el caso de prueba para que quien revise pueda reproducir las mismas condiciones y entender qué representa la evidencia.

El contenido web puede observar características generales del dispositivo y de la sesión del navegador. Por separado, una disposición de pantalla o un modo de entrada pueden parecer corrientes. En conjunto, la pantalla, la interacción, los gráficos, el contenido multimedia, el idioma y el contexto de red pueden facilitar una correlación a largo plazo. Un perfil mantiene alineadas esas familias, de modo que una revisión de privacidad autorizada no exponga una mezcla accidental entre el comportamiento del equipo anfitrión y el del dispositivo objetivo. La coherencia también mejora la calidad de una revisión de diseño: un fallo observado con un perfil de tablet documentado es más fácil de reproducir que uno producido por un conjunto de ajustes temporales del navegador.

La coherencia del perfil no sustituye a la gobernanza. Los equipos deben usar cuentas de prueba aprobadas, destinos autorizados, datos controlados y una política de conservación para capturas y registros. La cobertura de dispositivos debe responder a un propósito de QA por escrito, porque una lista amplia de perfiles resulta menos útil que un conjunto menor vinculado a requisitos reales del producto.

Un perfil de dispositivo resulta más útil cuando quien revisa lo trata como una condición de prueba completa. Las familias de comportamiento relevantes son:

• Pantalla: área útil de la página, densidad visual, orientación, comportamiento a pantalla completa y diseño adaptable.
• Entrada: toque, puntero, teclado, foco, selección, arrastre y controles basados en gestos.
• Formularios: efectos del teclado en pantalla, mensajes de validación, diseño del autocompletado, controles de fecha y hora, y selección de archivos.
• Multimedia: imágenes adaptables, controles de reproducción, solicitudes de permiso de captura y presentación adecuada al dispositivo.
• Identidad de plataforma: contexto de familia de navegador y de sistema operativo presentado como una familia de dispositivo coherente.
• Gráficos y texto: comportamiento de renderizado apropiado para el perfil elegido y para el contenido revisado.
• Contexto regional: idioma, zona horaria y ubicación de red elegidos según el plan de pruebas autorizado.

Usa estas categorías para observar la aplicación: si un control sigue visible, si se puede completar un formulario, si se respeta el consentimiento y si el mismo perfil produce un resultado estable.

Conserva device-profile, journey-id, expected-result y evidence-id con el registro del caso. Para el contrato geométrico del teclado, consulta VirtualKeyboard: límites del viewport y los insets, que separa la política del perfil de la evidencia del viewport visual.

Elegir perfiles y revisar cada familia de dispositivo

Parte de los datos de uso que tu organización puede utilizar. La analítica de producto puede mostrar la proporción general de sesiones en teléfono, tablet y escritorio. Los registros de soporte pueden señalar un flujo móvil que genera problemas repetidos a los clientes. Las pruebas de accesibilidad pueden exigir condiciones tanto táctiles como de teclado. Estas fuentes permiten definir un conjunto compacto y defendible de perfiles, en el que cada perfil tiene una razón de ser.

Evita elegir perfiles solo porque son nuevos o populares. El conjunto adecuado refleja la aplicación, las regiones a las que sirve y los compromisos de soporte que ha asumido el equipo. Revisa el conjunto periódicamente, retira los perfiles que ya no corresponden a un requisito activo y añade uno cuando el uso o un cambio de cara al cliente lo justifique.

Anota por qué cada perfil pertenece al conjunto. Una nota breve como «cubre el pago en pantalla estrecha» o «representa el panel con prioridad táctil» permite que quien revise más adelante decida si el perfil sigue justificando su lugar. Cuando dos perfiles producen siempre los mismos hallazgos, conserva el que se corresponde con más uso real y retira el otro.

Teléfono. La prueba en teléfono debe seguir tareas completas. Una captura de la página de inicio dice poco sobre si un cliente puede iniciar sesión, aceptar una opción de consentimiento, recuperar una cuenta, subir un documento o terminar una compra. Recorre el camino desde la entrada hasta el final con el mismo perfil y presta especial atención a los controles cercanos al borde inferior de la pantalla, a la navegación fija, a los diálogos y a los formularios de varios pasos. Revisa vertical y horizontal solo cuando el producto admita ambas orientaciones.

Los objetivos táctiles necesitan suficiente separación, pero la revisión también debe confirmar el acceso con teclado donde el producto lo prometa. Un perfil de teléfono no es motivo para pasar por alto el orden del foco, las etiquetas, la recuperación de errores ni las preferencias de movimiento reducido. Las revisiones de privacidad y de accesibilidad en móvil suelen revelar los mismos problemas de diseño de fondo: opciones ocultas, estados poco claros o controles que dependen de un único método de entrada.

Tablet. Los diseños de tablet suelen situarse entre las suposiciones del móvil y las del escritorio. Un sitio puede pasar a un diseño de varias columnas mientras la entrada sigue siendo principalmente táctil, y un menú compacto puede convertirse en una barra lateral permanente. Usa perfiles de tablet para paneles, herramientas de inventario, aplicaciones de servicio en campo, productos educativos y experiencias multimedia. Revisa las vistas divididas, los diálogos grandes, las interacciones de arrastre, los teclados virtuales y la rotación, y comprueba que el mayor ancho no deje a la vista controles exclusivos de escritorio difíciles de usar con el tacto. Una prueba de tablet no es una prueba de teléfono ampliada, así que dale sus propias capturas esperadas y sus propias notas de interacción.

Escritorio. Los perfiles de escritorio siguen siendo importantes aunque el tráfico móvil sea mayor. Los flujos de estación de trabajo suelen implicar formularios largos, tareas con varias ventanas, descargas, cargas de archivos, atajos de teclado e información densa. Mantén una base documentada para comparar, porque un tamaño de ventana aleatorio en cada ejecución dificulta interpretar los cambios entre capturas. La revisión de escritorio también sirve de control para los hallazgos móviles: si un diálogo de consentimiento falla solo con un perfil de teléfono, el equipo tiene un ámbito más reducido que investigar, y si falla en todas las familias, el problema puede estar en la lógica compartida de la aplicación.

Registra profile-rationale, coverage-family, review-date y retire-decision para cada perfil seleccionado.

Formularios, teclado en pantalla y entrada táctil

Los formularios merecen una revisión móvil específica porque el foco puede cambiar el área visible de la página. Prueba el inicio de sesión, la introducción de direcciones, el pago, la búsqueda, la recuperación de cuentas y cualquier editor personalizado con el perfil de teléfono o tablet elegido. El campo con foco, su etiqueta, el mensaje de validación y la siguiente acción deben seguir siendo comprensibles.

No juzgues un formulario solo por el primer evento de foco. Recorre la secuencia completa de foco, error y pérdida de foco, corrige un error, abre y cierra un diálogo y vuelve a la página. Confirma que el desplazamiento sigue siendo predecible y que la página recupera una posición útil cuando se cierra el teclado. Estas comprobaciones protegen a las personas usuarias reales y generan evidencia que otra persona puede reproducir.

La diferencia entre el viewport de diseño y el viewport visual explica por qué el comportamiento del teclado necesita su propia comprobación. MDN describe el viewport visual como la parte visible de la página, sin los teclados en pantalla ni otros elementos que no escalan con la página. Cuando se abre un teclado, el área visible puede reducirse mientras el diseño en el que se apoyan CSS y el posicionamiento fijo permanece sin cambios. Un pie de página fijo dimensionado a partir del diseño puede dejar una acción principal bajo el teclado, mientras que una página que responde a los cambios del área visible puede mantener esa acción al alcance. Para un modelo de revisión más completo que cubre los estados del viewport y los recorridos con teclado y toque, consulta Revisión de calidad de perfiles móviles.

Escribe el resultado esperado de una revisión del teclado en términos observables. En un formulario de inicio de sesión, el campo con foco permanece dentro del área visible, el mensaje de validación aparece junto al campo y no queda oculto tras el teclado, la acción de envío se puede alcanzar sin salir de la página y la pérdida de foco devuelve la página a una posición razonable. Guarda estos resultados como una lista breve dentro del caso de prueba y ejecútalos con el perfil elegido para ese caso, de modo que otra persona pueda repetir la secuencia y comparar el resultado.

Para el comportamiento móvil con teclado, usa la configuración documentada del producto en lugar de superponer un viewport del framework al perfil. El perfil debe seguir siendo el responsable de la condición del dispositivo durante toda la prueba, y el framework de automatización solo debe seguir el recorrido aprobado.

La revisión de la entrada debe centrarse en los resultados para la persona usuaria. Confirma que los toques activan el control previsto, que el desplazamiento no dispara una acción contigua, que los tiradores de arrastre siguen siendo utilizables y que los menús se pueden cerrar. Cuando un flujo admita puntero o teclado físico, prueba esa condición por separado y conserva su propia evidencia. Para saber cómo se comportan los eventos de ratón, pantalla táctil y lápiz y cómo mantener accesible cada vía, consulta Pointer Events y accesibilidad con ratón, pantalla táctil y lápiz.

La revisión manual sigue teniendo valor. Las comprobaciones automáticas pueden confirmar que un control existe y que una tarea se completa, mientras que una persona revisora puede notar que un menú resulta apretado, que la explicación de un permiso no es clara o que una opción de privacidad se vuelve difícil de alcanzar tras girar el dispositivo. Los perfiles de dispositivo no sustituyen a las pruebas de accesibilidad, que siguen necesitando comprobaciones semánticas, cobertura con teclado y lector de pantalla, revisión de contraste, gestión del foco y personas evaluadoras cualificadas.

Captura focus-target, visualViewport.height, validation-state y return-position para la secuencia del formulario.

Orientación, multimedia, permisos y contexto regional

Prueba los cambios de orientación solo donde se espera que las personas giren el dispositivo. El contenido multimedia, la revisión de documentos, los mapas, los gráficos y algunas herramientas de tablet suelen necesitar ambas orientaciones, mientras que un pago oficialmente solo vertical quizá no. Cuando la orientación esté dentro del alcance, verifica la continuidad: la página debe conservar un estado significativo, mantener visible la tarea activa, evitar reabrir diálogos descartados y conservar los datos introducidos en el formulario. Para ver cómo funciona la rotación como estado de diseño y cómo mantener intacta la tarea durante el giro, consulta Screen Orientation API y experiencias adaptables.

Captura evidencia antes y después del cambio con el mismo perfil. No combines una revisión de orientación con un cambio no relacionado de idioma, región de red o estado de la cuenta. Un solo cambio controlado hace que el resultado sea más fácil de entender.

La cámara, el micrófono, la ubicación, las notificaciones y el acceso a archivos implican tanto la presentación del navegador como el consentimiento de la aplicación. Prueba estos caminos solo con cuentas autorizadas y datos de prueba aprobados. La aplicación debe explicar por qué solicita el acceso, gestionar la denegación sin atrapar a la persona usuaria y permitir cambiar de decisión más adelante cuando el producto lo admita. En el contenido multimedia, confirma que la vista previa, el silencio, la cancelación y la recuperación de errores se comportan como se espera.

Los resultados de los permisos pueden persistir en un directorio de datos del navegador, así que define una política deliberada de estado de prueba. Un estado limpio sirve para el consentimiento de la primera ejecución, y un estado conservado sirve para las visitas posteriores. Etiqueta la evidencia para que otra persona sepa qué condición se probó.

La familia de dispositivo es solo una parte de la experiencia móvil. El idioma, la zona horaria y la región de red pueden cambiar el contenido, el formato, las obligaciones de consentimiento y las vías de soporte. Elige estos valores a partir del plan de pruebas autorizado y mantenlos coherentes con el escenario. Un perfil de teléfono no exige un tipo de red concreto, pero la ruta debe estar aprobada, documentada y ser lo bastante estable para que el resultado pueda revisarse. Mantén las credenciales fuera de las capturas y de los registros compartidos.

Ejecuta las variaciones regionales como casos separados. No mezcles sin cuidado un cambio de idioma con otra cuenta, otro perfil y otra ruta de red. Unos límites de caso claros facilitan reproducir los fallos y reducen la recopilación innecesaria de datos de las personas usuarias.

Nombra las entradas controladas como orientation-change, permission-state, locale y network-route.

Evidencia, matrices de publicación y CI

La evidencia útil conecta la condición del dispositivo con el comportamiento observado en la aplicación. Registra la familia del perfil, la versión del navegador, la versión de la aplicación, la clase de cuenta de prueba, la configuración regional, la orientación y el recorrido intentado. Captura la imagen o grabación más pequeña que explique el resultado y oculta los datos personales antes de compartirla.

Los registros deben seguir la misma contención. La salida de la consola de la aplicación, las trazas de red y los diagnósticos del navegador pueden contener identificadores o datos de cuentas. Recopila solo lo que exige la investigación, guárdalo según la política de conservación del equipo y limita el acceso. Nombra con claridad las bases esperadas para que quien revise sepa si una captura pertenece a un pago en teléfono, a un panel de tablet o a un flujo de soporte en escritorio sin abrir otra hoja de cálculo.

Un registro de caso que sobrevive a los cambios de personal enumera el recorrido, la familia de perfil, el resultado observable esperado, la clase de datos de prueba, la persona responsable y la fecha de la próxima revisión. Guarda el registro junto a la propia prueba y no en un documento aparte, para que una captura modificada lleve siempre a la persona y al requisito que hay detrás.

Las matrices grandes suelen volverse lentas e ignoradas. Separa una pequeña puerta de publicación de una cobertura programada más amplia: la puerta contiene las familias de dispositivos y los recorridos cuyo fallo bloquearía la entrega, y las ejecuciones programadas cubren más diseños, idiomas y flujos menos frecuentes. Asigna un responsable a cada caso y mantén la cuarentena temporal y visible. Si un caso de dispositivo es inestable, registra el motivo, conserva un caso de diagnóstico más pequeño y fija una fecha de revisión, en lugar de aceptar en silencio capturas cambiantes o reintentos repetidos.

Los ejecutores de CI necesitan el mismo perfil, la misma versión del navegador, las mismas fuentes y recursos de apoyo y el mismo estado de aplicación que la base aprobada. Empaqueta estas entradas con los controles habituales de secretos y artefactos de la organización, y no descargues un perfil distinto en cada ejecución salvo que la prueba cubra expresamente la rotación de perfiles. Evita que los ajustes de pantalla del framework sustituyan la condición de dispositivo respaldada por el perfil y usa instancias de navegador separadas para identidades de dispositivo distintas, de modo que el estado de almacenamiento y los fallos sigan atribuyéndose al perfil previsto.

La planificación de capacidad debe basarse en mediciones sobre tus propias páginas. Un panel con mucho contenido multimedia y un formulario sencillo tienen costes distintos de memoria, gráficos y red. Empieza con un conjunto pequeño de ejecuciones simultáneas, observa el tiempo de finalización y el margen de recursos y luego elige un límite para esa carga de trabajo.

Las actualizaciones del navegador, del perfil, del framework de automatización y de la aplicación pueden afectar cada una a una prueba de dispositivo. Cambia una capa cada vez cuando sea posible, ejecuta la puerta de publicación antes de ampliar a la matriz programada y compara con una base generada por la misma familia de perfil. Tras una actualización, revisa el consentimiento, los permisos, la recuperación de cuentas, las cargas de archivos y el pago, y conserva la evidencia antigua solo mientras lo justifiquen la política y el valor de ingeniería.

Cada fila de la matriz identifica browser-build, profile-revision, app-build y matrix-case.

Cuándo sigue siendo mejor el hardware físico

Las pruebas de escritorio respaldadas por perfiles no eliminan la necesidad de dispositivos físicos. Usa hardware cuando los criterios de aceptación dependan de una cámara real, de la radio, de un sensor biométrico, de un diálogo del sistema operativo, del traspaso a otra aplicación, del comportamiento de hardware específico de un fabricante o del rendimiento bajo condiciones reales de batería y temperatura. El hardware también es apropiado para una certificación final cuando un contrato o una política de plataforma lo exijan.

Una regla de escalado útil es sencilla: si el resultado esperado depende de un equipo físico o de un servicio del sistema operativo ajeno al navegador, confírmalo en el dispositivo objetivo. Si se refiere a la presentación en el navegador y a un flujo compatible respaldado por perfil, la ejecución en escritorio o en servidor puede aportar la evidencia repetible que necesita el equipo, y el escaso tiempo del laboratorio de dispositivos se dedica a las condiciones que de verdad requieren hardware.

BotBrowser puede ejecutar perfiles móviles Android o de la familia WebKit coincidentes, con compatibilidad táctil definida por el perfil. Con la opción documentada --bot-mobile-keyboard, el foco de confianza en un campo editable reduce visualViewport.height sin cambiar el viewport de diseño, de modo que un equipo puede repetir una revisión móvil de formularios y teclado a partir de una condición de perfil documentada. Los perfiles de escritorio ignoran esa opción. BotBrowser no puede sustituir a los dispositivos físicos, a los teclados reales del sistema operativo, a los diálogos ni al comportamiento del hardware, y no garantiza que todos los dispositivos o diseños de aplicación se comporten de forma idéntica.

Elige pruebas de dispositivo respaldadas por perfiles cuando el equipo necesite QA de navegador repetible en familias de móvil, tablet y escritorio, sobre todo en CI o en infraestructura administrada. Elige un servicio de dispositivos físicos cuando la aceptación dependa de hardware real, y una emulación adaptable estándar cuando la tarea sea un borrador temprano de diseño y la identidad del dispositivo quede fuera del alcance. Antes de ampliar el despliegue, confirma quién es responsable de cada perfil, el uso aprobado, el tratamiento de los datos de prueba, la conservación de la evidencia, la capacidad de los ejecutores y la vía de escalado. Estas decisiones importan más que el número de nombres de dispositivos de un catálogo.

Descarga BotBrowser para ejecutar perfiles de dispositivo aprobados o consulta las funciones de coherencia de plataforma antes de definir un despliegue. Para la planificación móvil, consulta las pruebas de perfiles de navegador Android. La coherencia de pantalla y ventana trata la revisión del diseño adaptable, y los perfiles de navegador multiplataforma tratan las opciones de despliegue en el anfitrión.

Conclusión práctica

Elige el conjunto más pequeño de perfiles aprobados que cubra recorridos nombrados, conserva juntos el perfil y la evidencia de publicación, y trata el hardware físico como la escalada necesaria cuando el criterio de aceptación dependa de hardware o de un servicio del sistema operativo.

Fuentes

• Documentación de emulación de dispositivos de BotBrowser
• MDN: VisualViewport