Pruebas de sistemas digitales y confirmación de su preparación para el uso

Un equipo puede arrancar con normalidad y aun así fallar en la primera tarea que necesita su usuario. Las pruebas someten un sistema configurado a acciones conocidas y después comparan lo que ocurre con lo que debería ocurrir. El sistema puede ser un equipo portátil, una impresora, una configuración de cuentas o una aplicación utilizada por un equipo de trabajo.

Pruebas y aseguramiento de la calidad

El aseguramiento de la calidad (QA) mejora la forma de trabajar para prevenir problemas. Una lista de comprobación de configuración estándar, una línea base de seguridad acordada y una revisión del plan de pruebas son actividades de aseguramiento de la calidad. Las pruebas examinan el sistema concreto producido por ese proceso. Son control de calidad: encuentran defectos y aportan evidencias para decidir sobre la preparación.

Las pruebas ayudan a prevenir la pérdida de trabajo, las tareas bloqueadas y los incidentes de seguridad. También dan a la persona responsable una base para aceptar el sistema. Una carpeta que se abre para el técnico, pero rechaza la cuenta del usuario, es un problema que debe encontrarse antes del primer turno del usuario.

Sigue un problema desde el error hasta el fallo

Estos términos describen distintas partes de una misma historia:

Una prueba puede revelar el fallo. Después, el diagnóstico sigue el método de diagnóstico y resolución de problemas para establecer su causa; el resultado de la prueba por sí solo no demuestra qué ajuste es incorrecto.

La verificación comprueba la especificación: ¿se configuró el sistema según lo exigido? La validación comprueba la necesidad: ¿pueden las personas realizar su trabajo real? Un equipo portátil puede cumplir su lista de comprobación de configuración y aun así carecer de una aplicación que necesita el usuario. Por eso, tanto las tareas de los usuarios como las políticas del lugar de trabajo ayudan a definir las pruebas.

Elige el nivel y el tipo

El nivel de una prueba describe qué se examina. Los desarrolladores prueban componentes individuales de software y su integración. Los técnicos de soporte prueban principalmente el sistema configurado completo. Las pruebas de integración de sistemas comprueban las conexiones con otros sistemas, como el almacenamiento en la nube o el correo electrónico. Las pruebas de aceptación permiten a los usuarios o responsables comprobar la idoneidad para el uso.

El tipo de una prueba describe la cualidad examinada. Las pruebas funcionales comprueban qué hace el sistema. Las no funcionales comprueban el rendimiento, la usabilidad, la accesibilidad, la seguridad, la fiabilidad y la compatibilidad. Son dimensiones distintas: una prueba de aceptación puede examinar tanto el rendimiento como la funcionalidad.

Las pruebas de caja negra, o caja cerrada, parten de los requisitos sin examinar la estructura interna. Las de caja blanca, o caja abierta, utilizan el conocimiento del código o de la lógica de configuración. La mayoría de las comprobaciones de tareas de soporte son pruebas de caja negra.

Las pruebas no pueden abarcar todas las combinaciones posibles de cuentas, entradas y condiciones. Prioriza las áreas donde un fallo sea probable o perjudicial y prueba con tiempo suficiente para corregir los problemas antes de que los usuarios dependan del sistema. Una ejecución sin incidencias establece que esas pruebas no encontraron defectos. No demuestra que el sistema no tenga ninguno. Incluye los requisitos de las políticas de seguridad, accesibilidad y protección de datos, aunque quien haya hecho la solicitud no los haya mencionado.

Las solicitudes suelen mezclar una tarea, una solución preferida y una expectativa imprecisa. Antes de probar, separa esas ideas y acuerda cómo se reconocerá el éxito. Un requisito claro permite que dos personas que realicen pruebas lleguen a la misma decisión de prueba superada o fallida.

Empieza por la tarea del usuario

Un requisito de usuario expresa una necesidad en lenguaje cotidiano: «Necesito escanear facturas en la carpeta de finanzas». Los requisitos del sistema relacionados identifican qué debe permitir esa tarea: un controlador de escáner adecuado, ajustes de escaneo a carpeta, permiso de escritura y acceso al servidor de archivos.

Un requisito funcional indica qué hace el sistema, como imprimir en una impresora asignada. Un requisito no funcional indica cómo de bien funciona o qué restricciones se aplican, como un límite de tiempo de inicio de sesión o acceso restringido a los registros de finanzas. Ambos necesitan evidencias.

«Instalar este navegador» puede ser una solución propuesta para «Abrir el portal del proveedor». Instalar el navegador verifica una acción. Completar la tarea en el portal valida la necesidad del usuario.

Haz que el éxito sea observable

Un criterio de éxito, también llamado criterio de aceptación, establece una condición clara para superar la prueba. Sustituye «rápido», «fácil» o «seguro» por una medición acordada o un resultado visible. Especifica la acción, las condiciones, el umbral y la unidad cuando corresponda.

Para un PC de recepción, «rápido y seguro» puede convertirse en:

1. Desde el encendido hasta disponer de un escritorio utilizable transcurren como máximo 60 segundos en cada una de tres pruebas.
2. La aplicación de reservas se abre en un máximo de 5 segundos.
3. La pantalla se bloquea tras 5 minutos sin interacción.
4. La persona de recepción utiliza una cuenta estándar y no puede instalar programas que requieran derechos de administrador.
5. El disco del sistema está cifrado.

Los límites de tiempo son requisitos acordados, no normas universales para todos los equipos. Pide a quien hizo la solicitud que los confirme antes de las pruebas. De lo contrario, quien realiza las pruebas puede elegir un umbral fácil después de ver los resultados.

Encuentra los requisitos menos visibles

Pregunta quién utilizará el sistema, qué tareas importan, qué dispositivos y aplicaciones utiliza, y qué ajustes de accesibilidad o tecnologías de apoyo necesita. Añade los requisitos establecidos por las políticas. Una tarea de inicio de sesión puede depender de la red, de un servicio de identidad y de MFA; una aplicación puede necesitar un sistema operativo concreto, una conexión a una base de datos o un servidor de licencias.

La compatibilidad significa que esas combinaciones necesarias funcionan juntas. Si el personal utiliza dos navegadores, probar solo uno deja parte del requisito sin comprobar. Registra las dependencias para que el entorno de pruebas pueda incluirlas.

Relaciona las prioridades con las pruebas

Las prioridades MoSCoW distinguen entre imprescindible, importante, opcional y descartado por ahora. Un requisito imprescindible incumplido normalmente impide considerar preparado el sistema. Un requisito opcional incumplido puede convertirse en un problema conocido aceptado. La prioridad ayuda a elegir el orden y la profundidad de las pruebas, pero no convierte un resultado fallido en uno satisfactorio.

Crea una tabla de trazabilidad con el identificador del requisito, el criterio de éxito, los identificadores de los casos de prueba y el resultado. Una fila sin prueba revela un hueco de cobertura. Cuando cambie un requisito, actualiza sus pruebas y la tabla a la vez. Los requisitos comprobables se confirman con quien hizo la solicitud; no son simplemente las tareas que resultan más fáciles de comprobar.

