Teste automatizado: explicando seu valor comercial

Para começar, não acho que isso seja uma repetição de outras perguntas sobre testes de unidade . Estou procurando ajuda para articular seu valor a uma equipe de programadores, analistas, gerentes e testadores. Por testes automatizados, acho que não preciso fazer uma distinção entre testes de unidade (por exemplo, JUnit), BDD (por exemplo, JBehave, Fitness) e interface do usuário (Selenium, Watir) porque acho que todos eles fornecem valor semelhante (mas sinta-se à vontade para escreva uma resposta que discorde :))

A seguir está uma lista que identifiquei, estou procurando respostas que ajudem a expandir ou refinar:

1. Economia de tempo / custo : escrever testes automatizados pode levar mais tempo do que casos de teste escritos. No entanto, considerando que os testes são executados várias vezes, o trabalho marginal (ou seja, custo / tempo) para executar testes automatizados é várias ordens de magnitude a menos. O fato de os testes automatizados serem baratos facilita a alteração do sistema ao longo do tempo.
2. Documentação : não há maneira mais verdadeira de saber como um sistema funciona do que seus testes. Qualquer outra documentação geralmente está desatualizada no momento em que é escrita, mas os testes (pelo menos os que passam) revelam como as coisas realmente funcionam. Isso vale para a documentação do usuário final E da API.
3. Qualidade do código : a escrita de teste obriga a:
   • considere clientes porque os testes são um cliente
   • quebra dependências nas quais tornar o código testável geralmente significa descobrir como fazer com que esse código não exija que outro sistema grande esteja disponível

Alguns dos meus pensamentos:

1. Seja honesto que escrever testes automatizados levará mais tempo. Se você estiver usando TDD no nível da unidade (o que eu recomendaria como ponto de partida para investir em testes automatizados), você pode esperar cerca de 30% de tempo extra necessário para codificar um recurso. A chave aqui é explicar que esses 30% extras (que provavelmente são maiores que 30% no início, conforme sua equipe aprende a escrever bons testes) são um investimento criado para economizar custos ao longo do tempo. Como o TDD no nível da unidade, o design do seu sistema é fracamente acoplado e altamente coeso, o que torna seu sistema adaptável às mudanças ao longo do tempo. Novos requisitos e bugs inesperados sempre exigem alterações no seu sistema,
2. Há muito debate sobre o valor dos testes de nível de aceitação e nível de interface do usuário, dado o tempo necessário para escrever esses testes, quanto tempo leva para executá-los e quanta manutenção eles exigem. Eu recomendo a leitura deste artigo de James Shore sobre isso.
3. No mundo dos testes automatizados, existem boas e más maneiras de fazê-lo. Se você estiver enviando testes automatizados para sua gerência, eu mostraria como você planeja treinar sua equipe para escrever bons testes. The Art of Unit Testing de Roy Osherove, Working Effective With Legacy Code de Michael Feathers e The Art of Agile Development de James Shore são ótimos livros que lidam com esses tópicos direta ou indiretamente. Você também deve procurar algum tipo de treinador ou treinamento formal também. É uma grande mudança.
4. Em termos de valor comercial, os nºs 2 e 3 dos seus pontos acima realmente atendem ao seu primeiro ponto; portanto, enfatizo o ponto 1 e falo sobre como os pontos 2 e 3 servem para esse ponto maior. A documentação torna seu sistema mais compreensível, o que torna sua equipe mais rápida. A qualidade do código torna seu sistema adaptável às mudanças, o que faz sua equipe trabalhar mais rapidamente. Para as pessoas de negócios, trata-se de maximizar o fluxo de valor desde o momento em que uma ideia é lançada até o momento em que é entregue como um software em funcionamento.

Uma coisa de valor definido é que testes automatizados podem ser executados continuamente; como a cada hora em uma reconstrução ou similar. Isso força qualquer bug ou regressão a ser aberto rapidamente dentro de horas ou dias de um programador trabalhando no código incorreto, isso facilita muito a troca de contexto. O segundo benefício do teste contínuo é que ele o força a mantê-lo em um estado de funcionamento; nada é mais entediante do que passar a primeira semana de um ciclo de testes consertando todos os testes desatualizados. Se você pode automatizá-los, pode executá-los a qualquer momento e, executando-os regularmente, pode detectar bugs em seus testes ou código rapidamente.

Despesas de teste

