Esse tipo de teste seria melhor feito de fato. O problema é que isso deve ser feito por testadores, não por desenvolvedores . Nesse sentido, não é seu trabalho nem o de desenvolvedor de bibliotecas.
Pelo que você descreve, parece que não há testadores no projeto - se esse for o caso, é um problema de gerenciamento e bastante sério.
... economiza tempo, pois eles podem ler o código fonte das bibliotecas para determinar se a funcionalidade necessária está disponível
Raciocínio bastante manco. Quando a biblioteca de versões mais recente falha ao compilar com o projeto de versão mais recente, pode haver várias razões para isso - apenas pesquisar o código-fonte lib pode ser uma perda de tempo.
- E se a biblioteca estiver OK e a falha de compilação foi causada pelo erro no código do projeto? Ou, se a falha de compilação foi causada por uma mudança temporária incompatível que deveria ser corrigida um ou dois dias depois? E se uma falha de construção indicar um problema de integração complicado que levará uma semana ou mês para resolver? Para um problema de integração, o uso de uma biblioteca de versão anterior seria uma solução alternativa ou não?
Qualquer que seja o motivo, fazer uma análise preliminar da falha significaria desperdiçar o tempo do desenvolvedor em um trabalho que deveria ser feito pelos testadores.
Outra coisa acima do raciocínio esquecido é inevitável (e bastante dolorosa na minha experiência) as perdas de produtividade que se seguem quando é preciso interromper o fluxo alternando entre atividades de desenvolvimento e controle de qualidade.
Quando há testadores na equipe, essas coisas são realmente simples e podem ser tratadas com muito mais facilidade. O que seu desenvolvedor "sênior" lançou para você é basicamente um requisito de teste preliminar.
Após todas as alterações feitas no projeto ou na biblioteca, verifique se a compilação foi bem-sucedida.
As etapas a seguir são atividades típicas de controle de qualidade: esclarecer detalhes de requisitos, projetar um cenário de teste formalizado, negociar como lidar com falhas de teste.
- Da perspectiva do SQA , essa é uma tarefa rotineira de projetar, configurar e manter um procedimento de teste de regressão bastante simples que pode ser altamente automatizado - provavelmente até o ponto em que apenas a atividade manual criaria e manteria tickets no rastreador de problemas e verificação de Conserta.