Programadores fazendo testes

Gostaria de saber como é típico para programadores trocar de chapéu e fazer testes no trabalho um do outro. Suponha que a equipe queira adotar uma abordagem de "responsabilidade compartilhada" para que as tarefas sejam formalizadas para sua liberação -

1. é uma boa idéia que os programadores trabalhem como teste de software, desde que não escrevam um recurso?

2. Isso acontece com frequência?

3. Até que ponto um programador pode "testar" seu próprio trabalho?

Mesmo com TDD e testes de unidade, ainda não é necessário um aparelho de teste de software no processo de desenvolvimento?

1. Fazer o programador testar seus recursos pode ser uma mistura. Por um lado, o programador pode estar "muito familiarizado" com o bloco de código e simplesmente testar parâmetros do tipo passa / falha conhecidos. Por outro lado, se o programador "familiarizado demais" com seu código for diligente para que o recurso funcione, ele terá mais conhecimento sobre casos adicionais que podem causar problemas, uma vez que conhece o funcionamento interno da função e possíveis brechas. dentro dele.

2. Eu acho que isso acontece mais frequentemente do que não. Acho que a maioria das lojas de programação existe em equipes pequenas ou sob muita pressão para fazer as coisas. Isso não oferece a eles o luxo de um QA / Tester dedicado em seu grupo, então todos precisam obter sua parte. Ainda existe um número razoável de lojas de "cowboys solitários", onde cada desenvolvedor é essencialmente responsável por todo o ciclo de vida de seu aplicativo. Esse é o meu caso.

3. Voltarei ao primeiro lugar para isso. Eu acho que um programador é capaz de testar seu próprio trabalho, fora do modelo TDD, uma vez que possui um conhecimento profundo de como seu recurso funciona. Eles precisam tomar o cuidado de "recuar" e ser capazes de cobrir problemas específicos e amplos com o código (como "dedilhar" um campo de entrada de texto - o que acontece?), Mas isso pode ser feito.

Devs teste de código uns dos outros não deve ser feito em vez de testar por um focada especialista em QA, mas seria ótimo alémpara testar por um testador focado. Os desenvolvedores são hábeis em pensar em como fazer o produto funcionar. Os testadores são as únicas pessoas da equipe (BAs, PMs, desenvolvedores etc.) que estão focadas em descobrir como o produto pode falhar. É uma mentalidade muito diferente. Pense no seu trabalho de "tempo ocioso" - por exemplo, quando estiver delineando projetos em sua cabeça enquanto estiver tomando banho. Você pensa: "Ah, aposto que essa seria uma boa maneira de lidar com esse recurso!" ou você pensa: "Ei, eu deveria ver se posso conseguir que esse código falhe se eu fizer isso!"? O trabalho não acontece apenas no escritório, e os desenvolvedores provavelmente não estarão trabalhando para quebrar o código em seu "tempo livre". Os testadores também devem acumular uma ampla variedade de conhecimentos sobre ferramentas e técnicas de teste e experiência na escolha entre eles que os desenvolvedores não têm,

Ao mesmo tempo, a experiência interdisciplinar é uma coisa muito boa e sempre há um benefício em trabalhar com o código de outros desenvolvedores. Fazer com que os desenvolvedores se esforcem mais no teste antes que uma pessoa específica de controle de qualidade / teste verifique o código provavelmente resultará em um código de melhor qualidade, o que provavelmente resultará em um retorno mais rápido do teste, melhor cobertura do teste e pode até reduzir (mas não eliminar) o número de testadores dedicados necessários.

Se você realmente precisar fazer trocas devido à baixa disponibilidade de head-count ou se o pool de habilidades para o controle de qualidade for excepcionalmente ruim onde você estiver, essa configuração será melhor do que nada - mas o objetivo ainda deve ser obter um testador real antes que a equipe cresça muito.

Eu nunca vi um método ruim de testar.

Os programadores devem testar seu próprio código? Sim, obviamente.

Outras pessoas devem testar seu código? Sim, obviamente.

O teste de cobertura é uma boa ideia? Sim.

Os testes de Monte-Carlo são bons? Sim.

Podemos ter o que consideramos uma configuração muito boa para testes e, em seguida, uma nova pessoa faz alguns testes. Adivinha? Eles encontram problemas que não foram encontrados antes.