Un entorno de pruebas te ofrece un lugar donde cambiar ajustes, repetir acciones y restablecer datos sin interrumpir el trabajo real. También debe parecerse lo suficiente al sistema de destino para que los resultados aporten información útil.

Adapta el entorno a la finalidad

El entorno de producción contiene trabajo real y datos reales. Los entornos ajenos a producción responden a distintas necesidades:

Una máquina virtual puede ejecutar un sistema operativo de prueba en un equipo físico existente. Una instantánea captura su estado antes de un cambio. Volver a ella permite que un compañero repita la prueba desde el mismo punto de partida. Registra ese estado inicial: una prueba que depende de un cambio anterior desconocido es difícil de reproducir.

Haz que los resultados sean representativos

Compara la configuración de pruebas con los dispositivos previstos. Comprueba la versión y compilación del sistema operativo, las aplicaciones, las políticas, la capacidad del hardware, el acceso de red y los permisos. Una aplicación que funciona bien con 32 GB de memoria puede ser lenta en el equipo portátil del usuario con 8 GB. Una cuenta de prueba con derechos de administrador puede ocultar un problema de acceso de un usuario estándar.

La representatividad depende de lo que se pretenda comprobar. Una máquina virtual puede comprobar muchos ajustes, pero un resultado sobre una impresora física o un equipo portátil concreto sigue necesitando el dispositivo correspondiente. Anota las diferencias entre los entornos de pruebas y de producción para que el informe de preparación pueda explicar qué queda sin confirmar.

Prepara las cuentas, los datos y una forma de restablecer el estado

Utiliza datos sintéticos, como clientes ficticios y facturas de ejemplo, o datos debidamente anonimizados. Cuando sean necesarios datos personales reales, sigue la política: usa los mínimos, restringe el acceso y elimínalos al terminar las pruebas. Los datos de formación deben ser lo bastante realistas para realizar la tarea sin exponer los registros de un cliente.

Mantén claramente etiquetados los dispositivos, las cuentas y los servidores de prueba. Comprueba el destino del guion de comandos antes de cada ejecución. Una prueba bien escrita puede causar daños si envía mensajes a clientes reales o elimina datos de un servidor de producción. Separar las credenciales y los destinos de prueba ayuda a prevenir ese error.

Confirma los criterios de entrada antes de empezar: la configuración prevista está instalada, las cuentas y los dispositivos están disponibles, los datos de prueba están cargados, las herramientas funcionan y se ha registrado la línea base de rendimiento. Guarda el modelo del dispositivo, la compilación del sistema operativo, las versiones de las aplicaciones y los detalles de la red junto con los resultados. Estos datos explican las condiciones en las que se superó una prueba.

Algunas comprobaciones finales deben ejecutarse en el sistema real que se entrega. Acuerda una ventana de tiempo, conserva una copia de seguridad o un método para deshacer los cambios cuando los haya y da preferencia a las comprobaciones de solo lectura. Una comprobación final del dispositivo confirma el estado entregado; no convierte un equipo de producción en un lugar seguro para experimentos que puedan interrumpir el trabajo.

Un plan de pruebas convierte un conjunto de comprobaciones en un trabajo acordado. Establece la finalidad, los límites y las responsabilidades antes de conocer los resultados, para que las pruebas no dependan de quien esté disponible ese día.

Indica qué incluye el trabajo

Especifica el objetivo, los dispositivos, las cuentas, las aplicaciones y las conexiones que se probarán. Enumera qué se incluye en el alcance y qué queda fuera. Incluye los tipos de prueba, el entorno, los datos, las herramientas, las personas, el calendario, los riesgos y el método para comunicar los resultados. Quien hizo la solicitud debe poder ver cómo responde el plan a los requisitos.

Una tabla práctica del plan puede identificar cada prueba, su finalidad, los datos, el resultado esperado y un espacio para el resultado real. Las instrucciones detalladas y repetibles corresponden a los casos de prueba vinculados. El plan coordina toda la actividad; un caso de prueba describe una comprobación.

Acuerda cuándo empezar y terminar

Los criterios de entrada indican qué debe estar preparado antes de comenzar las pruebas. Para un lote de equipos portátiles, podrían exigir la configuración estándar y las cuentas de prueba en los 12 dispositivos.

Los criterios de salida indican qué condiciones deben cumplirse para considerar terminadas las pruebas. Un ejemplo es: «Todas las pruebas previstas ejecutadas, todos los requisitos imprescindibles cumplidos y ningún defecto abierto de gravedad crítica o alta». Permiten que la persona responsable valore los resultados de forma coherente. Una fecha límite es una restricción del calendario, no una evidencia de que se cumplieron esas condiciones.

Las pruebas bloqueadas y no ejecutadas siguen siendo visibles al revisar los criterios de salida. Si un servicio necesario no está disponible, anota la carencia y su efecto en la decisión. No marques el requisito como cumplido porque al técnico se le haya acabado el tiempo.

Dedica el esfuerzo donde los fallos importan

Las pruebas basadas en riesgos prestan más atención a los fallos probables o perjudiciales. El inicio de sesión, el acceso a datos empresariales, la aplicación principal y los ajustes de seguridad suelen merecer comprobaciones tempranas. Un error en el fondo de escritorio puede recibir una comprobación breve porque su impacto es diferente.

Para 12 equipos portátiles de ventas, un plan podría incluir inicio de sesión, correo electrónico, base de datos de clientes, VPN, impresión, un recurso compartido del equipo, cifrado, actualizaciones y ampliación para un usuario con baja visión. El código interno de la base de datos queda fuera de esta prueba de soporte. Empieza en una red de pruebas separada y después realiza las comprobaciones finales con las cuentas correctas.

Si las configuraciones son idénticas, prueba dos dispositivos en profundidad y utiliza una lista de comprobación de preparación en los 12. Probar en una muestra el comportamiento común ahorra tiempo, pero los aspectos propios de cada dispositivo siguen necesitando comprobaciones individuales. El estado del cifrado, las actualizaciones, el estado de salud de la batería y la cuenta del usuario pueden diferir entre equipos portátiles idénticos en lo demás. Los criterios de salida que exigen los requisitos imprescindibles en los 12 siguen aplicándose a los 12.

Mantén el plan vinculado a los cambios

Asigna funciones claras: quién prepara las cuentas, ejecuta los casos, registra los defectos y acepta el sistema. Reserva tiempo para las correcciones y la repetición de pruebas. Identifica riesgos, como equipos de prueba no disponibles o una dependencia inaccesible, y acuerda cómo gestionarlos.

Cuando quien hizo la solicitud cambie un requisito, revisa a la vez su criterio de éxito, sus casos de prueba, el calendario y su fila de trazabilidad. Mantener el plan antiguo crea una diferencia entre el sistema que las personas esperan y el que realmente describen las evidencias.

Un compañero debe poder ejecutar un caso de prueba a partir de sus instrucciones escritas y obtener un resultado comparable. Eso requiere un estado inicial conocido, acciones claras y un resultado esperado elegido antes de ejecutar la prueba.

