Os programadores são maus testadores?

Sei que isso parece muito com outras perguntas que já foram feitas, mas na verdade é um pouco diferente. Parece ser geralmente considerado que os programadores não são bons em desempenhar o papel de testar um aplicativo. Por exemplo:

Joel on Software - As cinco principais (erradas) razões pelas quais você não tem testadores (ênfase minha)

Nem pense em dizer aos formandos do ensino médio que podem vir trabalhar para você, mas "todo mundo precisa fazer um pouco de controle de qualidade por um tempo antes de passar para o código". Eu já vi muito disso. Os programadores não são bons testadores e você perde um bom programador, que é muito mais difícil de substituir.

E nesta pergunta , uma das respostas mais populares diz (novamente, minha ênfase):

Os desenvolvedores podem ser testadores, mas não devem ser testadores. Os desenvolvedores tendem a evitar, de maneira não intencional ou inconsciente, o uso do aplicativo de maneira que possa quebrá-lo. Isso porque eles o escreveram e o testam principalmente da maneira que deve ser usado.

Então a questão é : os programadores são ruins em testes? Que evidências ou argumentos existem para apoiar esta conclusão? Os programadores são ruins apenas em testar seu próprio código? Existe alguma evidência para sugerir que os programadores são realmente bons em testes?

O que quero dizer com "teste"? Eu faço não o teste de unidade média ou qualquer coisa que é considerado parte da metodologia utilizada pela equipe de software para software de gravação. Refiro-me a algum tipo de método de garantia de qualidade que é usado após o código ser construído e implantado no que a equipe de software chamar de "ambiente de teste".

A pergunta parece estar se perguntando especificamente sobre o Teste do sistema , e é a isso que estou me referindo ao longo desta resposta.

Eu acho que há uma distinção importante a ser feita entre ser uma pessoa ruim para escolher realizar testes e realmente ser ruim nos testes.

Por que os programadores são ruins em testes:

• Se você escreveu o código, você (deveria) já pensou em todas as maneiras possíveis para que as coisas pudessem dar errado e lidou com elas.
• Se encontrar um bug particularmente feio significa que você precisa corrigi-lo, em uma base de código da qual você está cansado, então isso não ajudará sua motivação.

Por que os programadores são bons em testes:

• Os programadores tendem a ser pensadores lógicos e bons em trabalhar de maneira sistemática.
• Programadores experientes serão muito bons em identificar rapidamente casos extremos e, assim, apresentar testes úteis. (Se houver um processo formal de teste, a maioria desses casos já deverá ter sido identificada e testada antes do teste do sistema.)
• Os programadores são muito bons em garantir que todas as informações úteis sejam inseridas em um relatório de bug.

Por que os programadores são maus testadores:

• Programadores são mais caros que testadores (na grande maioria dos casos).
• A mentalidade é fundamentalmente diferente: "Construa um produto (funcional)" vs "Essa coisa não sai pela porta com nenhum bug (desconhecido) nela".
• Os testadores normalmente serão mais eficientes - ou seja, executam mais testes na mesma quantidade de tempo.
• Programadores especializados em programação. Profissionais de controle de qualidade especializados em testes.

Eu acho que os programadores são ruins em testar seu próprio código .

Gostamos de acreditar que nosso código funciona perfeitamente de acordo com os requisitos e testá-lo como tal. Em meu lugar, testamos nosso próprio código, depois testamos o código um do outro antes de liberá-lo no ciclo de teste real e muito mais bugs foram detectados dessa maneira do que apenas testando nosso próprio código

Os programadores são definitivamente as pessoas certas para testar algumas partes do sistema - em alguns locais, eles são os únicos que podem fazê-lo de maneira eficaz.

Um lugar em que os programadores tendem a ser muito ruins nos testes é o bit "usar a interface do usuário como um usuário normal" - eles não são usuários normais e não se comportam como eles. Por exemplo:

• Os programadores tendem a ser muito bons em obter as entradas de texto corretamente. Um problema bastante comum que vejo é espaços à frente ou especialmente à direita. A maioria das pessoas não os parece, mas bons programadores provavelmente são religiosos em fazer suas cordas a corda certa, sem espaços estranhos.
• Os programadores tendem a ser tecladistas, aproveitando as guias e outros atalhos para acelerar o trabalho. Usuários normais tendem a pegar o mouse entre os campos.
• Os programadores tendem a entender o que o sistema está dizendo a eles, em vez de ignorar as mensagens de erro e apenas clicar em OK.

Portanto, usuários normais fazem muitas coisas que os programadores não fazem. Você não pode confiar completamente na equipe de desenvolvimento do UAT.

No nível técnico (testes de unidade, testes de integração, testes de regressão), os programadores são provavelmente as únicas pessoas qualificadas a serem testadores, porque esses tipos de testes são automatizáveis ​​e, portanto, devem ser automatizados, o que requer programação.

Mas acho que não é disso que você está falando, e tenho certeza que também não é o que Joel Spolsky quer dizer - é a parte que resta, o teste manual prático: transformar um documento de requisitos e especificações funcionais em um script de teste e, em seguida, executando meticulosamente esse script no produto final.

