Deixando erros intencionais no código para os testadores encontrarem

Não fazemos isso em nossa empresa, mas um de meus amigos diz que seu gerente de projetos pediu a todos os desenvolvedores que adicionassem bugs intencionais pouco antes do produto passar para o controle de qualidade. É assim que funciona:

1. Pouco antes do produto ir para o controle de qualidade, a equipe de desenvolvimento adiciona alguns erros intencionais em locais aleatórios no código. Eles fazem o backup correto do código de trabalho original para garantir que esses erros não sejam enviados com o produto final.
2. Os testadores também são informados sobre isso. Portanto, eles testam muito, porque sabem que há bugs presentes e que não encontrá-los pode ser considerado um sinal de incompetência.
3. Se um erro (intencional ou não) for encontrado, eles serão relatados para a equipe de desenvolvimento corrigir. A equipe de desenvolvimento adiciona outro bug intencional em uma seção relacionada do código, pouco antes do produto ir para o controle de qualidade de segundo nível. O gerente de projeto diz que um testador deve pensar como um desenvolvedor e esperar novos erros nas seções em que foram feitas alterações.

Bem, é assim que acontece. Eles dizem que essa abordagem tem as seguintes vantagens.

1. Os testadores estarão sempre na ponta dos pés e testarão como loucos. Isso os ajuda a encontrar também erros ocultos (não intencionais) para que os desenvolvedores possam corrigi-los.
2. Os testadores se alimentam de bugs. Não encontrar nenhum erro afetará sua moral. Portanto, dar a eles uma tarefa fácil de encontrar ajudará o moral deles.

Se você ignora o cenário em que um desses erros intencionais é enviado com o produto final, quais são as outras desvantagens que devemos considerar antes de pensar em adotar essa abordagem?

Alguns esclarecimentos:

1. Eles fazem backup corretamente do código original no controle de origem.
2. Quando um testador encontra o erro intencional, a equipe de desenvolvimento simplesmente o ignora. Se o testador descobrir um erro não intencional (original), a equipe de desenvolvimento primeiro verificará se foi causado por algum erro intencional. Ou seja, a equipe de desenvolvimento primeiro tenta reproduzir isso no código de trabalho original e tenta corrigi-lo, se puder.
3. Apenas ignore os problemas de relacionamento entre o controle de qualidade e a equipe de desenvolvimento. Fiz especificamente essa pergunta em programadores , não no local de trabalho . Considere que há um bom relacionamento entre o controle de qualidade e a equipe de desenvolvimento, e eles festejam juntos após o horário de trabalho. O gerente de projeto é um senhor gentil e velho que está sempre pronto para apoiar as duas equipes (dádiva de Deus).

Isso parece absolutamente maluco. Está se esforçando muito para obter benefícios muito questionáveis, e a prática parece baseada em algumas premissas defeituosas:

• Esse controle de qualidade não funcionará muito, a menos que eles saibam que estão sendo testados todos os dias (o que não pode ser bom para a moral)

• Que não há erros introduzidos não intencionalmente no software para que o controle de qualidade encontre

• O trabalho desse controle de qualidade é encontrar bugs - não é; é garantir que o software tenha qualidade de produção

• Que esse tipo de batalha entre o desenvolvimento e o controle de qualidade é de alguma forma saudável para a empresa - não é; todos os funcionários devem estar trabalhando juntos contra os concorrentes da empresa e não entre si.

É uma péssima idéia e o gerente de projeto em questão é um idiota / idiota que não entende nada sobre pessoas e motivação. E isso é ruim para os negócios.

Para expandir minha descrição do "trabalho do controle de qualidade:" o controle de qualidade definitivamente deve encontrar bugs - tanto no código quanto em seus conjuntos de testes - como um artefato para o desempenho de seus trabalhos, mas a função não deve ser definida como "você precisa encontrar insetos." Deve ser "você deve manter os conjuntos de testes atualizados para dar conta de novos recursos e garantir toda a alta cobertura dos testes. Se isso não resultar na localização de erros, os procedimentos de teste não são suficientemente sofisticados para o produto.