Redacta una comprobación repetible

Incluye un identificador y un título, el requisito vinculado, las precondiciones, los pasos numerados, los datos de prueba y el resultado esperado. Durante la ejecución, añade el resultado observado, el estado, quién realiza la prueba y la fecha. «Funciona» es demasiado impreciso. «La cuenta figura como bloqueada y se rechaza una contraseña correcta hasta el desbloqueo» describe un comportamiento observable.

Las precondiciones evitan que las pruebas anteriores cambien el significado de las posteriores. Una prueba de bloqueo no puede contar cinco fallos de forma fiable si la cuenta ya tiene tres intentos fallidos registrados.

Recorre el bloqueo de cuenta

Para un requisito de bloqueo tras cinco inicios de sesión fallidos, establece el umbral en cinco. Empieza con una cuenta de prueba activa y desbloqueada cuyo contador de intentos fallidos esté a cero. Completa estos pasos sin una pausa lo bastante larga para restablecer el contador:

1. Introduce una contraseña incorrecta cuatro veces.
2. Comprueba que la cuenta siga activa.
3. Introduce una contraseña incorrecta por quinta vez.
4. Prueba la contraseña correcta.

El resultado esperado tras cuatro fallos es que no haya bloqueo. El quinto provoca el bloqueo y la contraseña correcta se rechaza hasta que un administrador desbloquee la cuenta o termine su período de bloqueo. Restablece la cuenta antes de otra ejecución para que coincidan las condiciones iniciales.

Elige datos que puedan revelar un error

Las pruebas positivas comprueban acciones permitidas y entradas aceptables. Las negativas comprueban que las acciones prohibidas y las entradas inaceptables se rechacen de forma segura. Una prueba negativa se supera cuando se produce el rechazo exigido; «rechazado» no significa automáticamente «fallido».

Algunos cursos agrupan los datos no válidos y los erróneos. Lo importante en un plan de pruebas es que los casos elegidos comprueben tanto el incumplimiento de reglas como las entradas inadecuadas.

Un mínimo de 12 incluye exactamente 12. Probar solo 11 y 15 podría dejar sin detectar un defecto que exigiera incorrectamente más de 12. En el extremo superior, deben aceptarse 64 y rechazarse 65. Indica las demás condiciones de la contraseña para que la comprobación de longitud no se confunda con otra regla.

Comprueba si un resultado tiene sentido

Los resultados inesperadamente buenos también necesitan comprobarse. Un archivo de 2 GB contiene 16 gigabits, así que un enlace de 1 Gbit/s necesita al menos 16 segundos para transportarlo, sin contar la sobrecarga. Una copia que figure como realizada en 0,1 segundos sugiere que la medición no representó esa transferencia por la red. Conserva la observación, revisa el método y consulta a un especialista en la materia cuando sea necesario. Actualiza los casos cuando cambien los requisitos y las configuraciones; repetir únicamente el camino feliz acaba dejando de revelar problemas nuevos.

Las pruebas consumen electricidad, equipos y tiempo del personal. Unas pruebas eficientes mantienen el nivel de confianza exigido y evitan recursos inactivos, reconstrucciones innecesarias y trabajo repetido que no aporta evidencias.

Calcula la energía a partir de la potencia y el tiempo

La potencia es la tasa de consumo de energía. Convierte los vatios en kilovatios y después multiplica por las horas de funcionamiento:

Un servidor que consume 120 W utiliza 0,12 kW. Funcionar de forma continua durante 30 días supone 720 horas y consume 86,4 kWh. Funcionar solo durante diez jornadas de pruebas de 8 horas supone 80 horas y consume 9,6 kWh. La diferencia es de 76,8 kWh, un ahorro aproximado del 89 %. Estas cifras suponen el consumo de potencia constante indicado; las mediciones reales pueden establecer el consumo efectivo de un dispositivo.

Reutiliza configuraciones y detén los recursos inactivos

Reutiliza dispositivos de prueba, máquinas virtuales e instantáneas cuando cumplan los requisitos de las pruebas. Automatiza las comprobaciones repetitivas y conserva los resultados en formato digital. Las configuraciones idénticas pueden compartir pruebas exhaustivas sobre una muestra, mientras que cada dispositivo sigue recibiendo las comprobaciones individuales de preparación que necesita.

Después de las pruebas, apaga las máquinas virtuales de prueba y elimina los recursos en la nube sin uso. Comprueba el estado real de los recursos en la plataforma: en Azure, apagar una máquina virtual desde el sistema operativo puede dejar sus recursos asignados y mantener los cargos por cómputo. Liberar sus recursos detiene esos cargos, mientras que los discos conservados siguen generando cargos por almacenamiento. Sigue las acciones de detención y eliminación documentadas por la plataforma y comprueba qué queda.

Prueba los ajustes de eficiencia según el trabajo real

Los programas de inicio y los servicios en segundo plano innecesarios consumen tiempo de procesador y memoria. Mide el uso de recursos y el tiempo de respuesta antes y después de un cambio de configuración, en condiciones comparables. Asigna a una máquina virtual la memoria y la capacidad de procesador que necesita sin restar al equipo anfitrión capacidad que no va a utilizar.

Los ajustes de suspensión y apagado de pantalla reducen el consumo energético en inactividad, pero sus tiempos deben adecuarse a la tarea. Una pantalla informativa de recepción puede necesitar permanecer visible todo el día. Un dispositivo con actualizaciones nocturnas programadas necesita reactivarse o seguir disponible durante esa ventana. Un ajuste de ahorro energético no cumple su finalidad si impide una tarea imprescindible.

No elimines un servicio necesario en segundo plano solo porque aparezca en un monitor de recursos. La prueba comprueba la configuración acordada y su efecto; un fallo se registra para investigarlo. La eficiencia y el rendimiento se miden según los mismos requisitos de usuario y de las políticas que los demás ajustes.

Utiliza el hardware durante su vida útil

Las pruebas pueden mostrar que un dispositivo antiguo sigue cumpliendo los requisitos, lo que retrasa su sustitución y el uso de materiales necesarios para fabricarla. Reutilizar hardware de pruebas también reduce los residuos. El ahorro de energía depende del dispositivo y de su carga de trabajo: la fabricación representa gran parte de la huella de muchos equipos portátiles y teléfonos, mientras que un servidor ineficiente puede consumir suficiente electricidad durante su uso como para que convenga sustituirlo.

Cuando el equipo llegue al final de su vida útil, organiza el borrado seguro de sus datos y su reciclaje autorizado. La reutilización solo es valiosa si el dispositivo sigue siendo adecuado para su siguiente tarea y sus datos anteriores están protegidos.

Una prueba funcional sigue una tarea hasta su resultado útil. Abrir un programa es solo el principio si el usuario necesita editar, guardar, enviar o imprimir trabajo con él.

Sigue la tarea completa

Parte de los requisitos funcionales y enumera las acciones que debe completar el usuario. Las comprobaciones habituales de soporte incluyen iniciar sesión; abrir las aplicaciones necesarias; editar y guardar archivos compartidos; usar el correo interno y externo; imprimir; acceder a Wi-Fi y VPN; escanear; acceder a los sitios web necesarios; y realizar una llamada con cámara y auriculares con micrófono.

