O título diz tudo. Alguns funcionários de nossa empresa acreditam que os testes automatizados são "fáceis" e que "deve levar um dia" para escrever conjuntos de testes COM e UI. O que pode ser feito para combater isso?
Nota: Não estou perguntando sobre como promover a automação. Esse não é o problema. Testes e processos automatizados estão sendo promovidos e solicitados o tempo todo aqui. A questão é que algumas pessoas não entendem que a automação não é "fácil" nem "rápida".
project-management
quality
automation
joshin4colours
fonte
fonte
Respostas:
Da próxima vez que você receber uma solicitação, tente dividir o máximo do processo de automação em partes do tempo. Acho que quando percebem que são necessários 5 minutos por campo de texto ou por pressionar o botão, eles começam a perceber quanto tempo leva.
Por exemplo, talvez por que demore tanto tempo que eles comecem a introduzir interdependência entre os campos: por exemplo, permita que eles continuem se isso for preenchido, mas não se isso não for, exceto quando ...
Tente educá-los sobre POR QUE leva tanto tempo, mas não tanto quanto você os perde através do processo de "aprendizado".
fonte
Em minhas funções, encontrei muitas pessoas "x é fácil", especialmente em projetos de desenvolvimento. Na minha opinião, existem três razões para isso:
1) Eles realmente não entendem do que estão falando, mas gostam muito de soar como eles.
2) Eles leram alguns livros e acham que sabem do que estão falando
3) Por fim, as pessoas assumem que um computador está testando rápido, porque computadores são rápidos.
A maneira certa de combater isso é envolver os usuários regularmente, as estratégias de comunicação para os projetos são essenciais, certamente explicar os meandros dos testes automatizados para usuários não técnicos será inútil, mas conscientizá-los dos processos envolvidos pode ser benéfico. Você pode fazer isso através de documentação, workshops ou apenas um bate-papo amigável na próxima vez que passar.
Eu já vi um bacharelado destacar a pessoa mais barulhenta dessas pessoas "x é fácil" e simplesmente convidá-las para um dia no departamento, com o pensamento de que elas vão embora entendendo mais sobre o que você faz OU simples sair pensando "Deus, eu realmente não sei do que estou falando, acho que estava errado".
fonte
Software é o negócio de automatizar as coisas.
Escrevemos software para facilitar tarefas chatas, repetitivas e trabalhosas. Nós escrevemos software para automatizar a criação de relatórios, coleta de dados, comunicação com outras pessoas, etc. Escrever testes automatizados é realmente apenas escrever software para garantir que nosso outro software funcione da maneira que esperamos.
Se seus colegas de trabalho entenderem que escrever software é difícil e leva tempo, deve ser bastante fácil mostrar a eles que escrever mais software deve ser difícil e demorado. Seria bom obter todos os benefícios da automação gratuitamente, mas, como sempre, precisamos colocar o trabalho na frente para obter os benefícios mais tarde.
Se eles não entenderem isso, você precisará ensiná-los ou aperfeiçoar seu currículo.
fonte
writing software is hard and takes time. Escrever um pequeno aplicativo de linha de comando é rápido. Escrever a IA do skynet é difícil. Contar tais afirmações gerais não convencerá ninguém.A maioria dos funcionários gasta seu tempo na parte "frontal" (voltada para o cliente-chefe-parte interessada) da empresa ou na parte "traseira" (onde o trabalho "real" é realizado). Essas duas funções são diferentes, quase opostas. (E muito poucas pessoas trabalharam em ambos). Como resultado, muitas vezes há mal-entendidos entre os dois grupos.
A melhor maneira de educar, por exemplo, as pessoas da "frente", é fazer com que um ou alguns deles passem um dia nas "costas". Se eles concluíssem "Um dia na vida de ...", teriam uma idéia mais realista do que pode ser feito em um dia e por que leva mais tempo e esforço para executar testes automatizados. Da mesma forma, as pessoas "de trás" podem se beneficiar de um ou dois dias na "frente".
Em "Como ser rico", John Paul Getty (um magnata da época) defendia esse "treinamento cruzado". Na sua opinião, um vendedor que passava algum tempo na linha de montagem em que o produto era fabricado faria um trabalho de venda muito melhor, e da mesma forma um engenheiro que passava um dia com os clientes faria um trabalho melhor de "depuração".
fonte
Não concordo com a sua premissa aqui.
Sou um grande defensor dos testes automatizados, não importa se são testes de unidade, testes de integração ou testes de interface do usuário. Existem muitas ótimas ferramentas disponíveis para implementar testes automatizados.
Vamos comparar testes automatizados e manuais com base no seguinte exemplo:
Em um aplicativo Web, teste a funcionalidade "Alterar senha" de um usuário existente usando um navegador.
Teste manual :
Fácil? Na verdade não. Existem muitas armadilhas possíveis no processo.
Rápido? Não . O trabalho manual leva tempo.
Agora, vamos tentar escrever um teste automatizado :
Fácil? Não! Precisávamos pesquisar as ferramentas, implementá-las, corrigir alguns erros em nossos testes.
Rápido? Não! Demora ainda mais do que fazer um teste manual.
Mas há uma grande diferença aqui: para testes futuros, você só precisa escrever o teste em si , o último item da lista - que foi feito comparável rapidamente. Todas as pesquisas e scripts de inicialização não precisam ser feitos para testes adicionais.
E depois de escrever o teste, você pode começar com facilidade. Em alguns segundos (ou talvez minutos, se o início do banco de dados e do aplicativo da web demorar muito), você verá se a rotina "Alterar senha" funciona ou não. Se houver um erro, corrija-o e execute o teste novamente - você verá imediatamente se o erro foi corrigido. Rápido e fácil .
Escrever testes automatizados não é fácil nem rápido, mas a execução é.
E este é o ponto em que o tempo investido volta.
fonte
Testar em geral não é fácil, e nem deveria ser. Se a Boeing ou a Mercedes não testassem seus produtos com a mesma rigor que testam, ou estariam em falência devido a ações judiciais ou fechariam o negócio por vender itens de baixa qualidade. Você dirige um carro a 100 km / h, sabendo que o volante pode ou não cair em pedaços?
É muito difícil sugerir maneiras de lidar com a mentalidade sem entender quem são essas pessoas ou seus motivos. A maioria dos gerentes e diretores pensa em custos e é julgada pelo que é produzido. O uso desse critério dificulta a justificação de tempo gasto em testes. Se esse for o seu caso, você precisará encontrar maneiras de apresentar essa tarefa como benéfica a longo prazo, o que é claro.
Só porque o software não é tangível, não significa que podemos fugir sem pensar nas implicações dos sistemas que construímos que não estão funcionando. Aposto que a Amazon tem testes automatizados e aposto que existem pessoas que conhecem muito bem as implicações de custo de seus sites / serviços falharem.
fonte
2 +2 = 4 é um dos trechos de código mais simples que todos entendem; E você pode ver como é fácil entender. Mas isso não significa que é uma equação "fácil". O nível de abstração necessário para alcançar a equação simples é bastante complexo. O mesmo acontece com o software e as metodologias de teste de software. O nível de abstração que requer um pedaço de código exige muito trabalho.
É verdade que uma boa prática leva a reutilizar classes e objetos, mas igualmente, para atingir esse estado, é necessário investir tempo e esforço .
fonte
Existem dois lados dessa questão.
Por seu lado, você parece pensar que está fazendo um bom trabalho e que o grupo "Automação é fácil" não sabe do que está falando.
Do lado deles, pelo que você diz, eles veem testes automatizados levando (na visão deles) muito tempo para serem produzidos.
A essa distância, com o pouco que temos para continuar, não sabemos quem está "certo" ou se alguém está "certo".
Como lidar com a automação é fácil mentalidade
Fale com eles. Honestamente, peça suas idéias sobre como isso pode ser melhorado. Envolva-os e envolva-os. É a única maneira de descobrir se eles realmente têm algo positivo a oferecer. Talvez eles tenham algumas contribuições valiosas a fazer e você possa obter uma vitória / vitória.
Se eles não têm nenhuma idéia real de como a programação e os testes automatizados funcionam, ou idéias realistas sobre como melhorar a produtividade, depois de tê-los engajado positivamente, você pode mostrar como isso é feito e aonde o tempo passa. Seja humilde e positivo, agradecendo-lhes por suas contribuições / idéias. Pense no que eles disseram: talvez as sugestões deles desencadeiem uma maneira diferente de pensar para você. Se sim, dê a eles esse feedback. Por ser humilde e positivo, você também pode ganhar / ganhar.
Antes de conversar com eles, pense em como você constrói, executa e gerencia seus testes. Que estrutura (s) você está usando? Existem outros que poderiam ser melhores? Você tem clichê "padrão" que você adapta? A criação dos testes poderia ser mais automatizada? O que está te segurando?
fonte