Bem, com base no que aprendi:

1. Não é uma escola nem uma entrevista de emprego;
2. Os testadores não são crianças;
3. Não é um jogo;
4. Desperdiça dinheiro da empresa.

O controle de qualidade não existe apenas para encontrar erros, mas também para se preocupar com o quão intuitivo o sistema é, qual é a curva de aprendizado para o usuário, a usabilidade e a acessibilidade em geral. Por exemplo: "O sistema é feio ?", "O usuário é daltônico e o material é vermelho e verde?" Eles deveriam reclamar também.

Os requisitos mínimos para um sistema passar no controle de qualidade são geralmente descritos em uma história de usuário para esse recurso em particular ou em quão mágico o OP queria que o sistema estivesse em sua cabeça.

tl; dr

Não são apenas erros, os testadores devem crescer fora dessa visão restrita.

Péssima ideia.

Do ponto de vista do testador: "Portanto, eles testarão muito, porque sabem que há bugs presentes e não encontrá-los pode ser considerado como sua incompetência". Basicamente, os desenvolvedores estão interceptando o código. Poucas pessoas gostam de fazer trabalhos que, em última análise, são inúteis (porque os bugs são conhecidos antecipadamente), mas que ainda afetam a forma como são percebidos. Se houver punições tangíveis por não encontrar as armadilhas, mais ainda. E você sabe que os testadores prosperam ao encontrar bugs? Isso soa como um ambiente de confronto tóxico; um controle de qualidade deve ser feliz se o código que eles estão examinando for de alta qualidade. Embora se eles são pagos pelo bug ... http://thedailywtf.com/articles/The-Defect-Black-Market

Do ponto de vista do desenvolvedor: os QAs estão sendo incentivados a encontrar os bugs que você sabe que existem. Isso pode aumentar a probabilidade de erros reais saírem pela porta; os QAs estão gastando pelo menos parte do tempo procurando o tipo de bug que é fácil de plantar, e não realmente sutis. Além disso, há uma pequena chance de que uma armadilha possa sair pela porta.

Eu concordo totalmente com as respostas acima sobre por que isso é ruim para a motivação e para a gestão de pessoas geralmente péssima. No entanto, provavelmente existem boas razões técnicas para não fazer isso também:

Pouco antes do produto ir para o controle de qualidade, a equipe de desenvolvimento adiciona alguns bugs intencionais em locais aleatórios no código. Eles fazem o backup correto do código de trabalho original para garantir que esses erros não sejam enviados com o produto final.

1. Com base na primeira declaração, você nunca testa o código de produção pretendido nessas duas passagens.

2. Eu imagino que você aumente bastante a probabilidade de incluir acidentalmente um bug "intencional" em seu código de produção liberado ao tentar apressar uma alteração para um cliente. Pode causar algumas bochechas vermelhas em algum momento.

3. Eu imagino que isso apenas treine seus testadores para pensar como seus desenvolvedores (ou seja, como Tom adicionaria um bug aqui), o que provavelmente os torna menos propensos a encontrar os bugs nos quais Tom não pensou.

Editar

Quero deixar claro que esta resposta está apenas falando sobre o conceito de testar seu processo de controle de qualidade e não estou defendendo a metodologia específica retratada na pergunta.

Finalizar edição

Há um motivo válido para verificar se o seu teste / verificação está realmente funcionando. Deixe-me dar um exemplo da fabricação, mas o princípio é o mesmo.

É típico ao alimentar o material através de uma máquina que o alimentador pode não empurrar o material o suficiente. Isso é chamado de "alimentação curta" e, para evitar isso, podemos instalar um "sensor de alimentação curta" (normalmente um sensor do tipo de barreira que é bloqueado pelo material). Este sensor detecta o final do material quando atinge o comprimento total de alimentação. Em um determinado ponto do ciclo da máquina, verificamos se o sensor está bloqueado e paramos a máquina se a verificação falhar.

