Por que deixar / não permitir que os desenvolvedores testem seu próprio trabalho

Como outros (e você mesmo) notaram, os desenvolvedores devem testar seu próprio código. No entanto, depois disso, qualquer produto não trivial também deve ser testado por pessoas independentes (departamento de QA e / ou o próprio cliente).

Os desenvolvedores normalmente trabalham com a mentalidade de desenvolvedor "como fazer isso funcionar?" . Um bom testador está pensando em "como quebrar isso?" - uma mentalidade muito diferente. O teste unitário e o TDD ensinam os desenvolvedores a mudar de chapéu até certo ponto, mas você não deve confiar nele. Além disso, como outros observaram, há sempre a possibilidade de entender mal os requisitos. Portanto, testes de aceitação final devem ser realizados por alguém o mais próximo possível do cliente .

O desenvolvedor sabe como o código funciona e terá o hábito de testar o código de acordo com esse conhecimento.

O desenvolvedor achará difícil remover-se da mentalidade de "como funciona", em oposição a "como deve funcionar".

Por causa disso, é melhor obter alguém com alto grau de objetividade para testar o programa, por exemplo, QA ou Engenheiros de Teste

Teste de testadores para quebrar, simples. Este tipo de preconceito é necessário para realmente descobrir as rolhas do programa.

Os desenvolvedores DEVEM testar seu trabalho. É uma responsabilidade implícita.

Estou assumindo que você não tem uma equipe dedicada para fazer os testes com base em sua declaração. No entanto, ter uma equipe dedicada aos testes realmente ajudará, pois os desenvolvedores tendem a testar seu código da maneira como o codificaram. Isso não significa que, uma vez que você tenha algum tipo de equipe de garantia de qualidade, você já pode fazer o teste como uma responsabilidade dos desenvolvedores.

Developers usually use nets with huge holes for catching bugs. As a result, smaller bugs escape.

Porque os desenvolvedores não são bons em tentar quebrar seu próprio código. Sua mente simplesmente segue o caminho correto de entrada de dados e interação com o aplicativo. Muitos bugs são o resultado da interação com o sistema como um normal guy . Os desenvolvedores não são usuários normais. Eles são usuários profissionais.

Existem algumas boas razões para ter uma equipe de testes dedicada. Primeiro, como mencionado acima, os desenvolvedores são muito bons em testar se o código deles funciona, mas não para quebrá-lo.

Além disso, como você diz, um desenvolvedor sabe o que eles escreveram, mas as equipes de teste sabem o que deveria ter sido escrito. Às vezes, esses dois conceitos não combinam. Um dos trabalhos da equipe de teste é garantir que o software atenda aos requisitos. Em muitos casos, um desenvolvedor conhece apenas algumas partes do sistema, mas a equipe de QA sabe tudo.

O que leva à próxima razão, as equipes de teste fazem testes de integração completa. A parte do código que você acabou de escrever pode funcionar bem por conta própria, mas pode quebrar outras funcionalidades que você não conhecia.

Tendo trabalhado com uma equipe de QA e sem, posso dizer a você que 100% apreciam o trabalho que fazem e dizem que são uma parte valiosa da equipe de software. Quando você tem uma equipe de QA, isso torna o lançamento do seu código muito mais fácil, porque você sabe que foi completamente testado e isso significa que você receberá menos chamadas às 3 da manhã.

Os desenvolvedores devem testar seu próprio código.

Testadores independentes não apenas testam para quebrar, eles testam as suposições não declaradas e não definidas que os desenvolvedores fizeram durante a codificação.

Eu esperaria que o desenvolvedor fizesse alguns testes iniciais antes de cometer quaisquer alterações e ter se convencido de que o código funciona. Esperaria, então, que o desenvolvedor fornecesse aos casos de teste qualquer conhecimento específico de "caixa branca" que eles tivessem. Por exemplo, detalha quaisquer outras áreas do código que possam ter sido afetadas.