Para cada tarea, identifica la evidencia final. Un cuadro de diálogo de impresión no demuestra que la impresora asignada haya producido una página legible. Un mensaje de guardado aporta una evidencia más sólida si el archivo puede cerrarse, volver a abrirse y comprobarse que contiene lo esperado.

Utiliza la cuenta correcta

Realiza las tareas del usuario con su cuenta o con una cuenta de prueba que pertenezca a los mismos grupos. Un administrador puede acceder a archivos o cambiar ajustes que un usuario estándar no puede. Probar solo como administrador puede ocultar precisamente el problema de permisos que encontrará el usuario.

Para un recurso compartido de Ventas, inicia sesión con una cuenta de prueba de Ventas. Abre el recurso compartido, crea «Presupuesto-prueba.docx», guárdalo, ciérralo y vuelve a abrirlo. Comprueba el contenido. Después intenta abrir el recurso compartido de Recursos Humanos con esa misma cuenta. Si el personal de Ventas no debe acceder a Recursos Humanos, el resultado esperado es «Acceso denegado». Registra por separado los resultados positivos y negativos.

Un técnico puede necesitar una herramienta autorizada con privilegios elevados para revisar un ajuste protegido. Es una comprobación distinta de demostrar que el usuario puede realizar una tarea. Incluye la cuenta y el nivel de privilegios en cada registro de resultados.

Elige una comprobación rápida o una prueba detallada

Una prueba de humo es una comprobación breve y poco exhaustiva de las funciones esenciales: arranque, inicio de sesión, conexión de red y aplicación principal. Ejecútala primero para identificar una configuración que no esté preparada para pruebas más profundas. Si falla el inicio de sesión, muchas tareas posteriores no pueden intentarse de forma significativa.

Superar la prueba de humo no demuestra que todas las tareas funcionen. Continúa con los casos previstos de extremo a extremo, incluidas las acciones menos frecuentes pero necesarias. Una aplicación que se abre puede fallar al guardar un informe o conectarse a un servicio.

Vuelve a probar las correcciones y el comportamiento relacionado

Las pruebas de confirmación repiten la prueba fallida tras una corrección. Responden a si el problema original ha desaparecido. Las pruebas de regresión repiten comprobaciones que antes se superaron para buscar perjuicios causados por el cambio.

Tras actualizar el controlador de una impresora, repite primero el caso de impresión que falló. Después comprueba la impresión desde las otras aplicaciones principales y el escaneo cuando el mismo paquete de controladores pueda afectarlo. Conserva el fallo original y añade los resultados nuevos para que el registro muestre tanto el defecto como la evidencia de su corrección.

Comprueba las combinaciones necesarias

Las pruebas de compatibilidad abarcan los sistemas operativos, navegadores, dispositivos y formatos de archivo que los usuarios necesitan realmente. Que un portal funcione en un navegador no confirma el segundo navegador admitido. Registra las versiones y combinaciones probadas; de lo contrario, afirmar que «el portal funciona» oculta parte del alcance. Incluso después de un cambio pequeño, elige pruebas de regresión para las funciones que pueda afectar.

Las pruebas de rendimiento sustituyen «parece lento» por mediciones en condiciones conocidas. Las pruebas de estabilidad preguntan si el comportamiento aceptable se mantiene con el tiempo, por lo que una ejecución rápida y satisfactoria es solo una parte de las evidencias.

Ajusta la métrica al requisito

El tiempo de respuesta mide la espera desde una acción hasta su resultado, en segundos o milisegundos. La tasa de procesamiento mide el trabajo por unidad de tiempo, como páginas por minuto o Mbit/s. La utilización de recursos incluye el porcentaje de uso del procesador, el uso de memoria, la actividad del disco y el uso de la red. La latencia de red es el retardo en milisegundos; la pérdida de paquetes es el porcentaje de solicitudes sin respuesta.

Conserva una línea base medida en condiciones normales. Compara los resultados posteriores con esa referencia y con los umbrales acordados. Una lectura del procesador del 70 % significa poco sin conocer la carga de trabajo y el comportamiento normal de ese sistema.

Elige condiciones realistas

Una ejecución con un solo usuario y poca actividad no permite establecer el rendimiento durante una mañana ajetreada. Una prueba de resistencia prolongada puede revelar un uso de memoria que no deja de crecer o una ralentización que tarda horas en aparecer. Repite las mediciones con el mismo método y registra condiciones como un arranque en frío, las actualizaciones en segundo plano y el modo de energía.

Interpreta algo más que la media

Para tiempos de inicio de sesión de 4,2; 3,8; 4,0; 9,6 y 4,1 segundos, el total es de 25,7 segundos. Al dividir entre cinco se obtiene una media de 5,14 segundos. Los valores ordenados son 3,8; 4,0; 4,1; 4,2 y 9,6, por lo que la mediana es de 4,1 segundos y el máximo, de 9,6 segundos.

Se cumple el criterio «mediana de como máximo 5 segundos y ningún inicio de sesión superior a 10 segundos». La ejecución lenta eleva la media por encima de 5 segundos, pero el criterio no especifica la media. Conserva la observación lenta para investigarla; no la elimines simplemente por ser inusual.

Un criterio porcentual también necesita su cantidad. «El 95 % de 20 cargas de página en menos de 2 segundos» exige 19 cargas que cumplan la condición. Se permite una carga más lenta, pero no dos. Una respuesta perdida de 20 solicitudes de ping supone un 5 % de pérdida. «Menos de 2 segundos» excluye exactamente 2 segundos, mientras que «como máximo 2 segundos» los incluye.

Registra un fallo antes de investigarlo

Utiliza el Administrador de tareas, el Monitor de recursos o el Monitor de rendimiento en Windows; el Monitor de Actividad en macOS; o top, htop y free -h en Linux. Un temporizador mide la espera del usuario, mientras que ping ayuda a medir la latencia y la pérdida. Conserva las unidades y el método con cada resultado.

Una memoria insuficiente, los programas de inicio, un controlador, el modo de energía, la capacidad del hardware, los defectos de software y los servicios externos pueden afectar al rendimiento. Un umbral incumplido identifica un problema que investigar, no su causa. Tras la corrección, vuelve a medir en condiciones comparables para que la comparación entre el antes y el después sea significativa.

Un sistema puede realizar sus funciones técnicas y aun así dificultar o impedir las tareas cotidianas a algunos usuarios. Las comprobaciones de usabilidad y accesibilidad examinan la tarea desde el punto de vista del usuario previsto, incluidos sus ajustes y su tecnología de apoyo.

Observa la tarea sin tomar el control

La usabilidad trata de la eficacia, la eficiencia y la satisfacción: ¿pueden las personas alcanzar sus objetivos con un esfuerzo y una experiencia aceptables? Recorre las tareas principales, anota los pasos y el tiempo, y busca etiquetas confusas o errores poco claros. Después observa a un usuario representativo intentarlo sin ayudarle. La ayuda puede ocultar el punto en que la interfaz deja de tener sentido.