Agora você precisa pensar em como o teste pode falhar. Por exemplo, alguma sujeira ou outros detritos podem bloquear o sensor e ele sempre informa "OK" e nunca para a máquina. Além disso, a natureza do sensor é que o receptor liga quando o feixe o atinge; portanto, dependendo do tipo de sensor instalado, você recebe eletricamente uma entrada "ON" quando o sensor não está bloqueado . Isso significa que, se o cabo foi cortado ou a energia foi perdida para esse sensor, ou a entrada falhou, a lógica do seu programa seria "OFF" e isso significaria "bloqueado" ou "OK".

Para capturar esses modos de falha do teste, normalmente inserimos uma segunda verificação para garantir que o sensor esteja realmente desbloqueado durante uma segunda parte do ciclo. Dessa maneira, verificamos se o teste ainda está em operação (da melhor maneira possível).

Da mesma forma, existem muitas maneiras pelas quais um departamento de controle de qualidade pode falhar. Talvez os testes automatizados não tenham sido executados e o relatório esteja analisando uma cópia antiga dos dados do teste. Talvez alguém não esteja fazendo seu trabalho corretamente. Testar o departamento de controle de qualidade é uma coisa razoável a se fazer.

Obviamente, a desvantagem é que um "bug de teste" poderia passar pelo departamento de controle de qualidade e entrar no produto acabado. Na indústria de manufatura, às vezes há casos em que uma peça defeituosa conhecida, às vezes chamada de "Coelho Vermelho", é inserida no processo (geralmente por alguém do controle de qualidade) e eles observam essa parte passar pelo processo e medir quanto tempo leva para encontre a peça e remova-a. Normalmente, esta peça é pintada de vermelho brilhante (ou laranja) para que possa ser facilmente rastreada. Como alguém está assistindo a peça passar pelo processo durante esse teste, a chance de entrar no produto final é praticamente nula. Existem, é claro, histórias apócrifas de alguém jogando uma parte ruim conhecida no processo para "ver se o sistema pode encontrá-la",

Honestamente, eu chamaria esse comportamento flagrantemente antiético e impraticável. O PM precisa de algum treinamento sério, se não de rescisão.

• Isso demonstra uma falta fundamental de entendimento do conceito de garantia de qualidade . Os testadores não devem pensar como desenvolvedores: devem pensar como usuários finais. Todo o motivo de ter equipes de controle de qualidade é que os desenvolvedores são inerentemente muito próximos do código; O controle de qualidade deve manter distância suficiente do código para que eles possam capturar o que os desenvolvedores sentem falta.
• Desperdiça o esforço de controle de qualidade . Assumindo que esses bugs não sejam triviais - veja abaixo quando são -, isso significa que o controle de qualidade está gastando tempo e recursos investigando coisas que já são conhecidas, quando eles poderiam estar gastando esse esforço procurando o que não é conhecido.
• Desperdiça o esforço do desenvolvedor . Para que o pessoal do controle de qualidade consiga detectar esses bugs não triviais, os desenvolvedores devem primeiro escrevê-los. Isso requer ainda mais esforço, gasto não apenas codificando os bugs, mas também considerando os requisitos e o design do software.
• Coloca a produção em risco desnecessário . É apenas uma questão de tempo até que as alterações não sejam mescladas corretamente.
• Se isso não acontecer, não fará sentido . Se todos os bugs conhecidos são triviais, eles não pegam trabalhadores abaixo do padrão: eles apenas pegam pessoas que não fazem nenhum trabalho. Existem melhores maneiras de fazer isso.
• Envenena o ambiente de trabalho . Seus testadores de controle de qualidade são profissionais. Eles devem ser confiáveis ​​para serem profissionais até que haja uma razão real para suspeitar do contrário. Quando não é razão para suspeitar de outra forma, deve haver uma investigação adequada, em vez de esses jogos mentais. Qualquer outra coisa mata moral.

A sério. Mesmo que a paranóia do primeiro-ministro se mostre bem fundamentada nesse caso específico, não é alguém que tenha negócios gerenciando testadores.

Pessoalmente, me sinto desconfortável com essa abordagem.