A principal objeção para os desenvolvedores testarem seu próprio código é que você está testando apenas um ponto de vista. O desenvolvedor leu a especificação e a interpretou. Espero que a especificação seja clara, completa e inequívoca, mas nem sempre é o caso. O desenvolvedor pode ter entendido mal parte da especificação. Se eles testarem seu próprio código, isso não será detectado, pois eles descobrirão que a função opera conforme o esperado.

Diferentes pessoas também tendem a usar um produto de maneira diferente e, por isso, seguem rotas diferentes através do código. Um desenvolvedor terá garantido que o código funciona para eles, mas pode não ter considerado um caso extremo que outro testador possa encontrar.

Desenvolvedores devem testar seu próprio trabalho. Permitir que os desenvolvedores enviem trabalhos não testados para uma equipe de controle de qualidade, ou para seus colegas desenvolvedores, é uma idéia realmente ruim. Ele desperdiça o tempo de desenvolvedores e testadores e destrói relacionamentos.

No entanto, isso nem sempre é suficiente. É provável que os desenvolvedores sigam um caminho feliz pelo sistema ou fiquem cegos a algumas idiossincrasias às quais foram expostos ao longo do desenvolvimento.

Outro ponto é que pode haver várias camadas de comunicação entre especificação e implantação. Isso pode levar a um efeito Chinês Sussurros na implementação final. É melhor que quem definiu o requisito ou o relatório de erros teste que funciona da maneira que queria.

Como desenvolvedor você é responsável por seu próprio código, você deve testá-lo. Does the feature work as expected? Se a resposta for sim, está pronto.

Por que você não deveria fazer casos de teste?

1. Você é subjetivo , pois os erros encontrados são escritos por você (ou por seus colegas).
2. Você é muito caro para a empresa executar os testes de caso. (Eu espero).

Normalmente, os desenvolvedores não serão, na maioria dos casos, aqueles que usam o código, exceto em determinados casos especializados. Portanto, a última etapa de teste antes da promoção para um sistema de produção deve ser o teste de aceitação do usuário, UAT. Eles geralmente [deveriam estar] mais familiarizados com o que eles esperam que o pacote esteja fazendo. E geralmente são mais capazes de quebrar coisas com fluxos de entrada que não são familiares a alguém que não o usa no dia a dia.

Seus planos de projeto não atendem a testes de usuários? Se você conseguir que os usuários testem, você pode pegar bugs antes da pós-implementação, o que no meu mundo não é ruim.

Os desenvolvedores não devem testar seu próprio código porque isso é como julgar a arte de seu próprio filho. Vai ser bonito para você de qualquer maneira, e você realmente precisa de um profissional para apontar as falhas. O teste de unidade, por outro lado, é como garantir que seu filho não esteja tentando pintar com chumbo.

Caso você REALMENTE não queira contratar o QA, faça com que os desenvolvedores escrevam código de teste para outros desenvolvedores. Esse é um bom primeiro passo - em breve você verá desenvolvedores solicitando recursos de QA porque a maior parte do tempo deles é gasto em testes de código de outras pessoas, além de CR.

Não são apenas os desenvolvedores que protegem seu código, se eles não percebem um caso específico ou interpretam mal uma especificação na forma como desenvolvem algo, então, eles perderão esses casos ao testar seu código.

As técnicas e habilidades para testes também são muito diferentes.

A maioria dos testes realizados por uma equipe de teste é funcional (que um produto funciona de acordo com uma especificação) e caixa preta (a equipe de teste não verá o funcionamento interno de um aplicativo). Os testadores funcionais não precisam se preocupar com a maneira como as coisas funcionam, eles só precisam se concentrar em saber se eles funcionam.

Na minha experiência, pelo menos na minha pequena organização, o usuário final precisa testar. Quase todos os projetos que recebemos, eles não fornecem todas as informações necessárias, e sempre deixam de fora certos detalhes. O desenvolvedor está sempre em desvantagem de teste, porque ele não sabe como fazer o trabalho do usuário, então, embora ele saiba que o software funciona de acordo com as informações que ele recebeu, ele não sabe se isso ajudará o usuário final. faça o seu trabalho.

