Como posso iniciar o teste em uma anticultura de teste? [fechadas]

Tenho uma confissão a fazer: O teste automatizado formalizado nunca fez parte do meu plano de programação. Agora eu trabalho em uma grande empresa com muitos desenvolvedores (a maioria deles web desenvolvedores de um tipo ou outro), e é evidente que a maioria deles não fazer test * também. (* Não vou continuar dizendo formalmente ; por favor, deduza.)

Se eu esperar o apoio da minha organização para começar a testar, isso nunca acontecerá. Se eu tentar "mudar as coisas de dentro" pressionando os testes na gerência, ficarei sem energia antes que as mudanças aconteçam. Preciso começar a testar agora.

Porém, com o TDD e seu tipo, vou acabar com muitos códigos de teste junto com o código de produção. Nossos sistemas de controle de versão (todos centralizados) não estão organizados para armazenar o código de teste. Vou ter que encontrar um lugar para tudo isso na minha estação de trabalho.

É possível iniciar uma prática pessoal de teste de software em uma cultura que não valoriza ou fornece as ferramentas para isso? Quais técnicas e ferramentas você usa para permitir que você teste quando as ferramentas e a organização oficiais não têm lugar para testes, estruturas e automações?

Eu pessoalmente fiz isso com um sucesso considerável. Os principais fatores para o sucesso:

• Obtenha suporte (provisório) de gerenciamento. As vantagens dos testes de automação estão bem documentadas e devem convencer qualquer gerente a pelo menos experimentá-lo. Isso inclui encontrar um ponto no VCS e um servidor de compilação, porque
• Os testes automatizados somente fornecem seu valor total se forem executados com frequência e automaticamente, para que você saiba sobre os problemas em breve e não precise confiar nas pessoas que não se esquecem de executá-los. Você precisa de um servidor de construção que os execute pelo menos diariamente. Esta pode ser uma estação de trabalho antiga. Jenkins leva muito pouco trabalho para correr.
• Lidere pelo exemplo. Faça testes, fale sobre o benefício que eles estão fornecendo a você e, quando revelarem erros introduzidos por outros desenvolvedores, falem sobre isso em termos de como eles foram protegidos de vergonha potencialmente muito maior.
• Vá para a fruta baixa. Algumas partes do aplicativo serão difíceis de testar, outras fáceis. Alguns serão robustos, outros frágeis. Escrever testes para peças quebradiças, mas fáceis de testar, oferece o maior valor no menor tempo possível.
• Veja se você pode escrever testes reutilizáveis, por exemplo, convenções ou recursos de teste que todos os módulos (páginas da web, serviços REST, qualquer que seja) devem ter, mas que geralmente são esquecidos.

Sem suporte de gerenciamento, você está morto na água. A gerência alegará que você não está fazendo um trabalho que vale a pena, será penalizado em suas avaliações e, por fim, será demitido. Existem maneiras de levar a gerência a ver que os testes iniciais custam menos e tudo isso. É possível mudar a cultura, mas você está colocando o pescoço no bloco de corte.

Eu sugeriria a leitura do capítulo Maquiavel O Príncipe sobre como introduzir mudanças antes de fazer qualquer coisa.

Na minha experiência, se a cultura é anti-teste, você não pode apresentá-la razoavelmente. Os testes serão vistos como uma perda de tempo e você será repreendido por "perder tempo" ou "levar muito tempo", ou o código apodreceu após anos de não ter sido escrito de maneira testável (por exemplo, sem interfaces, tudo fortemente acoplados) e você precisará gastar muito tempo refatorando e / ou reescrevendo o código (correndo o risco de "levar muito tempo" e "desperdiçar tempo") para torná-lo testável para que você possa escrever testes em primeiro lugar .

Você pode ter uma chance se estiver fazendo coisas novas, que só precisam interagir com coisas existentes (criar um bom invólucro em torno das áreas ruins) ou se você puder fazê-lo em pequenas quantidades, onde não causará problemas ou exija que você "trabalhe em tarefas não atribuídas a você", que podem colocá-lo na casinha.

Eu não acho que você vá muito longe até que você possa argumentar suficientemente bem que há um problema (que atualmente não seja reconhecido) que o teste automatizado possa resolver.

Se houver uma cultura de teste manual em relação aos scripts definidos, haverá um custo de execução desses scripts, associado ao risco de resultados incompletos ou imprecisos. Pode haver uma história (documentada ou na forma de "história de guerra") disso. Sugira um projeto piloto para automatizar alguns desses testes manuais com o objetivo de proporcionar uma economia de custos a longo prazo.

Se não houver sequer uma função de teste manual, sugiro que a empresa não perceba que qualquer tipo de teste formal, automatizado ou não, tenha valor. Nesse caso, consideraria o caminho a seguir longo e íngreme, mas novamente é provável que precise de uma demonstração clara de que os negócios podem se beneficiar da adoção de uma abordagem menos casual da qualidade do software. Se você não pode fazer isso, é difícil ver como pode haver algum suporte para a ideia em termos comerciais.

Uma idéia é que você tente escrever um teste que comprove que o código que outra pessoa escreveu está com defeito. Deve vender o conceito.