O principal que me preocupa é a praticidade de inserir bugs intencionais . Parece-me difícil fazer isso de maneira previsível.

Qualquer alteração no código (intencional ou não) corre o risco de causar efeitos colaterais. Esses efeitos colaterais podem muito bem ser revelados durante o teste, mas pode não ser óbvio (mesmo para o desenvolvedor que plantou o bug) qual é a causa raiz. Não parece "seguro", se você entende o que quero dizer (estou falando do meu intestino aqui).

Além disso, o testador desperdiçará muito tempo testando código que não será realmente lançado. Depois que os erros intencionais são removidos, um re-teste completo deve ser feito de qualquer maneira, na minha opinião. Esse é o objetivo dos testes. Algo muda, qualquer coisa , e você testa tudo novamente . Ok, eu sei que isso nunca acontece na prática, mas é disso que se trata o teste de regressão.

Então, no geral, não estou convencido.

Por outro lado, tendemos a permitir que os clientes verifiquem o trabalho das equipes de controle de qualidade, o que possivelmente não é o ideal. É um loop de feedback muito poderoso.

É uma má idéia por todas as razões já apresentadas, mas a propagação de bugs é uma ferramenta útil para uma finalidade diferente. Você pode usá-lo para obter uma métrica aproximada de quão eficaz é o processo de controle de qualidade.

No seu caso mais simples, digamos que você semeia 100 bugs e eles são representativos de toda a extensão de bugs reais (eu sei, improvável, mas estou simplificando). Você não diz ao controle de qualidade que está fazendo isso para evitar estragar o experimento. No final do processo de controle de qualidade, digamos que eles encontraram 60 dos 100 erros propagados (e outros erros reais). Agora você sabe que o controle de qualidade está encontrando 60% dos erros.

Você pode estender isso ainda mais contando o número de bugs reais encontrados no controle de qualidade e aplicar a taxa de bugs falsos. No nosso exemplo, se o controle de qualidade encontrou 200 erros reais, você pode concluir que eles encontraram apenas 60% deles, restando 133.

Obviamente, essa é apenas uma estimativa ampla com enormes barras de erro. Escrever bugs realistas e representativos é difícil. É provável que os erros que você escreve sejam mais fáceis de encontrar pelo controle de qualidade, porque os desenvolvedores são treinados para não escrever erros. Talvez seja melhor simular uma classe de erros, como erros de um por um, erros de Unicode, estouros de buffer e assim por diante.

Isso deve ser aplicado a todo o processo de controle de qualidade , que inclui testes de unidade do desenvolvedor, integração contínua e, se disponível, uma equipe de controle de qualidade dedicada.

Essa é uma métrica e não deve ser invadida como uma ferramenta motivacional de gerenciamento.

Péssima ideia.

Esse é o tipo de abordagem lógica e binária que os desenvolvedores costumam oferecer, mas é desmotivadora para os QEs. Simplesmente demonstra falta de confiança. Os QEs geralmente são colocados nessas situações sem muita contribuição deles, e assumiram que eles estão bem com isso, e não é o lugar deles sugerir o contrário.

Esse tipo de pensamento se combina com os QEs sendo apenas testadores manuais e não sendo motivados a entender o código real em teste.

Sou QE sênior e esse é um problema familiar na maioria das organizações em que trabalhei.

Eu diria que é uma má ideia.

Um: os programadores vão gastar tempo colocando erros deliberados no código e algum esforço para salvar a boa versão. Embora os testadores devam estar testando tudo, inclusive os recursos com o bug plantado, quando encontrarem um, eles provavelmente terão que voltar e executar novamente o teste para verificar se isso foi realmente um bug (e não que o testador tenha se confundido) de algum modo). No mínimo, os testadores gastam tempo escrevendo os bugs plantados. Em seguida, os programadores precisam gastar tempo consertando o bug que plantaram. É muito esforço que poderia ser gasto tentando escrever um bom código e criar bugs reais.