Os desenvolvedores interpretam mal e interpretam mal os requisitos e os responsáveis pelos requisitos muitas vezes não conseguem especificar as principais coisas. Se ninguém, exceto o desenvolvedor, testar, ninguém encontrará essas desconexões antes de entrar em operação. Quando os desenvolvedores testam, eles sabem muito sobre como deve funcionar e não tentam as coisas estúpidas que os usuários podem tentar. Os desenvolvedores também escrevem seus testes com base em sua própria interpretação do requisito, o que muitas vezes não é o que realmente se queria dizer. Portanto, os testes são aprovados, mas o requisito não foi atendido. Quando você tem um teste de pessoa diferente, essa pessoa pode ter uma ideia diferente dos requisitos e muitas vezes você encontra os lugares onde o requerimento foi mal expresso pela forma como duas pessoas diferentes o interpretam. Muito melhor para descobrir isso em testes do que depois de ir viver.

O desenvolvedor deve fazer o teste inicial para que possamos saber que a peça que codificamos funcionaria da maneira esperada, de acordo com os requisitos que temos. Então, nós fizemos o teste normal, assim como escrevemos Testes de Unidade para o código que escrevemos.

O próximo passo é o trabalho dos QAs para descobrir o que os desenvolvedores não vêem quando escrevemos o código. Um desenvolvedor pensa em um nível mais alto, mas o usuário pode não pensar no mesmo nível. Quando o desenvolvedor está testando sua parte e tem que inserir algum texto em uma caixa de texto, ele pode sempre digitar um pensamento completo que o usuário também faria. Pode ser que o usuário também faça isso, mas, aleatoriamente, quando ele insere um caractere especial como% & $ ^ no texto e interrompe o aplicativo, ele não fica bem no usuário final. Um desenvolvedor não pode e não vai pensar em todas as possibilidades que poderiam acontecer porque ele não é treinado para pensar dessa maneira. Quando se trata de um QA (testador), eles sempre pensam sobre o que o usuário pode fazer para quebrar esse aplicativo e tentar todas as coisas estúpidas no livro, e não os usuários são estúpidos, mas não devemos deixar nada ao acaso.

Agora também temos que entender que geralmente há mais de uma peça feita ao mesmo tempo e ambas irão para a produção. O desenvolvedor poderia testar apenas sua parte e pensar que está funcionando bem, mas o teste geral de regressão precisa ser feito para todas as partes que estão sendo enviadas, bem como para descobrir que a combinação de duas partes diferentes poderia quebrar o aplicativo e não não parece bom também. Também temos que considerar os cenários de teste de carga e outras coisas que os testadores estão mais familiarizados.

Finalmente, temos que passar pelo Teste de Aceitação do Usuário (UAT - User Acceptance Test) para ver se a peça que fizemos é o que é esperado. Em geral, embora os requisitos passem pelos BAs, a pessoa final pode não saber exatamente como é que ela se parece e talvez pense que não é o que eles esperavam, ou talvez queira adicionar outra coisa para parecer melhor ou, por algum motivo, peça inteira como eles acham que a peça não iria com a funcionalidade já disponível.

Como explicado acima, isso é muito importante e não pode ser feito apenas pelo desenvolvedor e é absolutamente necessário para o aplicativo funcionar bem. A gerência pode dizer que esta é uma abordagem conservadora, mas é a melhor abordagem. Podemos fazer alguns ajustes ao que foi dito acima, mas não podemos evitar como um todo.

Os comentários acima levantam grandes pontos.

Um outro não mencionado anteriormente é que ter um código de teste individual separado age como uma verificação adicional dos requisitos e se o sistema os implementa corretamente.

Os requisitos e a documentação não são perfeitos e, muitas vezes, a implementação é resultado da interpretação dos requisitos por um desenvolvedor.

Quando o teste é feito por um indivíduo separado, eles também fornecem sua própria interpretação dos requisitos ao criar o plano de teste e executar os testes.