Una aplicación anclada o una unidad de red asignada puede acortar una tarea diaria. Comprueba que cualquier ajuste siga cumpliendo los requisitos de acceso y seguridad.

Comprueba el acceso de las personas con discapacidad

La accesibilidad trata de si las personas con discapacidad visual, auditiva, motora o cognitiva pueden percibir, manejar y comprender el sistema. Los lectores de pantalla, las lupas, el control por voz y el acceso mediante conmutadores son ejemplos de tecnología de apoyo.

WCAG 2.2 agrupa la accesibilidad web en los principios perceptible, operable, comprensible y robusto. Sus criterios tienen niveles A, AA y AAA. Muchas organizaciones utilizan AA, que también incluye los requisitos de A. WCAG está redactado para contenido web y también se utiliza para orientar el trabajo con aplicaciones y documentos.

Las comprobaciones prácticas incluyen:

• Completar la tarea con controles de teclado y mantener visible el foco.
• Utilizar un lector de pantalla para comprobar que los botones, campos y encabezados tengan nombres significativos.
• Ampliar el texto al 200 % y comprobar que no se pierdan contenido ni funciones.
• Confirmar que el significado no dependa solo del color y que los vídeos tengan subtítulos.
• Comprobar el tamaño de los objetivos del puntero. WCAG 2.2 AA establece un mínimo de 24 por 24 píxeles CSS, con excepciones definidas.

Interpreta el contraste con precisión

Para el texto normal, la relación mínima de contraste de AA es de 4,5:1. Para el texto grande, es de 3:1. Grande significa al menos 18 puntos, o 14 puntos en negrita. Son relaciones entre el primer plano y el fondo, que van de 1:1 a 21:1.

Una herramienta de comprobación de contraste da aproximadamente 4,54:1 para #767676 sobre blanco, que supera el umbral del texto normal. #777777 da aproximadamente 4,48:1: no cumple para texto normal, pero sí para texto grande. No redondees al alza un valor inferior al umbral para que lo supere.

Prueba la configuración real del usuario

Configura la ampliación, la escala, los temas de contraste, el tamaño del puntero, el lector de pantalla, los subtítulos en directo, las teclas especiales o el dictado que se necesiten. Confirma que los ajustes se mantienen tras cerrar sesión y reiniciar, y después realiza la tarea empresarial con ellos. Una pantalla que parece correcta con la escala del técnico puede perder un control con el ajuste del 200 % del usuario.

Las herramientas automatizadas detectan problemas como alternativas textuales ausentes y contraste bajo. No pueden valorar por completo si las descripciones son significativas, el orden de lectura tiene sentido o las tareas se completan de forma práctica. Añade comprobaciones manuales con teclado y lector de pantalla y, cuando sea posible, usuarios con su propia tecnología de apoyo.

Las comprobaciones de seguridad confirman que las protecciones exigidas están presentes y se comportan correctamente. Una acción bloqueada puede ser el resultado satisfactorio: una cuenta de Ventas debe poder utilizar los archivos de Ventas, pero no acceder a los registros restringidos de Recursos Humanos.

Conoce qué se protege

La confidencialidad limita quién puede ver los datos. La integridad protege los datos y los ajustes frente a cambios indebidos. La disponibilidad mantiene el sistema utilizable para las personas que lo necesitan. Las pruebas de seguridad a nivel de soporte relacionan estos objetivos con los ajustes acordados de cuentas, dispositivos y red.

Prueba solo los sistemas para los que tengas autorización y mantente dentro del alcance acordado. Los análisis, los intentos de adivinar contraseñas y los intentos de eludir controles requieren permiso; las pruebas de penetración especializadas utilizan un acuerdo escrito.

Comprueba las identidades y los permisos

Aplica el principio de mínimo privilegio: concede a una cuenta solo el acceso necesario para su función. Comprueba la pertenencia a grupos, los recursos compartidos necesarios, la política de contraseñas, la MFA, el bloqueo, la deshabilitación de cuentas de invitado o sin uso y la eliminación de cuentas de antiguo personal. Cambia las contraseñas de fábrica de dispositivos y aplicaciones.

Utiliza tanto acciones permitidas como prohibidas. Confirma que un usuario estándar puede abrir la carpeta necesaria y después confirma que una carpeta restringida rechaza a esa función. Para una instalación que necesite derechos de administrador, el resultado esperado es una solicitud de credenciales de administrador que el usuario estándar no pueda satisfacer por sí solo.

Ser usuario estándar no impide todas las instalaciones de software: algunos programas se instalan en su perfil. Si el requisito es «ninguna instalación de software», también se necesita una política de control de aplicaciones y debe probarse. No conviertas una comprobación de privilegios de administrador en una afirmación más amplia sobre todo el software.

Revisa los ajustes del dispositivo y de la red

Comprueba el estado del cortafuegos en todos los perfiles de red, la protección activa de dispositivos finales y sus definiciones actualizadas, el cifrado de disco, el bloqueo de pantalla por inactividad, las actualizaciones exigidas y la desactivación de servicios o accesos remotos innecesarios. Confirma los puertos de red necesarios y una protección Wi-Fi aprobada, como WPA2 o WPA3.

En Windows, una consola autorizada con privilegios elevados puede ejecutar manage-bde -status C:. Comprueba que aparezca «Protección activada» en la unidad del sistema. PowerShell puede enumerar los estados de los perfiles del cortafuegos:

Get-NetFirewallProfile | Select-Object Name, Enabled

Dominio, Privado y Público deben mostrar «Verdadero» cuando el requisito sea que esté habilitado en todos los perfiles. Para una cuenta local, net user t.sales ayuda a revisar el estado activo y la pertenencia a grupos. En macOS, fdesetup status indica el estado de FileVault. Registra la salida real y compárala con el requisito.

Mantén controlados los datos y las excepciones

Comprueba que los archivos sensibles estén en ubicaciones aprobadas, sean accesibles solo para las funciones correctas y estén protegidos mediante cifrado cuando se exija. Elimina los datos de prueba y los archivos del técnico antes de la entrega. Aplica los avisos de inicio de sesión y los ajustes de protección de datos exigidos.

Céntrate en los riesgos habituales de configuración: permisos demasiado amplios, autenticación débil, parches ausentes, acceso remoto expuesto y valores predeterminados inseguros. Un ajuste en una pantalla de administración central no basta si no se ha aplicado al dispositivo.

Los ajustes de seguridad pueden añadir esfuerzo para el usuario: las solicitudes de MFA y los intervalos de bloqueo más cortos son ejemplos. Prueba la política acordada y registra cualquier excepción solicitada para que la apruebe la persona responsable de seguridad. Una preferencia personal no autoriza a debilitar un control obligatorio.

Un resultado es útil cuando otra persona puede ver qué se esperaba, qué ocurrió y cómo se comparan ambas cosas. Registra los hechos durante las pruebas, incluidos los fallos que después se corrijan.

Elige el estado según las evidencias

