Como popularizar os testes automatizados? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 2 anos .

Nossa base de códigos está crescendo há 20 anos. Somos cerca de 10 desenvolvedores + sqa trabalhando com 500kloc. Algum tempo atrás, uma pequena equipe de nós (2 desenvolvedores, um do sqa) começou a trabalhar em um programa de teste automatizado. Atualmente, uma execução leva 11h e é de alguma forma um teste de integração. Estamos trabalhando nisso para reduzir isso e reduzir os falsos positivos e estamos fazendo um bom progresso nisso. Mas os detalhes não devem importar.

Está funcionando bem e continuamos a melhorá-lo. Nós (a pequena equipe) gostamos muito. Se quebrarmos algo, notamos um dia depois e não dois meses depois, quando o sqa dá uma olhada. Além disso, nossos gerentes (dev + sqa) gostam da ideia. Mas outras pessoas na equipe simplesmente ignoram os resultados do teste. Na sua opinião, se os testes falharem após um check-in, é um problema do teste e não da alteração do código e é apenas o nosso projeto de brinquedo. Tivemos discussões várias vezes se um teste com falha é um erro real. Na maioria das vezes é.

Não podemos e não queremos impor algo. Como podemos mostrar que o teste automatizado é uma coisa?

testing integration-tests

— Peter Schneider
fonte

Este não é um problema de engenharia de software; é um problema das pessoas.

— Robert Harvey

@RobertHarvey Eu recebi votos negativos no SO porque "baseado em opiniões" e um comentário de que este site se encaixaria perfeitamente (e votos positivos nesse comentário). Então: onde devo perguntar? Eduque-me.

— Peter Schneider

Estou com @RobertHarvey sobre este ser um problema das pessoas. Mas, de acordo com o Local de trabalho, sua pergunta provavelmente será considerada um engano. Por exemplo, ver esta questão que é fundamentalmente o que você está pedindo workplace.stackexchange.com/questions/44964/...

— Peter M

Não deixe que aqueles que recusam (ou até votos próximos) o desanimam! Algumas pessoas podem entender que essas perguntas são importantes e talvez possam fornecer ajuda. A propósito, também meus colegas não veem a utilidade dos testes automatizados, apesar da versão anterior (sem testes automatizados) ser uma caixa de bugs. Basta mudar uma coisa e quebrar outras, coisas aparentemente não relacionadas. Algumas pessoas simplesmente não querem aprender (há uma resistência aberta contra o aprendizado de coisas novas).

— Bernhard Hiller

É uma pena que esta questão tenha sido encerrada. Se a engenharia de software significa alguma coisa, significa os problemas de trabalhar com pessoas reais, e as respostas para esses problemas envolverão opinião. Dito isto, algumas idéias rápidas: (1) se você testar dar falsos negativos, isso definitivamente aumentará a reação porque os resultados parecerão uma perda de tempo; (2) diminua o tempo de execução, se possível. 11 horas não parecem imediatas, mesmo que sejam muito melhores que dois meses; (3) o sqa adotará esses testes como métricas observadas. eles já são reconhecidos por sua organização nesta área.

— Dale Hagglund

Respostas:

aviso Legal

Embora eu possa parecer um gerente, escrevi isso como um desenvolvedor que também precisava ser convencido de que os testes automatizados são bons.

Você deve entender a psicologia básica dos desenvolvedores. É uma necessidade arraigada dos desenvolvedores para confirmar o código. Qualquer coisa que os impeça é algo muito, muito ruim. O teste reprovado é definitivamente algo que os impede de fazê-lo, portanto, é uma coisa ruim. Daí a resistência.

O que você deve ressaltar é que, embora os testes automatizados os reduzam a curto prazo, a longo prazo os poupará muito sofrimento e os acelerará, porque eles poderão se concentrar mais no desenvolvimento de coisas novas e perderá menos tempo fazendo a outra coisa que os desenvolvedores odeiam: corrigir bugs.

E sim, você deve aplicá-lo. Você deve obter o suporte incondicional do gerenciamento e tornar os testes automatizados de gravação obrigatórios e inegociáveis. Com o tempo, os desenvolvedores se acostumarão a eles. O que ajudará é se você puder conceber algumas métricas que mostrem quanto mais novos desenvolvimentos foram feitos e quanto o número de bugs foi reduzido desde a introdução dos testes automáticos. As palavras são voláteis. Os números são sólidos. E os números são algo que um desenvolvedor médio entende melhor do que palavras. Se você puder provar usando números sólidos que os testes automatizados são bons, obterá pouca ou nenhuma resistência a eles.

— Vladimir Stokic
fonte

Na sua opinião, se os testes falharem após um check-in, é um problema do teste e não da alteração do código e é apenas o nosso projeto de brinquedo. Tivemos discussões várias vezes se um teste com falha é um erro real. Na maioria das vezes é.

Esse é o seu problema. Se seus testes são inadequados (mesmo que sejam confiáveis "na maioria das vezes"), as pessoas tendem a ignorar os resultados. Sua equipe de automação deve se concentrar na eliminação desses falsos negativos. Somente então o restante da equipe ganhará confiança suficiente nos resultados para realmente confiar neles.

— Eternal21
fonte

Então, novamente, poderia ser outra coisa. Como resistência à mudança. Se um teste falhar, sempre há algo a ser corrigido, o código ou o teste, portanto a atitude de que as pessoas ignoram os testes porque os testes são inadequados é extraviada.

— Robert Harvey

Conversamos com eles quando tínhamos certeza de que algo estava quebrado (por exemplo, o teste falhou três vezes seguidas após o check-in afetar a funcionalidade em questão). Mas sim, aumentar a confiabilidade é a prioridade atual.

— Peter Schneider

@PeterSchneider, um teste pode falhar 100 vezes seguidas, o fará especialmente se o teste estiver errado.

— Pieter B

Por outro lado, um teste que nunca falha é mais provável completamente inútil

— Vladimir Stokic

Os testes +1 frágeis são definitivamente um problema. Os desenvolvedores devem estar convencidos de que os testes que escrevem são úteis, não apresentam complicações desnecessárias e não são trabalhosos .

— Andres F.

Não podemos e não queremos impor algo.

Você definitivamente deve aplicá-lo! Se alguém enviar um novo código e os testes falharem, o código deve ser rejeitado! É a única maneira de manter com segurança um projeto de software maior.

— Banan
fonte

Acho que depende do sistema, dos testes, da escala e do processo de desenvolvimento. Nem todos os erros podem ser resolvidos imediatamente, nem todos os problemas precisam ser resolvidos imediatamente.

— Nickl