8.10 · Test integral y QA

04 April 2026

Por:
Anton
Sección:
Módulo 8 · Construcción de un cyberdeck
Lectura:
4 min
Infografía: 8.10 · Test integral y QA

Test integral y QA: checklist completo (teclas, pantalla, WiFi/BT, LoRa TX/RX, batería duración y carga, temperaturas estables, carcasa sin holguras ni crujidos)

El deck está montado y cerrado. Funciona… probablemente. La diferencia entre “probablemente funciona” y “sé que funciona” es un proceso de QA (control de calidad): un test integral con una lista de comprobación que recorre cada subsistema de forma metódica. No te fíes de que arrancó una vez; verifica todo, anota resultados y corrige antes de dar el build por bueno.

Por qué una checklist

Cuando un sistema tiene muchas partes, la memoria falla. Crees haber probado el LoRa pero solo probaste la transmisión, no la recepción. Crees que la batería dura, pero nunca la descargaste del todo. Una checklist escrita te obliga a tocar cada función y a dejar constancia. Además, te servirá de plantilla para el segundo build y para cualquier deck que hagas a un cliente.

Marca cada punto como OK, FALLO o A REVISAR. Lo que no esté en verde, se arregla.

Entrada: teclado y puntero

  • Todas las teclas. Abre un editor de texto y pulsa cada tecla del Corne, una por una. Busca teclas muertas, teclas que repiten (chattering: el rebote eléctrico de un contacto que el firmware registra como varias pulsaciones) o que registran dos veces. En un teclado dividido, prueba las dos mitades.
  • Capas y combinaciones. Si el Corne usa capas, comprueba que los símbolos, números y teclas de función responden.
  • Puntero. Mueve el cursor en las cuatro direcciones, comprueba el clic y, si la trackball lleva LED, que se ilumina. Verifica que el movimiento es suave, sin saltos.

Salida: pantalla

  • Imagen completa. Muestra una imagen a pantalla completa y busca píxeles muertos, zonas oscuras o líneas.
  • Estabilidad. Mueve el deck y, si tiene bisagra, ábrelo y ciérralo: la imagen no debe parpadear ni cortarse, señal de un cable de pantalla mal sujeto.
  • Brillo y ángulo de visión, que sean los esperados.

Conectividad: WiFi, Bluetooth y LoRa

  • WiFi. Conéctate a una red y comprueba que navega. Verifica el alcance, ya que la carcasa puede apantallar la antena.
  • Bluetooth. Empareja un dispositivo y confirma que funciona.
  • LoRa TX. Transmite a un segundo nodo y confirma que recibe.
  • LoRa RX. Recibe un mensaje del segundo nodo y confirma que llega a la Pi.
  • Calidad de enlace. Anota RSSI/SNR. Un valor pobre con el nodo cerca delata problemas de antena.

Energía: batería, carga y autonomía

Aquí mides, no estimas:

  • Autonomía real. Carga al 100 %, usa el deck en un escenario representativo y cronometra hasta que se apague (o hasta el corte del BMS, Battery Management System, el circuito de protección del pack). Esa cifra es tu autonomía real, casi siempre menor que la teórica.
  • Carga. Conecta el cargador y confirma que la batería carga y que el sistema puede funcionar mientras carga si así lo diseñaste. Comprueba que la carga termina (no sobrecarga).
  • Tensiones bajo carga. Con el multímetro, verifica que el buck mantiene los 5 V con la Pi a plena carga. Si caen, la Pi reportará bajo voltaje.
  • Comportamiento al vaciarse. Confirma que el BMS de la 2S corta antes de descargar peligrosamente las celdas. No fuerces este test hasta el daño; basta con ver que protege.

Térmica: temperaturas en régimen estable

El calor es un problema de tiempo, no de instante:

  • Somete la Pi a carga sostenida varios minutos (un test de estrés de CPU) con la carcasa cerrada.
  • Vigila vcgencmd measure_temp. Debe estabilizarse por debajo de 80 °C. Si trepa hacia 85 °C, el sistema hará throttling y pierdes rendimiento: tu refrigeración es insuficiente.
  • Comprueba que el ventilador acelera con la temperatura y que la batería no se calienta (no debe estar cerca de la fuente de calor).
  • Revisa que vcgencmd get_throttled no reporte eventos de throttling tras la prueba.

Mecánica: carcasa sin holguras ni crujidos

El acabado mecánico distingue un prototipo de un producto:

  • Sacude el deck suavemente cerca del oído: nada debe sonar suelto dentro.
  • Aprieta y flexiona ligeramente la carcasa: no debe crujir. Un crujido indica piezas que rozan o tornillos flojos.
  • Holguras. Revisa que las tapas cierran a ras, sin escalones ni huecos por los que se vea el interior.
  • Puertos. Conecta y desconecta cada puerto externo: deben entrar firmes, alineados, sin forzar.
  • Strain relief. Da un tirón suave a cada cable externo: no debe transmitirse a la electrónica interna.

Documentar los resultados

Apunta cada resultado en la checklist con su cifra (autonomía en minutos, temperatura estable en grados, RSSI). Esos números son el estado base de tu build. Cuando iteres al segundo, compararás contra ellos y sabrás si has mejorado de verdad o solo te lo parece.

La regla del QA

Un fallo encontrado en el banco cuesta un destornillazo; el mismo fallo encontrado por un cliente cuesta tu reputación. No declares el deck terminado hasta que cada punto de la lista esté en verde. El QA no es burocracia: es lo que separa un cacharro que a veces funciona de un equipo en el que confías.

Del blog al libro Este post forma parte del temario de Guía del constructor de cyberdecks. El libro completo incluye el capítulo de UX y dotfiles, el árbol de alimentación paso a paso y los scripts del repo complementario.

Ver el libro

En construcción

Estamos preparando algo. Vuelve pronto.

Newsletter gratis

Novedades y montajes.

Directo a tu correo.

Sin spam.

Sin anuncios.

Al suscribirte aceptas recibir correos del taller. Puedes darte de baja cuando quieras.

Síguenos