Segundo: envia uma mensagem clara aos testadores de que os programadores e / ou a gerência pensam que não estão fazendo seu trabalho e devem ser tratados como crianças. Não consigo imaginar que isso seja bom para o moral. Como programador, se eu recebesse especificações ambíguas ou contraditórias para um programa e tivesse que gastar muito tempo para esclarecê-las, e depois de perder horas ou dias meu chefe me disse: "Ah, sim, eu deliberadamente coloquei declarações contraditórias em as especificações apenas para ter certeza de que você realmente as estava lendo ", acho que ficaria muito irritado. Se isso acontecesse regularmente, isso poderia ser suficiente para me fazer procurar outro emprego.

Na vida real, todas as alterações, exceto as mais triviais, terão bugs. Eu nunca tive um problema com os testadores sendo complacentes porque o primeiro código de rascunho que eles receberam era geralmente 100% perfeito. Eu tive que lidar com testadores preguiçosos que não fazem um trabalho adequado, mas eles não foram assim porque os programadores eram tão perfeitos. A melhor pessoa de teste com quem já trabalhei me disse que, para uma nova versão do software, ele estabeleceu uma meta pessoal para encontrar 100 bugs. Tudo bem, se 100 é um número realista, depende do tamanho do produto e da extensão das alterações, mas, no nosso caso, ele quase sempre conseguiu atingir esse objetivo. Às vezes, ele precisava esticar as coisas, como chamar uma palavra incorreta em uma mensagem de "bug", mas, ei, isso precisava ser corrigido.

Post script: Se você fizer isso, aposto que mais cedo ou mais tarde os programadores irão deliberadamente plantar um bug, os testadores não encontrarão aquele específico e os programadores se esquecem de devolver o bom código. Portanto, agora um bug deliberadamente plantado é enviado ao cliente.

Realmente não acho que seja uma má ideia. Eu especularia muitas coisas que funcionam melhor:

1. Responsabilize o controle de qualidade pela qualidade da maneira que puder. Por exemplo, apoiando sua responsabilidade também. Isso aumentará sua motivação para garantir que os produtos enviados tenham maior qualidade. Sempre é preciso menos esforço para descobrir uma inadequação (bug, obviamente, falta de recurso, comportamento contra-intuitivo) e depois tentar entender o que o usuário chateado está tentando explicar. E colocar parte dessa responsabilidade mesmo nos desenvolvedores pode aumentar sua motivação para ajudar o controle de qualidade a fazer o trabalho da melhor maneira possível.

2. Tenha várias equipes de controle de qualidade, que podem competir. Você precisa encontrar uma métrica sensata, é claro. Definitivamente não é apenas o número de questões. A consideração da gravidade do defeito ou do valor comercial (conforme determinado pelas partes interessadas) dos aprimoramentos propostos deve ajudar.

É difícil dizer se o controle de qualidade é "bom o suficiente". É mais fácil e possivelmente ainda melhor a longo prazo, encontrar maneiras de o controle de qualidade estar "sempre melhorando".

Ainda assim, há um problema a ser observado se você introduzir erros intencionais: como você sabe que o código "correto" realmente estava correto em primeiro lugar? Após o segundo controle de qualidade, você remove todos os erros intencionais que não foram descobertos. Não há como saber que você não está apenas substituindo-os por código que está quebrado de uma maneira diferente ou que você não está ativando um comportamento quebrado que antes era inacessível (exemplo exagerado: algumas caixas de diálogo não foram abertas devido a um erro intencional, mas o diálogo em si está quebrado - você simplesmente não descobre porque os testadores não conseguiram vê-lo).

Como outros já disseram, os desenvolvedores não devem adicionar propositalmente bugs no software, mas é uma estratégia legítima para o seu conjunto de testes adicionar bugs ao software como parte do processo de teste.

É chamado teste de mutação . A idéia é usar o software para automatizar a criação de pequenas alterações no código fonte (chamadas mutantes). As mudanças são projetadas para criar comportamentos diferentes, por exemplo, podemos mudar

if x < 10:
    print "X is small!"

para dentro

# we flipped the inequality operator
if x > 10:
    print "X is small!"

