Contacto y ayuda
Las pruebas reproducibles empiezan con un entorno de prueba documentado de forma limpia. En los sistemas Windows, indicar «Windows 11» en un informe de errores normalmente no basta. La versión del build, el modo de firmware, las funciones de seguridad, el controlador gráfico y el hardware pueden influir en si se produce un error y si este es reproducible en un segundo equipo. Esta guía muestra cómo recopilar los datos técnicos más importantes de un equipo de prueba Windows utilizando únicamente herramientas integradas, sin software de diagnóstico adicional.
¿Qué información debe incluirse en la documentación de un equipo de prueba Windows?
Para muchos escenarios de QA y soporte, seis grupos de información son especialmente relevantes: sistema operativo y build, procesador y memoria, modo de firmware, estado del TPM, estado del Secure Boot, así como datos gráficos y de controladores. Según la aplicación, se añaden la resolución de pantalla, la capacidad de almacenamiento disponible, el idioma, la zona horaria y los componentes de runtime instalados.
El objetivo no es recopilar la mayor cantidad de datos posible. La meta es una huella de sistema pequeña y coherente, obtenida de la misma manera en cada equipo de prueba. Esto permite detectar mucho más rápido las diferencias entre un entorno que funciona y uno defectuoso.
1. Registrar la versión y el build de Windows con winver
Pulse tecla de Windows + R, escriba winver y confirme. La ventana muestra la versión de Windows instalada y el build del sistema operativo. Ambos valores deben incluirse en un informe de errores.
La edición por sí sola es demasiado imprecisa. Dos equipos pueden tener ambos Windows 11 pero builds o niveles de parches diferentes. Por eso, un comportamiento que aparece tras una actualización solo puede investigarse de forma útil si el build está documentado.
Aun así, anote siempre también la edición. Que un equipo de prueba funcione con Windows 11 Home, Windows 11 Pro o Windows 11 Enterprise determina si funciones como BitLocker, las directivas de grupo o Hyper-V están siquiera disponibles, lo que también afecta al comportamiento durante las pruebas.
2. Consultar los datos centrales del sistema con msinfo32
Abra el comando msinfo32 mediante tecla de Windows + R. La información del sistema reúne muchos datos útiles para las pruebas y el análisis de errores. Son especialmente relevantes:
- Nombre y versión del sistema operativo
- Fabricante y modelo del sistema
- Tipo de sistema
- Procesador
- Memoria física instalada
- Versión y fecha del BIOS
- Modo del BIOS
- Estado del «inicio seguro» o Secure Boot
Para procesos de QA reproducibles, conviene mantener estos campos en una plantilla fija. Así se evitan informes de errores en los que un evaluador documenta la versión del BIOS y otro solo la edición de Windows.
3. Comprobar UEFI y Secure Boot
En msinfo32, el campo relativo al modo del BIOS muestra si el equipo se inició en modo UEFI o en un modo Legacy más antiguo. El campo relativo al inicio seguro muestra si el Secure Boot está activo. Microsoft indica la compatibilidad con UEFI y Secure Boot como parte de los requisitos del sistema de Windows 11.
Para la búsqueda de errores, esta información es útil incluso cuando la aplicación probada no utiliza directamente el Secure Boot. Las diferencias en la configuración del firmware y en el estado de seguridad pueden explicar por qué el comportamiento de instalación, controladores o dispositivos difiere entre dos equipos por lo demás equipados de forma similar.
No cambie la configuración del firmware solo para una prueba sin comprender las consecuencias. Si es necesario un cambio, documente el estado antes y después del ajuste y siga las instrucciones del fabricante del dispositivo o de la placa base.
4. Comprobar la versión del TPM con tpm.msc
Pulse tecla de Windows + R, escriba tpm.msc y abra la administración del TPM. Si el Módulo de plataforma segura (Trusted Platform Module) está disponible y operativo, encontrará allí la información del fabricante y la versión de la especificación. Para Windows 11, TPM 2.0 es un requisito mínimo.
Si Windows no muestra ningún TPM compatible, eso no significa necesariamente que falte el hardware. Microsoft señala que, en algunos equipos, el TPM puede estar desactivado en el firmware UEFI. Según la plataforma, puede aparecer con denominaciones como Intel PTT o AMD fTPM.
Para la documentación de pruebas suelen bastar tres valores: TPM presente: sí/no, versión de la especificación y estado. Las claves sensibles o los datos de identidad no deben incluirse en un informe de errores normal.
5. Documentar DirectX y el controlador gráfico con dxdiag
Abra el comando dxdiag mediante tecla de Windows + R. La herramienta de diagnóstico de DirectX muestra, además de datos del sistema, información sobre la unidad gráfica y el controlador. En la pestaña Pantalla se ven, entre otros datos, el nombre de la GPU, la versión del controlador, la fecha del controlador, la compatibilidad con DirectX y el modo de pantalla.
Estos datos son especialmente importantes en errores de representación, bloqueos relacionados con la aceleración por hardware, problemas con varios monitores o diferencias entre equipos de prueba virtuales y físicos. Microsoft indica para Windows 11 una unidad gráfica compatible con DirectX 12 y controlador WDDM 2.0 como requisito mínimo.
6. Registrar la CPU, la RAM y el tipo de sistema de forma uniforme
El procesador, la RAM instalada y el tipo de sistema también se encuentran en msinfo32 o en Configuración → Sistema → Acerca de. Al registrar la CPU, anote a ser posible la denominación exacta del modelo en lugar de solo «Intel» o «AMD». En cuanto a la memoria, la capacidad instalada es suficiente siempre que no se investigue un problema de memoria.
Para pruebas de rendimiento o de carga conviene registrar además si se están ejecutando en paralelo otros procesos que consumen muchos recursos. Un resultado de prueba sin contexto sobre el uso del hardware puede interpretarse fácilmente de forma errónea.
7. Comprobar el espacio de almacenamiento libre
Un equipo puede cumplir los requisitos formales de Windows y aun así tener demasiado poco espacio libre para una actualización, datos de prueba temporales o una aplicación de mayor tamaño. Por ello, en errores de instalación o actualización documente no solo el tamaño de la unidad, sino también el espacio libre disponible antes de la prueba.
Según Microsoft, Windows 11 requiere una unidad de almacenamiento de al menos 64 GB. Sin embargo, para pruebas de aplicaciones reproducibles, el indicador más significativo es el espacio libre realmente disponible.
Huella de sistema recomendada para informes de errores
Una plantilla compacta puede tener, por ejemplo, este aspecto:
SO: Windows 11 [Edición]
Versión/Build: [winver]
Modelo del equipo: [msinfo32]
CPU: [modelo exacto]
RAM: [GB]
Modo BIOS: UEFI/Legacy
Secure Boot: Activado/Desactivado/No compatible
TPM: presente, versión [x.x]
GPU: [modelo]
Controlador gráfico: [versión + fecha]
DirectX/WDDM: [dxdiag]
Pantalla: [resolución / escalado]
Espacio libre: [GB]
Fecha/hora de la prueba: [fecha/hora]Al comparar dos equipos, debe utilizarse la misma plantilla para ambos sistemas. Así las diferencias se hacen visibles de inmediato, sin que los desarrolladores tengan que revisar varias capturas de pantalla.
¿Qué datos no deben incluirse en informes de errores públicos?
El diagnóstico del sistema puede contener información que no es necesaria para el análisis técnico. Por ello, no publique números de serie, claves de producto, datos de cuenta, identificadores de dispositivo, datos de red privados ni otra información personal o confidencial. Revise los informes de diagnóstico exportados antes de compartirlos.
En las empresas se aplican además políticas internas para registros y datos de telemetría. Una buena huella de sistema contiene solo los datos que contribuyen a reproducir el error.
Por qué esta documentación mejora la reproducibilidad
Un error que aparece solo en un único equipo de prueba no es automáticamente aleatorio. A menudo el entorno difiere en un detalle: otro build de Windows, otro controlador gráfico, una configuración de firmware distinta, menos espacio libre u otro hardware. Si estas diferencias se registran de forma estructurada, un «a mí me funciona» puede convertirse en una hipótesis comprobable.
Este método resulta especialmente valioso en las pruebas de regresión. Guarde la huella de sistema junto con la ejecución de la prueba. Si el resultado cambia tras una actualización de Windows, del firmware o de un controlador, se puede rastrear qué variable de entorno cambió entre las ejecuciones.
Conclusión
Una documentación de pruebas de Windows sólida no requiere numerosas herramientas de terceros. Con winver, msinfo32, tpm.msc y dxdiag se pueden registrar de forma coherente las características de sistema más importantes. Lo decisivo no es la cantidad de datos, sino una plantilla repetible que se utilice de forma idéntica en todos los equipos de prueba.
