Eu trabalho em uma empresa de médio porte (150 funcionários, ~ 10 equipes de engenharia de tamanho), e a maioria dos meus projetos envolve a interface com equipamentos de laboratório (osciloscópios, analisadores de espectro óptico, etc.) para fins de aplicações de teste semi-automatizadas. Encontrei alguns cenários diferentes em que não consigo solucionar problemas ou testar com eficiência o novo código, porque eu não tinha mais ou nunca tinha a configuração de hardware disponível para mim.
Exemplo 1: Uma configuração em que 10 a 20 processos de "queima" são executados independentemente, usando um sensor do tipo bancada - eu consegui obter um desses sensores para testes e, ocasionalmente, poderia roubar um segundo para simular todas as facetas da interface para vários dispositivos (pesquisando, conectando, transmitindo, etc.).
Eventualmente, um bug apareceu (e finalmente acabou no firmware e nos drivers do dispositivo) que era muito difícil de reproduzir com precisão com apenas uma unidade, mas atingia os níveis "show stopper" quando 10-20 desses dispositivos estavam em uso simultaneamente. Isso ainda não foi resolvido e está em andamento.
Exemplo 2: Um teste que requer um analisador de espectro óptico caro como seu componente principal. O dispositivo é bastante antigo, herdado de acordo com o fabricante que foi adquirido por uma empresa maior e basicamente dissolvido, e sua única documentação era um documento longo (e pouco informativo) que parece mal traduzido. Durante o desenvolvimento inicial, eu pude manter o dispositivo em minha mesa, mas agora está ligado, tanto fisicamente quanto dentro do cronograma, durante os testes de 24 horas por dia, 7 dias por semana.
Quando os bugs aparecem relacionados ou não ao dispositivo, muitas vezes preciso passar pelo problema de testar código externo ao aplicativo e ajustá-lo, ou escrever código cegamente e tentar diminuir o tempo de teste entre as execuções, tanto quanto a lógica do programa exige que o OSA e o restante do hardware de teste estejam no local.
Acho que minha pergunta é como devo abordar isso? Eu poderia potencialmente gastar tempo desenvolvendo simuladores de dispositivos, mas entender isso na estimativa de desenvolvimento aumentará mais do que a maioria provavelmente gostaria. Também pode não reproduzir com precisão todos os problemas, e é muito raro ver o mesmo equipamento usado duas vezes por aqui. Eu poderia melhorar nos testes de unidade ... etc ... Eu também poderia falar alto sobre o problema e fazer com que outras pessoas entendessem que serão necessários atrasos temporários, não muito mais do que uma dor de cabeça para Pesquisa e Desenvolvimento, mas geralmente uma brincadeira. quando lançado para a fabricação.