e um bom teste de unidade deve detectar que o fragmento de código mutante não funciona mais como o esperado e mata o mutante . Quando o código original passa no teste, e todos os mutantes (que não são equivalentes funcionalmente) falham no teste, você sabe que seu código e seus testes são fortes .

Eu gosto da ideia. Foi o general Patton quem disse: "Quanto mais você suar em paz, menos sangrará na guerra".

Colocar erros intencionais "desperdiça tempo" dos testadores. Mas isso também os faz trabalhar mais, o que significa que eles também farão um trabalho melhor para encontrar bugs não intencionais. (E você tem uma cópia do "original" para não precisar viver com o que fez.)

Encontrar mais erros não intencionais provavelmente poupará mais sofrimento a longo prazo do que o custo de lidar com os intencionais.

Além disso, você pode ter uma idéia de quão bons são seus testadores, e não um pequeno benefício em si.

Não há base para uma recompensa ou punição por mérito próprio, mas pelo resultado do comportamento que você está alvejando. E, às vezes, há consequências não intencionais. O objetivo é impedir que a equipe de controle de qualidade se afrouxe ou fazer com que algum gerente sinta que está realmente contribuindo com algo sem perceber que está apenas atrapalhando.

Resultado positivo - A equipe de controle de qualidade trabalha mais para encontrar bugs. Quem sabe, talvez eles vejam isso como um desafio. É um jogo amigável. Ou eles estão apenas fazendo porque estão sendo vigiados (Efeito Hawthorne?).

Resultado negativo - Eles podem não trabalhar mais e encontrar o bug de qualquer maneira. O controle de qualidade vê isso como mesquinho e contraditório. Então, agora, eles entram na unidade de busca de bugs e retornam todos os tipos de pequenos problemas. Essa fonte não é renderizada corretamente quando eu tiro uma captura de tela e a converto em pdf e a vejo em 500%.

Sem impacto - me parece que isso não faz diferença, então por que se preocupar? Você corre o risco de perder tempo e irritar as pessoas.

Todos nós podemos concordar que isso não funcionará 90% do tempo. Isso não faz muito bem aos outros 10%. Teste as coisas por si mesmo. Os clientes estão mais satisfeitos com uma versão que possui os erros de código intencionais? Isso afeta o moral e a produtividade do trabalhador em outras áreas? Aumentar a rotatividade? Você nos diz.

Vindo de um mundo em que os desenvolvedores devem escrever e executar os testes, esse silo de "teste" "QA" ao qual você se refere me assusta e me confunde, então tentarei responder dessa perspectiva. Como um aparte, engenheiros de controle de qualidade qualificados, da minha perspectiva (conforme descrito na resposta do @ SparK), devem se concentrar nos problemas maiores para garantir que o software satisfaça totalmente as histórias do usuário e tenha "qualidade" geral (em relação a o domínio ao qual o software se destina), em vez de procurar bugs.

O que me atraiu aqui é a menção de @JamesMcleod sobre "injeção de defeito" nos comentários à pergunta. Na verdade, acho que fazer com que os desenvolvedores pensem em como podem injetar bugs no sistema é uma ótima idéia para direcionar o conceito de defesa em profundidade. Nenhum bug deve ser suficiente para derrubar todo o sistema de maneira descontrolada (sem registro acionável claro), causar corrupção de dados ou expor por si só uma vulnerabilidade de segurança.

Fazer com que os desenvolvedores de cada componente criem defeitos intencionais, lidem com os de outros componentes e, em geral, adotem uma mentalidade mais adversa sobre seu software, poderia fazer muito para melhorar a robustez do software. Até o benefício imediato pode ser significativo - eu exigiria que, durante cada injeção desse tipo de defeito (até então não testado), o desenvolvedor o cobrisse imediatamente por um novo teste, que será definido com uma bandeira que permita que o bug permaneça inalterado por um curto período de tempo e depois ligue antes da entrega (e o defeito removido) se transforme em um teste regular que tornará o conjunto de testes mais abrangente.