Ser um bom testador exige qualidades ortogonais, em grande parte, para quem é um bom programador. Há um pouco de sobreposição - você deve ser capaz de pensar analiticamente, precisa de uma certa afinidade com os computadores em geral - mas, além disso, as habilidades de um testador são muito diferentes. Isso por si só não significa que você possa ter os dois conjuntos de habilidades e, de fato, muitas pessoas provavelmente possuem. No entanto, para ser um bom programador, é preciso ter uma certa preguiça (o desejo de automatizar suas tarefas), enquanto um testador realmente bom precisa de persistência (verifique todos os três mil campos de formulários quanto a inconsistências) e, como conseqüência, mesmo os programadores que o que é preciso para ser um testador geralmente abomina a idéia.

E há o viés seletivo: um programador que já está envolvido em um projeto, mesmo que marginalmente, já possui algum conhecimento interno sobre a base de código e terá dificuldade em abordá-lo com a mente em branco, da perspectiva do usuário final . Ele nem precisa ser explícito, como em "Eu sei que esse botão funciona, então vou observar 'pass'"; pode ser bem mais sutil e esses efeitos sutis podem levar à perda de casos críticos nos testes.

Pela minha experiência, sim, programadores são maus testadores. Muitas vezes eu vi outros e eu dizer "Huh, mas eu testei isso antes de fazer o check-in!" quando confrontado por um testador que reproduz o bug na sua frente.

Por quê? Bem, não sei por que, mas talvez seja porque queremos ver as coisas funcionando. Ou apenas queremos acabar com o teste desse ou daquele recurso.

De qualquer forma, testar não é uma habilidade que aprendemos e não trabalhamos como programador porque somos bons em quebrar recursos. Também podemos não ter idéia de como fazer o planejamento de teste adequado ou todas as outras coisas que o controle de qualidade faz. Não estamos mais qualificados para realizar o trabalho de um testador do que um qualificado para implementar seu novo pipeline de renderização em 3D.

Como na pergunta, testar não significa nada automatizado, mas testar usando o programa.

Existem vários níveis de teste. O teste de "baixo nível" pode e deve ser realizado pelos desenvolvedores. Eu acho que na unidade testig.

Por outro lado, testes de "alto nível" são totalmente outra coisa. Em geral, acho que os desenvolvedores são maus testadores não porque perdem habilidades, mas porque é muito difícil mudar a maneira de pensar e a maneira de trabalhar em alguns momentos.

Eu uso para tentar testar o máximo possível meus códigos, mas depois de pelo menos 10 minutos feitos por um testador, surge algo para considerar um bug ou aprimoramento. Isso significa que testar algo que você cria é um trabalho árduo. Você sabe onde clicar, sabe quando clica, conhece a lógica de negócios e provavelmente sabe como os dados são mantidos. Você é um deus que nunca cairá.

Que tipo de teste você quer dizer? Se você quer dizer testes exaustivos abrangentes, pude ver algumas justificativas para dizer sim, embora eu suspeite que a maioria das pessoas seja pobre nessa categoria se considerarmos todas as combinações possíveis de entradas como um requisito para esses testes.

Posso reconhecer que o desenvolvedor que cria o software pode ter uma visão de túnel quando se trata de como o código deve lidar e ignorar alguns possíveis casos de fronteira que simplesmente não foram considerados. Por exemplo, se eu criar um formulário da Web com um número, n e depois imprimir de 1 a n na tela, talvez eu perca alguns casos especiais, como se nada for inserido ou algo que não seja um número natural como e ou pi . O que o programa deve fazer nesses casos pode ser questionável.

O Desenvolvimento Orientado a Testes seria um exemplo de uma metodologia de desenvolvimento que coloca os testes sob uma luz diferente que pode fornecer outra visão aqui.

Os programadores definem bem os testes quando os definem antes de escrever o código. Com a prática, eles ficam ainda melhores.

No entanto, ao definir testes para o código que eles escreveram, eles não se saem muito bem. Eles terão os mesmos pontos cegos nos testes que tinham ao escrever o código.

Usar programadores para fazer testes manuais é simplesmente bobo. O teste manual é bastante tolo por si só; fazer programadores fazer isso é extremamente bobo. É caro e afasta os programadores competentes.

Um tipo de teste no qual eu particularmente vi devlopers falhar é testar se o requisito foi atendido. O que os devlopers pensam que algo em um requisito significa e o que os testadores pensam que isso significa são geralmente duas coisas completamente diferentes.

Posso pensar em um recentemente em que o develoepr foi convidado a fazer uma exportação delta e o desenvolvedor pensou que isso significava obter registros que não haviam sido enviados uma vez e os testadores pensaram que isso significa obter novos recrutas e alterações. Eles tiveram que voltar ao cliente para descobrir quem estava correto. Eu o revisei e fiz a mesma suposição que o desenvolvedor fez sobre o requisito. Porque logicamente, se você quisesse incluir atualizações, as teria mencionado. E geralmente sou bom em identificar essas coisas ambíguas, porque costumava estar do lado do usuário.

Portanto, outros desenvolvedores que fazem o teste tendem a fazer muitas das mesmas suposições, porque também fazem certas suposições como "bem, eles teriam mais detalhes se quisessem dizer X vice Y, porque há muitos detalhes a serem respondidos antes que eu pudesse fazer Mas os escritores de requisitos não pensam assim. Portanto, alguém que se parece mais com os escritores de requisitos precisa testar as premissas do desenvolvedor e alguém que não é desenvolvedor é a melhor pessoa para perceber que há um problema.