¿Cómo solucionar problemas o probar nuevos códigos de manera eficiente cuando la configuración de hardware para reproducir errores es difícil o imposible de obtener?

Trabajo en una empresa mediana (150 empleados, equipo de ingeniería de tamaño ~ 10), y la mayoría de mis proyectos involucran la interfaz con equipos de laboratorio (osciloscopios, analizadores de espectro óptico, etc.) con el fin de aplicaciones de prueba semiautomatizadas. Me he encontrado con algunos escenarios diferentes en los que no puedo solucionar problemas o probar el nuevo código de manera eficiente porque ya no tenía o nunca tuve la configuración de hardware disponible.

Ejemplo 1: Una configuración en la que se ejecutan 10-20 procesos de "quemado" de forma independiente utilizando un sensor de tipo de sobremesa. Pude obtener uno de esos sensores para probar y ocasionalmente pude robar un segundo para simular todas las facetas de la interfaz para múltiples dispositivos (búsqueda, conexión, transmisión, etc.).

Finalmente, apareció un error (y finalmente terminó en el firmware y los controladores del dispositivo) que era muy difícil de reproducir con precisión con solo una unidad, pero alcanzó niveles cercanos al "show stopper" cuando 10-20 de estos dispositivos estaban en uso simultáneamente. Esto aún no se ha resuelto y está en curso.

Ejemplo 2: Una prueba que requiere un costoso analizador de espectro óptico como componente central. El dispositivo es bastante antiguo, heredado según el fabricante que fue adquirido por una empresa más grande y básicamente se disolvió, y su única documentación fue un documento sin aliento (y poco informativo) que parece mal traducido. Durante el desarrollo inicial pude mantener el dispositivo en mi escritorio, pero ahora está atado, tanto físicamente como en el horario durante sus pruebas de varias semanas, las 24 horas, los 7 días de la semana.

Cuando aparecen errores relacionados o no relacionados con el dispositivo, a menudo necesito pasar por el problema de probar código externo a la aplicación y ajustarlo, o escribir código a ciegas e intentar exprimir un poco de tiempo de prueba entre ejecuciones, tanto La lógica del programa requiere que el OSA y el resto del hardware de prueba estén en su lugar.

Supongo que mi pregunta es ¿cómo debería abordar esto? Potencialmente podría pasar tiempo desarrollando simuladores de dispositivos, pero deducir que en la estimación de desarrollo aumentará más de lo que la mayoría probablemente apreciaría. Es posible que tampoco reproduzca con precisión todos los problemas, y es bastante raro ver el mismo equipo utilizado dos veces por aquí. Podría mejorar en las pruebas unitarias ... etc ... También podría hablar en voz alta sobre el tema y hacer que otros entiendan que se requerirán demoras temporales, no mucho más que un dolor de cabeza para Investigación y Desarrollo, pero generalmente se percibe como una broma cuando se lanzó a la fabricación.

La gerencia entiende que llevará más tiempo desarrollar y mantener software cuando no tenga acceso completo al hardware de prueba. Debe tener esto en cuenta al hacer sus estimaciones. Parte del criterio de aceptación para poner su software en producción debe ser que tenga una manera de mantener el software en la mayoría de las circunstancias sin detener la fabricación. Si está practicando TDD, esto debería suceder de forma bastante natural.

Solía ​​escribir software para aviones de $ 60 millones. Obviamente, se requiere un alto grado de confiabilidad, y son reacios a dar a cada desarrollador uno para su escritorio. Básicamente teníamos 5 niveles de entornos de prueba, con más hardware real en cada nivel, hasta un avión completo. Calculo que el 95% de nuestro software podría desarrollarse y depurarse solo con emuladores y pruebas unitarias. El 95% de las características restantes podrían funcionar en el siguiente nivel, y así sucesivamente.

Intente configurar niveles similares de entornos de prueba para usted. No puede esperar nunca necesitar acceso al hardware real, pero si lo configuró para que no pueda trabajar en la GUI de su software sin el hardware disponible, está desperdiciando un tiempo valioso en un recurso costoso (no mencionar que tiene algunos problemas de acoplamiento con su arquitectura). Considere que otros desarrolladores probablemente tengan los mismos problemas que usted. Le preguntaría al vendedor de hardware si ya tienen emuladores u otros recursos de prueba disponibles.

También debe cambiar su mentalidad si solo tiene acceso limitado al hardware. En lugar de tratar de depurar su aplicación de la manera en serie normal, a menudo necesita escribir código específicamente con el fin de recopilar información lo más rápido posible.

Por ejemplo, quizás tengas un error y puedas pensar en 10 posibles causas. Si el único momento en que puede subirse a una máquina son los 15 minutos mientras el operador está en pausa, escriba un ejemplo breve, autocontenido, correcto (compilable) que active el error y escriba 10 pruebas automatizadas utilizando ese SSCCE para probar sus teorías y registrar un montón de datos. Luego, de vuelta en su escritorio, puede tomar el tiempo que necesite para examinar los datos para su próximo intento. La idea es maximizar la utilidad de su tiempo limitado con el hardware.

Estás tratando de resolver un problema que no es tuyo.

La gerencia necesita priorizar el acceso al equipo. Eso puede significar que terminas con un mayor acceso, pero también puede significar que terminas con menos.

Presente los desafíos que tiene en un formato objetivo a su equipo directivo y pídales orientación. Su presentación sería mucho más fuerte si colaborara con los demás que también necesitan acceso, para que todos puedan presentar su caso al mismo tiempo.

A partir de ahí, la empresa (administración) debe priorizar quién tiene acceso y cuándo. Es una decisión comercial que deben tomar ya que la (falta de) disponibilidad de los recursos está impactando el desarrollo del negocio.

Estás efectivamente codificando a ciegas.

Si la administración no paga por los dispositivos de prueba, entonces hay una alta probabilidad de errores, o incluso el desarrollo demorará más de lo que lo haría si tuviera dispositivos reales para usar.

El costo de los dispositivos no necesita ser completamente asignado al ciclo de "desarrollo". Tal vez podrían rotarse para uso de producción, o como respaldo. ¿Podrían incluso ser revendidos de segunda mano en otro lugar?

Pruebe y cueste las fases de corrección de errores, tanto en tiempo como en dinero, y muestre el costo general a su equipo / empresa.

Discutir con sus jefes es mucho más fácil cuando tiene algunos números, o al menos algunos pros y contras a la mano, por lo que mi sugerencia es tratar de hacer un análisis de costo versus beneficio. La idea aproximada es así:

• ¿Cuánto esfuerzo de desarrollo espera para escribir un simulador de dispositivo? (Tenga en cuenta que un simulador de dispositivo no puede reemplazar el hardware original al 100%, especialmente cuando el hardware tiene algunas peculiaridades inesperadas).

• ¿Cuánto esfuerzo de prueba / depuración espera sin tal herramienta? Incluya los costos para sus trabajadores de laboratorio porque tiene que bloquear el hardware para fines de prueba. Incluya también los costos por el tiempo que el sistema no se puede usar debido a errores y tiene problemas para encontrar la causa raíz.

• ¿Cuánto costará el hardware adicional para las pruebas?

• ¿cuánto tiempo espera que necesite bloquear el hardware para realizar pruebas?

Por supuesto, la realidad puede no ser tan simple, y hay muchas variables desconocidas en esta ecuación, pero trate de hacer algunas estimaciones y, si no está seguro, pregunte a otras personas de su entorno.

Presente los resultados a su gerencia, discuta las alternativas y luego déjelos decidir.