Uma vez que um teste automático é escrito, ele pode ser executado por um computador ao custo de alguns joules. O teste manual equivalente exige que uma pessoa na folha de pagamento elabore uma lista de instruções.

Confiabilidade do teste

O computador pode ser confiável para executar fielmente o mesmo procedimento de teste, sempre. O humano é capaz de cometer erros e ficar com preguiça.

Os modos de falha de teste do computador também são muito mais aparentes - travaram (os relatórios de teste param de aparecer), ocorreu um pequeno erro que causou um resultado falso (execute um teste determinístico novamente e o resultado difere). Se um humano falha um passo e marca o "OK", como podemos saber?

Durabilidade do teste

Um teste automatizado precisa ser um artefato concreto (por exemplo, um pedaço de código) para ser executado e é naturalmente incluído com os outros artefatos de desenvolvimento de software - o repositório de origem. Um teste manual pode ser desenvolvido em uma folha de papel de nota por um testador e nunca formalizado. É mais provável que os negócios precisem de processos para garantir que isso não aconteça.

Valor do teste

O computador pode ser programado para gerar resultados de teste de forma consistente e facilmente analisada. A pessoa está fazendo a entrada de dados para gerar o mesmo ou está gravando notas de forma livre que exigem um analista, desenvolvedor ou gerente para digerir.

Principalmente (dependendo da sua cobertura de teste), código livre de erros, e eu diria que um dos maiores argumentos é quando você diz ao seu gerente que pode escrever um teste para um bug descoberto, garantindo que você sempre saberá no futuro se esse bug volta :)

Minha opinião é que os testes de unidade / integração são mais importantes, enquanto se você aplicar algum padrão de interface do usuário como o MVC, é suficiente para a maioria dos projetos. Normalmente, testo todas as ações em meus controladores / apresentadores e deixo a ligação de dados nas Views.

Obviamente, o teste automatizado não substitui o bom ponto antigo e clica em aventuras em torno de seu aplicativo, tentando descobrir as coisas mais loucas que seu usuário poderia fazer.

Há também um ponto de integração contínua .

Mais uma coisa - é preciso esforçar-se para que a qualidade do código leve à qualidade do produto, valor comercial e capacidade de manutenção - caso contrário, não faz sentido fazê-lo.

Eu acho que você deve liderar com os pontos mágicos de "menor custo" e "mais recursos / tempo unitário" / menor tempo de ciclo.

No entanto, antes de fazer um caso, aconselho a refletir sobre sua situação. Sua pergunta me levou a escrever uma postagem no blog sobre os possíveis contras de testes automatizados.

A facilidade de refatoração é um grande fator aqui. Tendo uma boa cobertura por um bom e READABLE (!!!) teste de unidade, você pode refatorar seu sistema sem ficar nervoso por comprometer a funcionalidade existente.

Você precisa vender o conceito - você precisa evitar dizer a eles que isso melhorará o código. Se eles tiverem algum investimento no código que os colocará imediatamente contra você / teste automático. Se eles são bons, eles também entenderão o GIGO, portanto não entenderão por que você acha que ele não se aplica.

Eu deixaria de vendê-lo também como aspecto de documentação, coisas como o Fitnesse podem fazê-lo bem, mas até que eles experimentem pode ser difícil de visualizar.

Áreas que acho que podem ter sorte em vendê-lo

1. Os testes de unidade podem substituir muitos chicotes de desenvolvedores - onde você cria um aplicativo apenas para acessar a área para depuração / teste sem passar por todos os menus / login.

2. Os testes permitem que você configure e repita facilmente situações de problemas - sem gastar muito tempo configurando dados de teste (especialmente usando um sistema de simulação decente)

3. À medida que você cria conjuntos de testes de BDD e UI - você obtém uma resposta muito mais rápida se houver pausas simples do que aguardar na próxima vez em que o testador olhar para ele

4. Os testes de BDD e interface do usuário podem evitar que você pressione repetidamente os botões para verificar todos os aspectos que podem ter sido afetados por sua alteração e evitar que você lembre todas as áreas.

5. As compilações automáticas geralmente são destacadas quando alguém se esquece de fazer o check-in do código

6. Os testes ajudam a evitar erros que reaparecem.

7. Testes de unidade e zombaria decente significarão menos código interligado e serão mais fáceis de resolver

Lembre-se de que você está tentando vendê-lo, não convertê-los em religião - então aceite pequenos passos e tente não convencê-los. Também levará tempo para eles se ajustarem e aprenderem a escrever bons testes.