Escribe el resultado esperado antes de la prueba, utilizando el requisito. Registra el resultado observado a medida que ocurre. Si coinciden, la prueba se supera; si difieren, falla. Decide por separado la gravedad de esa diferencia.

Una interrupción de la red que impide una prueba de correo electrónico la deja bloqueada. No demuestra que el correo haya superado la prueba ni que haya fallado. Mantén visible esa carencia en el informe.

Escribe evidencias que pueda utilizar un compañero

Registra los identificadores del caso y del requisito, el dispositivo, la cuenta, quién realiza la prueba, la fecha y la hora exacta. Incluye los pasos, las mediciones con unidades, el texto y los códigos de error, las capturas pertinentes y las entradas de registro. Utiliza fechas inequívocas, como 2026-10-21, y términos coherentes para los estados.

«La impresión no funciona» deja demasiado por reconstruir. Un registro más sólido es: «A las 10:42, el trabajo de impresión del procesador de textos permaneció en la cola durante 30 segundos y después mostró “Error de impresión”; el registro del servicio de impresión anotó un error a las 10:42». Distingue las observaciones visibles de una hipótesis sobre su causa.

Cada fallo necesita un informe de defecto con un identificador único, título, entorno, pasos para reproducirlo, resultados esperados y reales, evidencias, gravedad, prioridad y estado actual. Vincula el informe a la prueba para que quien lo revise pueda seguirlo hasta la corrección y la repetición de la prueba.

Separa el impacto de la urgencia

La gravedad mide el impacto del defecto. La prioridad mide con qué urgencia debe corregirse. A menudo coinciden, pero sirven para decisiones diferentes. El nombre de la empresa mal escrito en una pantalla de inicio de sesión tiene gravedad baja, pero puede ser urgente antes de un lanzamiento de cara al cliente. Un problema de gran impacto en un informe anual puede tener menor prioridad inmediata si aún no toca elaborarlo.

No utilices una prioridad baja para ocultar un impacto alto. La decisión sobre la preparación sigue teniendo en cuenta la gravedad y los requisitos imprescindibles.

Indica la base de cada tasa

Supón que se previeron 48 casos: 42 se superan, 3 fallan, 2 están bloqueados y 1 no se ejecuta. Los casos ejecutados son los superados y los fallidos, así que hay 45. La tasa de pruebas superadas entre las ejecutadas es aproximadamente del 93,3 %; entre las previstas, es del 87,5 %. Ambas describen los mismos resultados con distintos denominadores.

Informa de las cantidades junto con los porcentajes para que los tres casos no ejecutados no desaparezcan detrás de una tasa alta. Busca patrones entre dispositivos, horarios, configuraciones y redes: tres fallos de un mismo lote de entrega sugieren una causa común que investigar, no la demuestran.

Conserva el fallo original cuando se realice una corrección. Añade la corrección y el resultado de la repetición de la prueba con sus fechas. Sobrescribir la fila fallida destruye las evidencias de lo que cambió y hace que el registro resulte engañoso.

Los registros muestran eventos internos de un sistema que pueden no aparecer en su pantalla. Interprétalos junto con el resultado de la tarea y las mediciones de rendimiento para construir una relación cronológica de lo ocurrido.

Encuentra el registro pertinente

Un registro del sistema es un registro con marcas de tiempo de eventos, errores y actividad de acceso. El Visor de eventos de Windows incluye los registros Aplicación, Seguridad, Instalación, Sistema y Eventos reenviados, además de los Registros de aplicaciones y servicios específicos de cada componente. Las entradas tienen campos como hora, origen, identificador de evento, nivel y descripción.

Los niveles de Windows incluyen Crítico, Error, Advertencia, Información y Detallado. Los eventos de seguridad utilizan Auditoría correcta o Error de auditoría. Un error de auditoría puede ser lo esperado en una prueba negativa, como un intento de inicio de sesión prohibido; su significado depende del resultado esperado de la prueba.

En Linux, utiliza journalctl para el diario de systemd y los archivos pertinentes de /var/log. En macOS, utiliza Consola. Los niveles estándar de gravedad de syslog van desde 0, Emergencia, pasando por Alerta, Crítico, Error, Advertencia, Aviso e Informativo, hasta 7, Depuración. Un número de syslog menor significa mayor gravedad.

Relaciona por hora e identidad

Antes de una prueba, comprueba el reloj y la zona horaria del dispositivo. Anota la hora de cada paso y después filtra el registro pertinente por esa ventana de tiempo y origen. Lee los eventos inmediatamente anteriores al fallo, además del propio fallo. Compara con el comportamiento normal de la línea base, porque algunas advertencias son habituales.

En una asignación de unidad fallida a las 10:42, a un evento de dirección IP a las 10:41:58 le sigue un tiempo de espera DNS agotado para files.example.com a las 10:42:05 y un error de asignación a las 10:42:06. Guarda juntas las entradas del tiempo agotado y de la asignación. Orientan la investigación hacia la resolución de nombres; por sí solas no establecen la causa definitiva.

Comprende los eventos de cuentas

El evento de Seguridad de Windows 4624 registra un inicio de sesión correcto; el 4625, uno fallido; y el 4740, el bloqueo de una cuenta. Dependen de que la auditoría esté habilitada. La auditoría de errores de inicio de sesión es necesaria para las entradas 4625 pertinentes; el 4740 necesita la auditoría de aciertos de Administración de cuentas de usuario.

Una prueba de bloqueo puede producir varios eventos de inicio de sesión fallido, incluido otro cuando se rechaza la contraseña correcta después del bloqueo. Para una cuenta de dominio, las evidencias pueden estar en distintos equipos, incluido el controlador de dominio que almacena la cuenta. Relaciona cuenta, hora y equipo. No esperes una secuencia fija de eventos en un solo registro.

Interpreta las alertas y las tendencias en su contexto

Una alerta notifica a alguien que se ha producido un evento o umbral definido: un servicio detenido, una copia de seguridad fallida o un disco casi lleno. Crea de forma segura una condición de alerta exigida en el entorno de pruebas y confirma que llegue la alerta. Registra su destino y cuándo llega.

Los indicadores de rendimiento incluyen uso de CPU, memoria disponible, almacenamiento libre, actividad del disco, tasa de procesamiento, latencia, pérdida y tiempo de respuesta. Un pico breve del procesador al iniciar sesión difiere de varios minutos de inactividad al 95 %. Compara la duración, la carga de trabajo y la línea base.

Busca intervalos repetidos, fallos tras reinicios o problemas limitados a una subred. Copia los identificadores y mensajes pertinentes en el registro de resultados. Una advertencia es una pista que interpretar, no un defecto automático, y una pantalla sin mensajes no es motivo para omitir los registros de las pruebas críticas.

La automatización puede repetir una comprobación en muchos sistemas sin omitir pasos por cansancio. Su valor depende de lo que demuestre realmente la comprobación y de si alguien ha verificado sus resultados.

Asigna a las herramientas el trabajo repetible

