Os programadores são maus testadores?

36

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".

jhsowter
fonte
17
@jshowter Os programadores são piores ao testar seu próprio código, enquanto brilhantes ao testar o código de outros. Os testadores (bons testadores) são eles próprios programadores à sua maneira (já que precisam entender a lógica de programação e sua funcionalidade), com a exceção de que não escrevem muito código. Acredito que isso esteja mais relacionado à psicologia, pois sempre hesito em encontrar dúvidas em meu próprio trabalho, por pior que seja.
Ubermensch
6
@ Ubermensch, eu discordo dos desenvolvedores serem brilhantes testadores do código de outros por padrão. Alguns desenvolvedores são, devido à prática de testes por um tempo. Requer uma mentalidade diferente e um tipo diferente de motivação também, o que não é de todo óbvio para os desenvolvedores em geral. Muitos desenvolvedores tendem a se concentrar - e aproveitar mais - a parte de codificação, e podem não apreciar - ou até mesmo estar cientes - da importância de outras atividades no SDLC completo.
Péter Török
1
@jshowter Se você está atrás de fatos concretos / dados de pesquisa, não consigo encontrar um. A maior parte da literatura refere-se ao desenvolvimento ágil e não conseguiu encontrar um que corresponda ao seu caso específico. Você pode tentar no Google Scholar ou Scirus.
Ubermensch
3
Não somos maus testadores! Funcionou no meu PC! ;-)
Joris Timmermans
2
@MadKeithV Ha! Este é o meu JIRA (issue tracker) avatar;)
yannis

Respostas:

39

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.
vaughandroid
fonte
4
Observe que o pensamento lógico dos programadores pode ser um prejuízo para ser um bom testador. Quantas vezes você já viu um programador reagir com "mas isso é impossível!" quando confrontado com um bug encontrado? Apenas para descobrir que eles haviam perdido algo sério no raciocínio que tornava o bug "impossível".
Joris Timmermans
2
@ CraigYoung - é claro que é um pensamento lógico defeituoso, mas isso é muito comum (os sistemas são complexos). O fato é que, nos testes, você não deve usar o pensamento lógico para eliminar testes "desnecessários", e parece ser difícil para os desenvolvedores evitar esse tipo de pensamento.
Joris Timmermans
3
+1 Uma ótima resposta equilibrada. Também explica por que a combinação entre testes automatizados de unidade e integração escritos por programadores e testes de sistema pelo controle de qualidade é a melhor combinação.
precisa
1
+1 para "mentalidade é fundamentalmente diferente". Afinal, esses são papéis diferentes, com conjuntos de habilidades relacionadas (mas diferentes).
Joshin4colours
3
@MadKeithV O pensamento lógico é vital nos testes, assim como a eliminação de testes desnecessários. Você está pensando em testes de caixa preta versus caixa branca? Nos testes de caixa preta, você cria testes a partir dos requisitos sem o conhecimento da implementação. Para verificar suposições com falha, lógica equivocada, etc. Os desenvolvedores do IMHO são bons nisso, desde que não conheçam a implementação. Em particular, se eles escreverem o código e cometerem erros, inevitavelmente estarão propensos a cometer os mesmos erros nos testes. O teste do sistema deve ser de caixa preta.
MarkJ
19

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

Amy
fonte
1
Meus dois centavos. Os desenvolvedores geralmente testam apenas as últimas alterações, a última correção, o último recurso, o que eles fizeram (do que eu fiz) e, em alguns casos, eles (nós) são um pouco cegos ou preguiçosos para testar outro recurso.
Andrea Girardi
11

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.

Wyatt Barnett
fonte
3
Exemplo adicional para o seu primeiro ponto: Nossos usuários tendem a copiar do MS Word, que insere coisas estranhas, como traço e citações inteligentes - que às vezes quebram até as bibliotecas que não escrevemos. Nenhum de nós está sequer no Word, de modo que o caso de uso mal passa pela nossa cabeça, e muito menos é testado.
Izkata
1

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.

tdammers
fonte
1

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.

Morothar
fonte
1

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á.

AngeloBad
fonte
0

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.

JB King
fonte
Obrigado por perguntar isso. Atualizei minha pergunta para dizer o que considero o teste. Basicamente, o teste é algo que acontece depois que o software foi construído e implantado, não durante o desenvolvimento (como teste de unidade) ou como parte de uma metodologia de desenvolvimento (como revisão por pares).
jhsowter
0

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.

Kevin Cline
fonte
Por mais que eu defenda a escrita de testes de unidade e integração, não vejo como o TDD (ou escrevendo os testes primeiro) corrige isso. Se você escrever os principais cenários de sucesso antes do código, provavelmente não encontrará a maioria dos erros. Você tem que pensar em todas as coisas que podem dar errado. O código escrito pode ajudar a encontrar alguns deles, pois você pode examinar os ramos e os métodos que você chama para ver o que pode quebrá-los.
precisa
Além disso, muitos dos erros que descobri que os desenvolvedores perderam estavam relacionados à ordem de chamada da API. Algo que a maioria dos testes de unidade não cobre, especialmente se você não souber como outros métodos poderiam ser chamados que podem afetar o que você está testando (e que ainda não foi implementado).
precisa
@ Danny: com o TDD, você só deve escrever ramos ou métodos em resposta a um teste com falha e escrever apenas o código necessário para fazer o teste com falha.
precisa
Conheço a metodologia do TDD, não concordo com as conclusões.
Danny Varod
0

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.

HLGEM
fonte