Uma opção relacionada é o uso de sinalizadores de recursos para desativar intencionalmente recursos em componentes específicos para examinar como outros componentes lidam com isso. Também gostaria de recomendar a leitura do livro / artigo gratuito "Aprendendo com os socorristas: quando seus sistemas precisam funcionar", que descreve testes tão extensos da infraestrutura de software a serem usados ​​pela equipe de Obama nas eleições de 2012.

Como outros já disseram, não é tarefa do controle de qualidade apenas encontrar bugs. Eu iria além e diria que não é o trabalho deles, tecnicamente. Os desenvolvedores devem ser responsáveis ​​por manter seu próprio código livre de erros. As suítes de teste devem ser executadas antes que o novo código seja confirmado e, se as suítes de teste falharem, nunca será necessário fazer o controle de qualidade. A introdução de bugs intencionalmente significa que você definitivamente não pode passar nos seus conjuntos de testes. Por que seu código está indo para o controle de qualidade?

O trabalho do controle de qualidade é validar o aplicativo com base nas histórias de usuário que ele implementa. Eles devem testar o fluxo, a interface do usuário etc. e garantir que o usuário possa fazer tudo o que puder, da maneira mais utilizável e acessível possível. Ao fazer isso, é claro, eles podem encontrar erros, mas esse é um efeito colateral do que eles fazem, não do que fazem. Lembre-se de controle de qualidade significa garantia de qualidade, não garantia livre de erros.

Isso não é necessariamente tão louco quanto parece. Depende bastante da sua motivação. Se você está procurando um bastão para vencer sua equipe de teste, isso seria uma loucura. Por outro lado, uma das coisas mais difíceis no desenvolvimento de software é saber quão eficaz é sua abordagem de teste.

Portanto, se você a estruturar adequadamente, poderá usar esta técnica para estimar quantos bugs não encontrados permanecem no produto que está prestes a enviar. Imagine que você propôs 100 bugs artificialmente na sua compilação de teste, e os testadores encontram 50 deles. Então você pode deduzir que há uma certa probabilidade de que, se eles também encontrassem 50 bugs não-semeados, talvez sobrem 50 para encontrar.

Claro, isso está cheio de muitos problemas. Você pode decidir se deve enviar com base nessas estatísticas, mas na vida real, pode encontrar um problema muito desagradável ou mil pequenas irritações.

Ainda - o conhecimento é poder e, sem essa técnica, você tem ainda menos idéia da qualidade da sua base de código. Se você puder implementá-lo respeitosamente e pelos motivos certos, eu diria "Por que não?"

Uma coisa que ninguém mais mencionou ainda: teste de mutação .

É aqui que uma ferramenta automatizada pega seu código-fonte e insere deliberadamente erros nele. (Por exemplo, exclua uma instrução escolhida aleatoriamente, altere um AND para um OR ou qualquer outra coisa.) Em seguida, ele executa todo o seu conjunto de testes e verifica se os testes são aprovados.

Se todos os testes forem aprovados, há duas possibilidades:

• O que foi alterado não faz nada. Em outras palavras, você tem código morto.
• A alteração introduziu um bug que seu conjunto de testes não está detectando. Você precisa de mais testes.

Observe que, diferentemente da sua proposta, tudo o que descrevi acima é automatizado . Você não está perdendo tempo dos desenvolvedores inserindo bugs inúteis manualmente. E você não está perdendo tempo dos testadores encontrando bugs conhecidos. A única coisa que você está gastando é o tempo da máquina, que é muito mais barato. (As máquinas não se cansam de fazer o mesmo teste 20.000 vezes. Os humanos param de se importar depois de um tempo!)

Eu sugeriria que o teste automatizado de mutações é uma abordagem muito, muito melhor do que o cenário manual de que você está falando.

Observe que, se você solicitar a um desenvolvedor que insira manualmente os erros, o tipo de erro que você recebe provavelmente não é representativo do tipo de erros acidentais que os humanos podem cometer. (Por exemplo, se você ainda não percebeu que existe uma condição de corrida possível, é improvável que você insira uma condição deliberada.) Se uma ferramenta automatizada consegue ser mais objetiva ainda está para ser vista, é claro ...