Los guiones de PowerShell y Bash pueden revisar ajustes, las macros pueden repetir acciones, las herramientas de interfaz pueden ejecutar tareas de aplicaciones y las herramientas de supervisión pueden recoger métricas. Los analizadores de configuración, vulnerabilidades y accesibilidad comparan determinadas características con reglas o líneas base.

Estas herramientas son útiles para las pruebas de regresión y las comprobaciones necesarias en cada dispositivo. Un error del guion también se repite en todos los dispositivos, así que primero compara su salida con un sistema conocido y una comprobación manual. Actualiza la herramienta cuando cambie el sistema. La repetición hace coherente un método; no hace exacto un método incorrecto.

Limita la afirmación a lo que comprueba la prueba

Test-NetConnection files.example.com -Port 445 puede indicar «Prueba TCP satisfactoria: verdadero». Esto establece que se realizó correctamente una conexión TCP a ese puerto del servidor. No establece que el usuario pueda abrir un recurso compartido, crear un documento o guardarlo.

Para demostrar el acceso a archivos, realiza la tarea del usuario con los permisos correctos y revisa su resultado. Una comprobación de puerto y una prueba funcional de una tarea aportan evidencias diferentes. Combinarlas puede ayudar a aislar un fallo, pero una no puede sustituir a la otra.

Un falso positivo es un problema notificado que no es real. Un falso negativo es un problema real que la herramienta no detecta. Un falso positivo puede hacer perder tiempo o retrasar la entrega; un falso negativo puede generar una confianza injustificada. Su perjuicio relativo depende de la comprobación. No detectar un ajuste de seguridad inseguro suele ser más grave que señalarlo innecesariamente para revisarlo.

Revisa un borrador de IA antes de utilizarlo

Las herramientas de IA pueden sugerir casos y datos de prueba, resumir registros, identificar posibles patrones y redactar borradores de informes. También pueden inventar comandos, omitir casos importantes o escribir conclusiones que las evidencias no respaldan.

Relaciona los casos generados con la lista de requisitos. Añade las comprobaciones negativas, de valores límite y de accesibilidad que falten. Contrasta los comandos propuestos con la documentación oficial y después pruébalos en el entorno de pruebas. Compara un resumen del registro con las líneas originales, incluidas las marcas de tiempo y las cuentas que afirma describir.

Para un rango de contraseñas de 12–64 caracteres y bloqueo tras cinco fallos, un borrador que contenga una contraseña de 15 caracteres y un caso de cinco fallos está incompleto. Añade las longitudes 11, 12, 64 y 65, comprueba que cuatro fallos no bloqueen la cuenta y prueba el desbloqueo. Establece condiciones iniciales adecuadas para que cada caso mida la regla prevista.

La persona que da la aprobación formal sigue siendo responsable de los resultados. La revisión incluye comprobar si la conclusión de una herramienta va más allá de sus mediciones, no solo corregir su ortografía.

Protege la información que se procesa

Utiliza solo servicios de IA aprobados por la organización para el material de trabajo. No pegues contraseñas, datos personales, registros confidenciales ni nombres de equipo internos en un servicio no aprobado. Oculta los valores sensibles y sigue las políticas de uso aceptable y protección de datos. Un resumen útil no justifica exponer la información que resume.

Las comprobaciones de preparación confirman el estado del dispositivo o sistema real justo antes de la entrega. Las evidencias de pruebas anteriores pueden describir una configuración antigua, otra cuenta o un dispositivo de muestra, así que conserva una lista de comprobación firmada y fechada para cada unidad entregada.

Comprueba el usuario y las conexiones

Confirma que la cuenta existe, está habilitada y pertenece a los grupos correctos. Comprueba el inicio de sesión, el cambio de contraseña temporal y el registro de MFA según corresponda. Elimina las cuentas de prueba y el perfil del técnico, y evita los derechos de administrador salvo que la función los requiera.

Comprueba la dirección, la puerta de enlace y los servidores DNS. En Windows, ipconfig /all muestra la configuración IP. En Linux, ip a muestra las direcciones, ip route muestra las rutas, incluida la puerta de enlace predeterminada, y resolvectl status muestra DNS en los sistemas que utilizan systemd-resolved. ip a por sí solo no establece la configuración de la puerta de enlace ni de DNS.

Utiliza ping para comprobar los destinos de red que responden, nslookup para la resolución de nombres y una comprobación del puerto del servicio, como Test-NetConnection, para los servicios necesarios. Después completa la tarea real. Algunas redes bloquean ping, así que la ausencia de respuesta por sí sola no establece que todos los servicios estén indisponibles. Confirma los perfiles Wi-Fi, la VPN, los recursos compartidos y las impresoras necesarios.

Compara el almacenamiento con el requisito

Comprueba el espacio libre, las cuotas, el almacenamiento de red, la sincronización en la nube y la copia de seguridad. Una unidad comercializada como de 512 GB contiene 512 mil millones de bytes. Al dividir entre 2³⁰ se obtienen aproximadamente 476,8 GiB; Windows suele etiquetar este número de base binaria como «GB».

Para un criterio de «al menos un 20 % libre», utiliza cifras de espacio libre y total con la misma base de medición. El veinte por ciento de 476,8 es aproximadamente 95,4. Con 61,2 libres, la proporción es de aproximadamente el 12,8 %, por lo que no cumple. Elimina los instaladores sobrantes y los archivos de prueba según corresponda y vuelve a medir. Comparar 61,2 con los 512 comercializados sin tener en cuenta las unidades mezclaría bases.

Confirma las actualizaciones y la protección

Comprueba el sistema operativo, las aplicaciones, los navegadores, los controladores y el firmware según las versiones exigidas. Completa los reinicios pendientes y actualiza las definiciones de protección de dispositivos finales. Windows Update y winver, Actualización de software de macOS y el gestor de paquetes de Linux aportan evidencias pertinentes.

Verifica el cifrado de disco, el cortafuegos, la protección activa de dispositivos finales, el tiempo de bloqueo de pantalla, las contraseñas predeterminadas cambiadas y los servicios innecesarios desactivados. Confirma los ajustes aprobados de almacenamiento de archivos y copias de seguridad en el dispositivo, no solo en una consola de administración que indique que se envió la política.

Termina con la tarea en funcionamiento

Ejecuta una prueba de humo de la funcionalidad y el rendimiento esperados. Realiza las tareas del usuario con su cuenta o una equivalente. Utiliza privilegios de administrador autorizados solo para las comprobaciones que los necesiten, como una herramienta con privilegios elevados para consultar el estado del cifrado.

Si falta un perfil VPN, registra la comprobación fallida, añade el perfil mediante el proceso aprobado y repite el acceso VPN y las tareas afectadas. Conserva la corrección y la nueva comprobación en el registro de ese dispositivo. Comprobar otro equipo portátil del mismo modelo no establece el estado de este.

Una recomendación sobre la preparación compara las evidencias con los requisitos y los criterios de salida. La persona responsable necesita ver qué se superó, qué sigue abierto y qué riesgos se aceptarían al comenzar a utilizar el sistema ahora.

Construye la decisión a partir de los registros