Quando as atividades de teste são realizadas independentemente das atividades de desenvolvimento, e as saídas de ambas "concordam", isso fornece uma confirmação adicional de que o sistema está correto e realmente corresponde à intenção original dos requisitos.

Um programador, ao testar, verá uma caixa de texto chamada "Quantidade" e digite "1". Um programador altamente experiente fará então um teste de acompanhamento com o valor "2".

Um usuário verá uma caixa de texto chamada "Quantidade" e digitará "~~ unicórnios ROX !!! ~~". Um usuário experiente também tentará "-12 1/2".

Espero que um testador esteja em algum lugar para alertar o programador sobre o que o usuário experimentará quando fizer isso.

Uma razão é porque os desenvolvedores estão muito perto de seu próprio código. Eles sabem que são peculiaridades, são comportamentos pouco estranhos. Eles tendem a testar ao redor as pequenas idiossincrasias que eles conhecem tão bem. Eles não são objetivos o suficiente sobre isso. Equipes de teste tratam como uma caixa preta. Eles escrevem matrizes de dezenas ou centenas de casos de teste e os veiculam metodicamente para ver o que o código fará. Muitas vezes, eles criam cenários com os quais a equipe de desenvolvimento nunca sonharia.

Outra razão é o tempo. Para grandes projetos que são construídos em estágios, a equipe de desenvolvimento construirá o Estágio 1. Em seguida, os testadores irão testá-lo enquanto o Estágio 2 estiver sendo construído e os defeitos do Estágio 1 forem corrigidos. Isso acontece em todos os estágios, então o estágio que está sendo testado é o anterior que foi construído.

