Como solucionar problemas ou testar com eficiência um novo código quando é difícil ou impossível obter a configuração do hardware para reproduzir bugs?

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.

A gerência entende que levará mais tempo para desenvolver e manter o software quando você não tiver acesso total ao hardware de teste. Você precisa levar isso em consideração ao fazer suas estimativas. Parte dos critérios de aceitação para colocar seu software em produção deve ser que você tenha uma maneira de manter o software na maioria das circunstâncias, sem interromper a fabricação. Se você estiver praticando TDD, isso deve acontecer naturalmente.

Eu costumava escrever software para aeronaves de US $ 60 milhões. Obviamente, é necessário um alto grau de confiabilidade e eles relutam em dar a cada desenvolvedor um para sua mesa. Basicamente, tínhamos 5 níveis de ambientes de teste, com mais hardware real em cada nível, até uma aeronave completa. Eu estimo que 95% do nosso software possa ser desenvolvido e depurado apenas com emuladores e testes de unidade. 95% dos recursos restantes poderiam ser trabalhados no próximo nível, e assim por diante.

Tente configurar níveis semelhantes de ambientes de teste para si mesmo. Você não pode esperar nunca precisar acessar o hardware real, mas se você o configurou para não trabalhar na GUI do seu software sem o hardware disponível, estará perdendo um tempo valioso em um recurso caro (não para mencione que você tem alguns problemas de acoplamento com sua arquitetura). Considere que outros desenvolvedores provavelmente têm os mesmos problemas que você. Gostaria de perguntar ao fornecedor de hardware se ele já possui emuladores ou outros recursos de teste disponíveis.

Você também precisa mudar um pouco a sua mentalidade se tiver apenas acesso limitado ao hardware. Em vez de tentar depurar seu aplicativo da maneira serial normal, geralmente você precisa escrever um código especificamente para coletar informações o mais rápido possível.

Por exemplo, talvez você tenha um bug e consiga pensar em 10 causas possíveis. Se o único momento em que você pode entrar em uma máquina são 15 minutos enquanto o operador está em pausa, escreva um Exemplo breve, autocontido, correto (compilável) que desencadeie o erro e escreva 10 testes automatizados usando esse SSCCE para testar suas teorias e registre um monte de dados. Depois, de volta à sua mesa, você pode levar o tempo necessário para examinar os dados para sua próxima tentativa. A idéia é maximizar a utilidade do seu tempo limitado com o hardware.

Você está tentando resolver um problema que não é seu a resolver.

A gerência precisa priorizar o acesso ao equipamento. Isso pode significar que você acaba com maior acesso, mas também pode significar que você acaba com menos.

Apresente os desafios que você tem em um formato objetivo à sua equipe de gerenciamento e peça orientação. Sua apresentação seria muito mais forte se você colaborasse com outras pessoas que também precisam de acesso, para que todos possam apresentar seu caso ao mesmo tempo.

A partir daí, a empresa (gerência) deve priorizar quem obtém acesso e quando. É uma decisão de negócios que eles precisam tomar, pois a (falta de) disponibilidade dos recursos está afetando o desenvolvimento dos negócios.

Você está efetivamente codificando cegos.

Se o gerenciamento não pagar pelos dispositivos de teste, há uma alta probabilidade de erros, ou mesmo o desenvolvimento demorando mais do que custaria se você tivesse dispositivos reais para usar.

O custo dos dispositivos não precisa ser completamente alocado para o ciclo de "desenvolvimento". Talvez eles possam ser alternados para uso em produção ou como backup. Eles poderiam ser revendidos em segunda mão em outro lugar?

Experimente e custe as fases de correção de erros, em tempo e dinheiro, e mostre o custo total para sua equipe / empresa.

Discutir com seus chefes é muito mais fácil quando você tem alguns números, ou pelo menos alguns prós e contras, então minha sugestão é tentar fazer uma análise de custo x benefício. A idéia aproximada é assim:

• quanto esforço de desenvolvimento você espera para escrever um simulador de dispositivo? (Observe que um simulador de dispositivo não pode substituir o hardware original 100%, especialmente quando o hardware apresenta algumas peculiaridades inesperadas).

• quanto esforço de teste / depuração você espera sem essa ferramenta? Inclua os custos para os funcionários do laboratório, pois você deve bloquear o hardware para fins de teste. Inclua também os custos pelo tempo em que o sistema não puder ser usado devido a erros e você terá problemas para encontrar a causa raiz.

• quanto custará o hardware adicional para testes?

• quanto tempo você espera que precisará bloquear o hardware para fins de teste?

Obviamente, a realidade pode não ser tão simples, e há muitas variáveis ​​desconhecidas nessa equação, mas tente fazer algumas estimativas e, em caso de dúvida, pergunte a outras pessoas do seu ambiente.

Apresente os resultados à sua gerência, discuta as alternativas e deixe-as decidir.