Embora seja uma má ideia em geral (as outras respostas explicam perfeitamente o porquê), há algumas situações especiais em que intencionalmente injetar bugs no código de produção de uma maneira controlada e temporária pode fazer sentido.

Quando você refatorar o código de teste - e você deve, o código de teste merece a mesma atenção aos detalhes que o código de produção - você pode querer saber se o código de teste ainda está encontrando os bugs que deveria encontrar.

Em seguida, é possível quebrar intencionalmente o código de produção para verificar se os testes ainda funcionam.

Existem vários níveis nos quais isso é possível:

• Um desenvolvedor que acaba de refatorar algum teste de unidade pode quebrar o código de produção para verificar se o teste de unidade ainda encontra o que deveria encontrar.
• Um testador que acaba de refatorar algum teste de aceitação pode quebrar o código de produção para verificar se o teste de aceitação ainda verifica o que deve verificar.
• Se a interface for estável e robusta o suficiente (por exemplo, com base em protocolo), a empresa pode querer manter um conjunto de versões conhecidas de produtos defeituosos e executar testes contra eles para fazer o teste de regressão.

Se essas coisas fazem sentido depende. Se eu sou um desenvolvedor e levo apenas um minuto para injetar um bug, testar o teste de unidade, remover o bug - por que não? Mas eu deveria ter meu editor, meu ciclo e meu sistema de controle de versão sob um controle tão bom que não acidentalmente confirmar / entregar / fazer check-in / enviar o bug. O mesmo vale para o testador e o teste de aceitação.

Se faz sentido para uma organização manter conjuntos de versões conhecidas de produtos com defeito e teste de regressão, o teste depende. Para uma loja online eu não. Para cartões automotivos, aeroespaciais, bancários ou de TV paga, eu o faria.

A quantidade de esforço necessária depende fortemente da dissociação dos testes do código de produção. Quanto mais dissociados forem os testes do código de produção, menos esforço será feito, mais coesos os testes serão com o código de produção, mais esforço.

O motivo é simplesmente o seguinte: quando seus testes e seu código de produção são coesos, a alteração do código de produção exige a alteração frequente dos testes, o que interromperia a dependência entre os testes e as amostras de produção com defeito. Você precisaria também manter as amostras de produção com defeito. Em casos raros, mesmo isso pode valer a pena, e a zombaria e o uso inteligente de um sistema de controle de versão podem reduzir significativamente o esforço, mas isso requer desenvolvedores muito acima da capacidade.

O conceito de injetar intencionalmente falhas no código de produção é chamado sabotagem , a falha injetada é chamada sabotador .

Um testador que não está recebendo o código a ser testado diretamente do repositório está fazendo errado. (1)

Um desenvolvedor que está verificando o código defeituoso conhecido no repositório está fazendo errado. 2)

Portanto, neste estágio, já não há como esse esquema funcionar sem que um ou os dois lados violem premissas muito básicas de como o desenvolvimento e o teste devem ser feitos.

(1) Porque você precisa documentar qual versão testou. Uma versão marcada com um hash Git ou um número de revisão SVN é algo que você pode testar, "o código que Joe me deu" não é.

(2) Porque você simplesmente não faz isso, fora de um driver de teste que está esperando falha.

Esta é uma tentativa de uma razão de "passo do elevador" mais curta possível que deve fazer sentido imediato para desenvolvedores, testadores e gerenciamento.

Eu recomendo contra injetar deliberadamente erros em TODAS as compilações enviadas para o controle de qualidade.

De tempos em tempos, digamos que uma vez por ano, faça uma "auditoria de controle de qualidade" encoberta. Faça uma base de código "testada e funcionando" e o mínimo possível de novos recursos da sua lista de tarefas. Implemente-os "um pouco mais desleixado" do que costuma fazer. Pense nos casos extremos, anote-os, mas não corrija seu código para levá-los em consideração. Envie para o controle de qualidade.

Se eles encontrarem mais bugs de casos que não estão funcionando do que você anotou, certamente não é seu controle de qualidade que precisa de supervisão ... ;-)