I want to gather some arguments as to why letting a developer testing his/her own work as the last step before the test goes into production is a bad idea, because unfortunately, my place of work sometimes does this (the last time this came up, the argument boiled down to most people being too busy with other things and not having the time to get another person familiar with that part of the program - it's very specialised software).

Os testes não são opcionais para um desenvolvedor. Um desenvolvedor tem que testar o código que ele escreveu. De que outra forma ele pode ter certeza de que a tarefa foi realizada com sucesso? Você tem que escrever algum tipo de testes automáticos (unittests) ou executar o trabalho de verificação "é a máquina fazendo o que eu quero fazer" manuall (usando a GUI, chamando o comando na linha de comando ou qualquer outra coisa). / p>

Tudo o que está sendo testado depois disso é "apenas" um teste adicional feito por outras pessoas (colegas de trabalho, controle de qualidade, ...). Não há alternativa para o teste direto por um desenvolvedor. Todo mundo que me diz que um desenvolvedor não tem que testar (ou até mesmo não é permitido) o código / recurso que ele escreveu simplesmente não tem nenhum entendimento de como o software está sendo desenvolvido.

Ele é testado por alguém não familiarizado com o código, quer você goste ou não. A questão é se você quer que alguém seja seu cliente.

Grande pergunta. Na sua situação, os casos de teste - às vezes - existem e o software parece ser complexo o suficiente para que a obtenção de um novato sobre o produto não seja prático. Você também diz que o teste realizado é o teste final antes da produção

Razões para o desenvolvedor poder fazer o teste final

• Há cobertura de teste suficiente em outros ... Testes de unidade existem, um ambiente de teste de integração existe e é usado, teste de interface do usuário, testes exploratórios etc. foi realizado. Um teste final é menos um critério de aceitação rigoroso do que um final "percorrer"
• Um conjunto de casos de teste escritos por um SQA / Testador profissional existe que alguém (um desenvolvedor) pode / precisa seguir explicitamente
• O risco de falha do recurso / produto / módulo foi atenuado para níveis baixos (deixe o profissional testar as áreas de alto risco e um teste "novato" o menor risco)
• A realidade da situação do negócio é que liberar um produto com possíveis defeitos é melhor do que atrasar o lançamento
• O desenvolvedor em questão é realmente um testador muito qualificado e é capaz de fazer mentalmente a mudança nas funções
• A alteração é uma correção de bug feita em campo pelo desenvolvedor quando o site do cliente é desligado ou perder receita por causa do sistema estar offline (um patch que será levado de volta ao escritório e testado / liberado em um versão controlada o mais rápido possível)

Razões para um desenvolvedor não fazer o teste

• Mais alguma coisa

Em geral, parece que você está no caminho certo para atacar a solução real - faça com que o especialista em SQA gere os casos de teste ...

Nota: Eu geralmente sou a favor de deixar os desenvolvedores fazerem o teste, mas eu tenho certeza que o primeiro ponto de bala existe ...

Os seres humanos, sendo humanos, tendem a sofrer de Preconceito Cognitivo - onde seu julgamento em dois cenários quase idênticos será diferente, simplesmente por causa de algumas coisas que mudaram - uma coisa que notei em 8 anos de desenvolvimento, é que quando um desenvolvedor se depara com o teste de seu próprio código, ao contrário do código que um colega escreveu, o teste realizado em seu próprio código é de pior qualidade.

Isso não quer dizer que o desenvolvedor esteja em falta diretamente - seu cérebro vai usar o viés que ele escreveu, para reforçar o fato de que eles acreditam que o seu direito, e só irá realizar verificações básicas, ao contrário de um desenvolvedor que está olhando para o código de outra pessoa, fará mais verificações completas.

Já é hora de a indústria de TI avançar para uma atitude mais profissional e implementar procedimentos para evitar o teste de seu próprio código.

• Todos devem testar - Desenvolve o código de teste, a funcionalidade de teste do QA'ers, o envio de mensagens de teste de marketing. Dessa forma, todos compartilham as mesmas filosofias e a linguagem em torno do teste, que é metade da batalha.

• O teste é manutenção de rotina e geralmente uso analogias para comparar . Por exemplo, a analogia da mudança de óleo do carro. Você nunca precisa mudar o seu petróleo. Mas você faz isso regularmente de qualquer maneira. O mesmo para escovar os dentes. Há uma razão pela qual você os mantém diariamente - eles não vão quebrar 'hoje', é tudo sobre amanhã e dias futuros e fazer um investimento.

• Todos devem compartilhar a responsabilidade para testar. Uma equipe de QA é importante, no entanto, fazer "testes" como algo que apenas a equipe de QA faz é uma atividade "separada" que não é integrada ao desenvolvimento de produtos e fluxo de trabalho, o que não é bom.

• Quando algo quebra na produção, faça duas coisas:

  1. Diga "hmm, temos um teste para isso " como o primeiro comentário.
  2. Faça qualquer correção inclua testes para o problema , primeiro para reproduzir, do que corrigir.

Na minha empresa, construímos algumas aplicações financeiras bastante complexas. Nossa política geral é que o desenvolvedor deve garantir que nenhum erro técnico apareça. Basicamente, tente tudo o que puder para quebrá-lo, dados os recursos do usuário. Quando não for possível encontrar um erro de tempo de execução, envie-o para os BAs para teste. Tivemos alguns desenvolvedores que se perderam em testar os requisitos de negócios até o ponto de se esgotarem, mas apenas porque todos os testes não eram de sua responsabilidade. A menos que haja algum erro gritante que seja claramente visível, nós o enviamos para as pessoas que são pagas para entender a saída. Além disso, os usuários devem ter um papel real na verificação dos resultados. O balconista em uma loja de varejo não experimenta as roupas para você, eles só o ajudam com os "detalhes técnicos", como encontrar roupas do tamanho certo.

Uma questão é que os desenvolvedores têm pouco incentivo para quebrar seu próprio código - poucas pessoas estão dispostas a procurar por defeitos em suas próprias obras ou estão dispostas a cometer erros. Ter uma equipe separada ajuda a garantir que as coisas sejam quebradas.

Um papel de Quality Assurance é essencial, entre outras razões, para que alguém possa verificar se o desenvolvedor entendeu os requisitos. O desenvolvedor não pode fazer essa verificação por si próprio, porque se eles achavam que tinham entendido mal, isso pedia esclarecimentos.