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?

30

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.

plast1k
fonte
5
um simulador de dispositivo (ou interface mockable) se pagará apenas na conveniência
catraca aberração
21
@ratchetfreak - como quem passa os dias simulando dispositivos (trabalho em um simulador de dispositivos médicos em tempo integral), garanto-lhe que mesmo uma simulação de baixa fidelidade do equipamento de outra pessoa pode ser uma tarefa MUITO difícil, dependendo do conexões, protocolos e tipos de dados envolvidos. Se o equipamento de teste usado pelo OP for parecido com o equipamento com o qual tenho de lidar, pode levar dias ou semanas cutucando-o para descobrir o que a coisa sangrenta está REALMENTE fazendo (em oposição ao que as especificações dizem). Portanto, não é de todo uma conclusão precipitada que um simulador vale a pena.
Michael Kohne

Respostas:

35

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.

Karl Bielefeldt
fonte
Aceitei esta resposta como a mais completa - e acho que um bom equilíbrio de "conscientizar a gerência" com "mudar suas práticas". Acho que vale a pena gastar algum esforço em melhores níveis de dissociação e algum nível de simuladores de hardware, e posso mostrar isso nas minhas estimativas. Também gosto especialmente das dicas de alguns testes rápidos e completos que capturam muitos dados durante a depuração - obrigado.
Plast1k
14
Eu parei de ler depois de "A Administração entende"
PlasmaHH
11
"Relutante em dar a cada desenvolvedor um pela sua mesa". Ironicamente, você provavelmente poderia dobrar os números o suficiente para provar que dar a cada desenvolvedor seu próprio avião de US $ 60 milhões para trabalhar seria mais barato do que o custo acumulado total de um desastre de uma companhia aérea!
Sr. JavaScript
15

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.


fonte
4
Uma coisa que pode ajudar a conversar com a gerência é predicar suas agendas (ou marcos) no acesso ao equipamento. Você só pode fazer isso sem o hardware à sua frente e, se deixar claro que a estimativa é a partir de quando a entrega é feita, o gerenciamento pode tomar decisões com todo o conhecimento.
Michael Kohne
4

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.

ozz
fonte
4

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.

Doc Brown
fonte
Eu acho que você quis dizer não pode aqui Note que um simulador de dispositivo pode raramente substituir o hardware original de 100%, especialmente quando o hardware tem algumas peculiaridades inesperadas
Rémi
@ Rémi: talvez "raramente" não seja a ordem usual de palavras no inglês comum? FWIW, mudei minha resposta para tornar isso inequívoco, obrigado pela resposta.
Doc Brown
Eu não falo inglês nativamente, mas é estranho. obrigado
Rémi