Um sinal de que a qualidade está melhorando é quando a porcentagem de problemas encontrados em testes que não são realmente erros se aproxima de 100%.

Existe um grande e crescente movimento de desenvolvimento chamado Test Driven Development ou TDD. Eu não pretendo ser um especialista e realmente lutei para resolver esse método por padrão, mas a essência é que o desenvolvedor primeiro escreve um teste com falha e depois escreve o código para passar nesse teste.

O conceito tem muitos pontos fortes. Uma é que você tem um ótimo conjunto de testes. Outra é que, como isso é feito em muitos pequenos incrementos, você sabe imediatamente se quebra alguma coisa. Uma das coisas que eu já vi com esse método e outros "mandatos" de testar tudo é que você não faz com que os desenvolvedores andem por aí colocando recursos extras porque são legais ou legais. Sempre há um custo para um recurso e, muitas vezes, um desenvolvedor não vê ou sente esse custo. Com o TDD, eles fazem, desde que você escreve um caso de teste antes de escrever o código.

Existem extensões nessa teoria, além de levar a gravação do teste à fonte de requisitos, onde o especialista em negócios escreve um conjunto de testes funcionais que compõem as especificações e, em seguida, os desenvolvedores desenvolvem esse conjunto de casos de teste.

Portanto, com o TDD, o desenvolvedor escreve muitos testes, alguns defendem uma proporção de 1: 1 para linhas de código de teste e linhas de código.

Por outro lado, acho que há muito valor no recrutamento de pelo menos algumas pessoas para a equipe que são melhores nos testes do que na codificação. É um conjunto de habilidades que é diferente do desenvolvimento e acho - mesmo com TDD e outras práticas ágeis - que alguém com um bom olho para teste é inestimável para a qualidade do produto.

Tão fácil de perguntar - os testadores devem codificar tanto quanto os testadores.

OMI - sim, deve haver pelo menos um pouco de mistura. Ter uma perspectiva do outro lado da produção de um produto mantém você bem informado e pode gerar novas idéias.

Penso que é responsabilidade de um programador fazer uma quantidade razoável de due diligence antes de fazer o check-in de um pedaço de código e assiná-lo, o que significa:

• Escrevendo testes de unidade completos.
• Testando esse código em um cenário de uso real e tentando quebrá-lo - ou seja, interaja com ele como seria usado na produção.

...

• Em seguida, outro programador deve revisar esse código e os testes de unidade.

• Em seguida, um testador / responsável pelo controle de qualidade deve testar esse código.

Não acho que exista desculpa para não fazer o primeiro 3. E não acho que exista desculpa para não dar o último passo, mas ter um testador dedicado testando cada pedaço de código é caro e empresas menores (pense pelo menos) que isso é luxo que eles não podem pagar.

Pessoalmente, não acredito que testes específicos devam ser deixados de fora da equação. Eu acho que você precisa encontrar pessoas que pelo menos não estejam desenvolvendo o mesmo produto (ou talvez módulo grande), o que permitiria que outros programadores testassem, desde que eles realmente não tivessem idéia do que é a implementação. Eu acho que o mais importante é que, se eles fazem ou não, os desenvolvedores devem funcionar como testadores, e os testadores devem funcionar como desenvolvedores. Ter bases de conhecimento e familiaridades facilita muito o desenvolvimento, os testes e a comunicação entre os dois.

1. Sim, embora eles não estejam "trabalhando como teste de software". Escrever testes faz parte do trabalho de um programador. Além disso, escrever bons testes é uma habilidade. Ser incapaz de testar adequadamente seus próprios recursos não é uma falha nos testes, é um indicador de falta de habilidade *.

2. Eu certamente espero que sim.

3. Embora um programador possa testar completamente seu trabalho, pode haver valor em um processo externo de controle de qualidade. Entretanto, raramente achei que fosse esse o caso.

O objetivo do teste é triplo:

1. Para impulsionar o desenvolvimento
2. Para gerenciar mudanças
3. Para fornecer confiança

O teste do desenvolvedor pode e deve atender a todos esses propósitos. Se o teste do desenvolvedor é suficiente para eles, não há necessidade de mais testes.

* A programação em pares torna ainda mais difícil escrever testes tão ruins porque você nunca está testando seus próprios recursos.