Alguém deve acreditar que há um problema antes de aceitar uma solução proposta para esse problema.

Os testes automatizados podem economizar custos de correção de erros; portanto, se seus colegas não acreditarem que os custos de correção de erros são consideráveis ​​ou excessivos, será difícil convencer. Se esses custos são altos ou excessivos, mas as pessoas não acreditam, é necessário primeiro obter dados convincentes sobre esses custos.

O que as empresas adoram é aumentar valor e reduzir custos. Você precisa explicar como o teste automatizado aumentará o valor, uma vez que adiciona um custo extra.

Se o seu código for modular, será possível reutilizá-lo. O que significa que os testes não precisam ser escritos novamente e você pode apenas trabalhar com o código existente.

Se houver projetos herdados, o teste automatizado facilita muito a refatoração. A dívida técnica deve ser paga em algum momento.

O argumento da documentação que você fornece não é muito bom. A diferença entre manter os testes atualizados e a documentação atualizada é apenas um hábito.

"O que estou procurando ajuda é articular seu valor a uma equipe de programadores, analistas, gerentes e testadores. Por testes automatizados, acho que não preciso fazer uma distinção entre testes de unidade (por exemplo, JUnit), BDD ( por exemplo, JBehave, Fitness) e UI (Selenium, Watir), porque acho que todos eles fornecem valor semelhante (mas fique à vontade para escrever uma resposta que discorde :)) "

OK, eu vou aceitar esse desafio;)

Trabalho principalmente com programadores e controle de qualidade e minhas ferramentas são ruby, rails, testunit, rspec, jasmim e selênio.

As ferramentas BDD / TDD do rspec e testunit fazem parte da programação. Você não os quebra e fala sobre eles separadamente para a gerência, não os adia por falta de tempo, inclui-os em todas as suas estimativas de tempo. Se realmente for perguntado quanto tempo as pessoas têm para você explicar a ciência da computação e a programação para elas. Eu não uso esses testes para o front end

GUI / UI / Jasmine / Selênio. Estes são diferentes. Eu já fiz isso por pessoas de controle de qualidade que têm formação em programadores. Garantimos que os testes sejam escritos para serem o mais robustos possível e com base no conteúdo, não no layout. O (possivelmente novo) custo disso deve ser explicado como um custo alterado . Em vez de pagar com software quebrado, clientes perdidos e correções caras depois, você paga muito menos (relativamente) agora com algumas práticas simples.

Eu acho que a chave é falar sobre categorias específicas de testes que você criará, não sobre 'testes automatizados' como um todo. O último pode ser um pouco nebuloso e preocupante, e é muito fácil criar exemplos de onde seria perda de tempo.

Eu sempre recomendo dividir seus testes em 4 grupos (mais detalhes aqui ). Fique comigo aqui, vou entender como isso ajuda você a vender testes para outras pessoas em um momento.

1. Testes de sua funcionalidade principal . Ou seja, para uma ferramenta de monitoramento de sites, seriam testes de alertas que devem ser disparados para sites que você está monitorando. Esses testes garantem que esse material nunca quebre.
2. Testes de fumaça de toda a sua aplicação . Por exemplo, usando o Selenium para navegar em todos os links / botões em um aplicativo Web e verifique se não há erros no servidor. Esses testes evitam que você perca tempo com as construções obviamente quebradas.
3. Testes de qualquer código frágil . Ou seja, para o antigo módulo que ninguém quer tocar, ou o complexo pedaço de código que parece sempre ter bugs.
4. Testes que os desenvolvedores queriam escrever para apoiar seu trabalho . Às vezes, os testes são úteis quando você está escrevendo algo, mas não se enquadram nas categorias acima.

Ao dividir seus testes nessas categorias, agora você pode ter uma discussão diferente. Pegue os três primeiros grupos (o quarto fica a critério dos indivíduos) e pergunte se as pessoas pensam que os testes para esses trechos de código valeriam a pena. Se você não conseguir um acordo, talvez não inclua esses testes por enquanto. Se você puder, ou seja, se as pessoas concordarem que os testes em torno das principais funcionalidades executadas em cada confirmação são úteis, comece a adicioná-los.

O outro grupo que pode ser útil são os testes difíceis ou demorados para serem feitos manualmente . Deve haver aqui um benefício bastante fácil de explicar em termos de economia de tempo de teste manual ou de teste de itens ignorados por falta de tempo.