Primero da cuenta de cada caso previsto, incluidas las pruebas bloqueadas y omitidas. Confirma los requisitos imprescindibles, revisa los defectos según su gravedad y termina la lista de comprobación de preparación. Considera el riesgo de los problemas abiertos y el efecto de un retraso. Redacta una recomendación razonada para la persona autorizada para aceptar el sistema.

Los resultados habituales son apto, apto con condiciones y no apto. Las condiciones identifican problemas menores conocidos, soluciones provisionales viables y una fecha de corrección. Un problema sin resolver de gravedad alta que afecte a un requisito imprescindible suele impedir considerar preparado el sistema; los criterios de salida acordados determinan la decisión.

Una tasa global alta de pruebas superadas no puede anular un requisito imprescindible incumplido. Del mismo modo, un problema de bajo impacto no tiene por qué retrasar todos los dispositivos si la persona responsable puede aceptarlo según los criterios.

Separa los sistemas afectados

Para 12 equipos portátiles de ventas, supón que tres pierden el acceso VPN tras diez minutos de inactividad y todos tienen un fondo de escritorio incorrecto. El uso remoto de la VPN es imprescindible y los criterios de salida no permiten defectos abiertos de gravedad alta.

Los tres que tienen el defecto de VPN no están preparados hasta que se corrija y se repitan las pruebas. Se puede recomendar la entrega de los otros nueve con el problema de gravedad baja del fondo de escritorio registrado y aceptado. Identifica los dispositivos individuales en la decisión; una afirmación sobre todo el lote ocultaría la diferencia.

El mismo principio se aplica a un subconjunto de tareas solo cuando la persona responsable ha acordado ese alcance. Un técnico no puede eliminar discretamente un requisito incumplido para producir un resultado satisfactorio.

Aplica el umbral acordado

Un criterio de «el 95 % de 20 cargas en menos de 2 segundos» necesita 19 cargas que cumplan la condición. Dieciocho equivalen al 90 %, lo que supone un fallo aunque las personas digan que la aplicación parece rápida. Registra el incumplimiento como un fallo. Si la persona responsable acepta el riesgo, conserva la medición fallida y registra quién aceptó la excepción.

Los requisitos pueden entrar en conflicto en la práctica. Un análisis de malware al arrancar puede ralentizar el inicio de sesión, o la MFA puede añadir un paso. Indica el coste medido, el beneficio de seguridad exigido por la política y el compromiso aprobado. No cambies discretamente un umbral ni debilites un control para que ambas pruebas parezcan superadas.

Haz que el informe pueda revisarse

Un informe de resumen de pruebas indica el alcance, el entorno y las fechas; las cantidades por estado; las tasas de pruebas superadas con sus bases; los defectos abiertos y sus gravedades; las desviaciones respecto al plan; los riesgos restantes; y la recomendación con sus motivos. Vincula las conclusiones con los resultados de los casos, los registros o las evidencias de las listas de comprobación.

«No se encontraron defectos» describe las pruebas ejecutadas. Incluye las áreas no probadas para que no pueda interpretarse como una promesa de ausencia de defectos en todo el sistema. Llegar a una fecha límite tampoco satisface los criterios de salida: la persona responsable debe registrar cualquier riesgo aceptado.

Después de una actualización o un cambio de configuración, utiliza pruebas de regresión y comprobaciones de preparación para confirmar que el sistema sigue siendo apto para el uso. Una aceptación anterior se aplica al estado probado; un comportamiento modificado necesita evidencias nuevas.

La entrega proporciona a los usuarios un sistema que funciona y al equipo de soporte suficiente información para mantenerlo. La aceptación registra quién acordó que estaba preparado, cuándo lo acordó y las condiciones pendientes.

Prepara lo que necesita cada público

Los usuarios necesitan el dispositivo o servicio, datos de inicio de sesión entregados de forma segura, una guía breve de inicio rápido, las aplicaciones instaladas y los recursos conectados, los problemas conocidos con sus soluciones provisionales e instrucciones para obtener ayuda. Los compañeros técnicos también necesitan el registro de configuración y las evidencias que respaldan cualquier problema aceptado.

Registra las decisiones de configuración con sus motivos. «Bloqueo de pantalla tras cinco minutos, exigido por la política de seguridad» explica más que el ajuste por sí solo. «Escala de pantalla del 150 % por baja visión» ayuda al siguiente técnico a conservar un ajuste importante durante el soporte o la reconstrucción.

El responsable necesita el resultado sobre la preparación, los riesgos restantes y las decisiones que requieren aprobación. Un usuario suele necesitar las acciones que debe realizar en el primer inicio de sesión y cómo completar las tareas diarias. Enviar a ambos el mismo informe técnico dificulta encontrar la parte útil.

Entrega el acceso de forma segura

Envía el nombre de usuario y la contraseña temporal por canales separados. Exige cambiar la contraseña temporal en el primer inicio de sesión. No dejes una contraseña pegada al dispositivo ni la incluyas en el mismo mensaje que el nombre de usuario.

Confirma el registro de MFA o el proceso acordado para el primer uso. Elimina las cuentas de prueba, los archivos de prueba y el acceso innecesario del técnico antes de que el usuario se haga responsable del dispositivo. El equipo de soporte no debería tener que adivinar qué cambios temporales quedan.

Registra la aceptación del usuario

Pide al usuario o a la persona responsable que complete las tareas principales, a menudo en un recorrido breve o una sesión de pruebas de aceptación del usuario. Utiliza datos de ejemplo realistas en un entorno de formación cuando la práctica no deba afectar al trabajo de producción.

La aprobación formal registra la fecha, la persona que acepta y las condiciones. Los problemas conocidos necesitan sus soluciones provisionales y fechas de corrección acordadas. Un dispositivo entregado en un escritorio sin aceptación no constituye un registro de entrega completo.

Un mensaje al usuario puede decir: «Tu nuevo equipo portátil está preparado. Inicia sesión con tu nombre de usuario habitual y elige una contraseña nueva cuando se te pida. Si la segunda pantalla sigue apagada tras la suspensión, desconecta y vuelve a conectar el cable de la estación de acoplamiento. Contacta con el centro de soporte si el problema continúa». La solución provisional ofrece una acción que la persona puede realizar; los hallazgos técnicos permanecen en el registro de soporte.

Presta soporte durante los primeros días de uso

Demuestra brevemente las funciones nuevas o los flujos de trabajo modificados. Indica a los usuarios cómo contactar con el centro de soporte y cómo registrar una solicitud. Registra las consultas, responde dentro de los plazos de servicio acordados y escala los problemas que no puedas resolver. Mantén una comunicación respetuosa y evita prometer una fecha de corrección que no se haya confirmado.

Supervisa de cerca los registros, las alertas y los comentarios de los usuarios después de la entrega. Algunos fallos solo aparecen con cargas de trabajo reales o tareas menos habituales. Añade los hallazgos útiles a la lista de comprobación y al plan de pruebas de la siguiente implementación. Un problema conocido aceptado sigue siendo visible para los usuarios y el soporte hasta que se resuelva y se vuelva a probar.