Deixando erros intencionais no código para que os testadores encontrem

Isso soa absolutamente maluco. Está gastando muito esforço por um benefício muito questionável, e a prática parece baseada em algumas premissas erradas:

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

• Não existem bugs introduzidos involuntariamente no software para que o QA encontre

• O trabalho do QA é encontrar bugs - não é; é garantir que o software é de qualidade de produção

• Esse tipo de batalha de inteligência entre desenvolvimento e controle de qualidade é de algum modo saudável para a empresa - não é; todos os funcionários devem estar trabalhando juntos contra os concorrentes da empresa em vez de um ao outro.

É uma ideia terrível e o gerente de projeto em questão é um idiota / idiota que não entende nada sobre pessoas e motivação. E é ruim para os negócios.

Para expandir minha descrição do "trabalho de QA:" o QA definitivamente deveria estar encontrando bugs - tanto no código quanto em suas suítes de teste - como um artefato de realizar seus trabalhos, mas a função não deveria ser definida como "você tem que encontrar bugs ". Deve ser "você tem que manter os conjuntos de testes atualizados para considerar novos recursos e garantir toda a alta cobertura de testes. Se isso não resultar em encontrar bugs, 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. Isso desperdiça o dinheiro da empresa.

O QA não está lá apenas para encontrar bugs , mas também para se preocupar com o quão intuitivo é o sistema, o que é a curva de aprendizado para o usuário, usabilidade e acessibilidade em geral. Por exemplo: "O sistema é feio ?", "O usuário é daltônico e o material é vermelho e verde?" Eles devem reclamar também.

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

tl; dr

Não são apenas bugs, os testadores devem crescer com essa visão limitada.

Má ideia.

Do ponto de vista do testador: "Então eles vão testar bastante, porque sabem que há bugs presentes e não encontrá-los pode ser considerado como sua incompetência". Basicamente, os desenvolvedores estão trapaceando o código. Poucas pessoas gostam de fazer um trabalho que, em última análise, é inútil (porque os erros são conhecidos de antemão), 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 em encontrar bugs? Isso soa como um ambiente de confronto tóxico; um QA deve ser feliz se o código que eles estão examinando for de alta qualidade. Embora se eles são pagos pelo bug ... link

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

Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working code to make sure that those bugs aren't shipped with the end product.

1. Com base na primeira declaração, você nunca realmente testa seu código de produção pretendido nesses dois passos.

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

3. Eu imagino que isso apenas treina 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 que Tom não pensou.

Editar

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

End Edit

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

É típico quando a alimentação de material através de uma máquina que o alimentador não pode empurrar o material o suficiente. Isso é chamado de "alimentação curta" e, para evitar isso, podemos instalar um "sensor de alimentação curto" (normalmente, um sensor do tipo feixe atravessado bloqueado pelo material). Este sensor detecta a extremidade do material quando atinge o comprimento total de alimentação. Em um certo 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 reportará "OK" e nunca parará a máquina. Além disso, a natureza do sensor é que o receptor liga quando o feixe o atinge, então, dependendo do tipo de sensor que você instalou, 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 seja realmente desbloqueado durante uma segunda parte do ciclo. Desta forma, verificamos se o teste ainda está funcionando (da melhor maneira possível).

Da mesma forma, há muitas maneiras de um departamento de QA falhar. Talvez os testes automatizados não tenham sido executados e o relatório esteja analisando uma cópia antiga dos dados de teste. Talvez alguém não esteja fazendo o trabalho certo. Testar o departamento de QA é uma coisa razoável a fazer.

Obviamente, o inconveniente é que um "bug de teste" pode passar pelo departamento de QA e entrar no produto final. Na indústria de manufatura, às vezes há casos em que uma parte ruim conhecida, às vezes chamada de "coelho vermelho", é inserida no processo (normalmente 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 parte é pintada de vermelho vivo (ou laranja) para que possa ser facilmente rastreada. Como alguém está observando a peça passar pelo processo durante esse teste, a chance de entrar no produto final é praticamente nula. Há, é claro, histórias apócrifas de alguém jogando uma parte ruim no processo para "ver se o sistema pode encontrá-lo" e, claro, ter que colocar em quarentena todas as partes finais produzidas naquele dia e classificá-las manualmente, mas isso é apenas um caso de não realizar o teste com a devida diligência.

Honestamente, eu chamaria esse comportamento de descaradamente antiético e impraticável. O PM está precisando de algum treinamento sério, se não de término.

• Demonstra uma falta fundamental de compreensão do conceito de garantia de qualidade . Os testadores não devem pensar como desenvolvedores: eles devem pensar como usuários finais. A razão inteira para ter equipes de controle de qualidade é que os desenvolvedores são intrinsecamente próximos demais do código; O controle de qualidade deve manter uma distância suficiente do código para que eles capturem o que os desenvolvedores perdem.
• Isso desperdiça o esforço de controle de qualidade . Supondo que esses bugs não sejam triviais - veja abaixo quando estão - significa que o controle de qualidade está gastando tempo e recursos investigando coisas que já são conhecidas, quando poderiam estar gastando esse esforço procurando o que não é conhecido.
• Isso desperdiça esforço do desenvolvedor . Para o pessoal de QA pegar 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 de software e design.
• Isso coloca a produção em risco desnecessário . É apenas uma questão de tempo até que as alterações não sejam incorporadas corretamente.
• Se não fizer o acima, então é inútil . Se todos os bugs conhecidos são triviais, então eles não vão pegar trabalhadores abaixo do padrão: eles só vão pegar pessoas que não estão fazendo nenhum trabalho. Existem maneiras melhores de fazer isso.
• Ele envenena o ambiente de trabalho . Seus testadores de QA são profissionais. Eles devem ser confiáveis para serem profissionais até que haja uma razão real para suspeitar do contrário. Quando há razão para suspeitar de outra forma, deve haver uma investigação adequada em vez desses jogos mentais. Qualquer outra coisa mata o moral.

Sério. Mesmo que a paranoia da PM se mostre bem fundamentada neste caso específico, este não é alguém que tenha qualquer testador de gerenciamento de negócios.

Pessoalmente, me sinto desconfortável com essa abordagem.

A principal coisa que me preocupa é a praticidade de inserir bugs intencionais . Isso me parece difícil de ser feito de qualquer maneira que seja previsível.

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

Além disso, o testador perderá muito tempo testando o código que não será realmente lançado. Uma vez que os erros intencionais são removidos, um re-teste completo deve ser feito de qualquer maneira, na minha opinião. Esse é o objetivo do teste. Algo muda, qualquer coisa , e você testa novamente tudo . 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 está convencido.

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

É uma má ideia por todas as razões já dadas, mas a propagação de erros é uma ferramenta útil para um propósito diferente. Você pode usá-lo para obter uma métrica aproximada de como o processo de QA é eficaz.

Em seu caso mais simples, digamos que você semeie 100 bugs e eles sejam representativos da extensão total de bugs reais (eu sei, improvável, mas estou simplificando). Você não diz ao QA que está fazendo isso para evitar estragar o experimento. No final do processo de QA digamos que eles encontraram 60 dos 100 bugs semeados (e outros bugs 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 e aplicar a taxa de erros falsa. Em nosso exemplo, se o controle de qualidade encontrou 200 bugs reais, então você pode concluir que eles encontraram apenas 60% deles, então restam 133.

É claro que essa é apenas uma estimativa ampla com barras de erro enormes. Escrever erros realistas e representativos é difícil. Os erros que você escreve provavelmente serão mais fáceis para o QA encontrar, porque os desenvolvedores são treinados para não gravar erros. Talvez seja melhor simular uma classe de erros, como erros "off-by-one", erros Unicode, estouro de buffer e assim por diante.

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

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

Má ideia.

Esse é o tipo de abordagem lógica e binária que os desenvolvedores geralmente trazem, mas é desmotivador para os QEs. Isso simplesmente demonstra uma falta de confiança. Muitas vezes, as QEs são colocadas nessas situações sem muita contribuição delas, e presumiram que estão de acordo com ela, e não é seu lugar sugerir o contrário.

Esse tipo de pensamento combina-se com EQs apenas como testadores manuais e não se sente motivado para entender o código em teste.

Eu sou um QE sênior e este é um assunto familiar na maioria das organizações em que trabalhei.

Eu diria 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 presumivelmente estar testando tudo, incluindo os recursos do bug plantado, quando eles encontrarem um, presumivelmente terão que voltar e executar esse teste novamente para verificar se esse foi realmente um bug (e não que o testador ficou confuso de algum modo). No mínimo, os testadores vão gastar tempo escrevendo os erros plantados. Então os programadores têm que gastar tempo consertando o bug que eles plantaram. Este é um grande esforço que pode ser gasto tentando escrever um bom código e escrever erros reais.

Dois: Ele envia uma mensagem clara para os testadores de que os programadores e / ou gerentes acham 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 de um programa e tivesse que gastar um 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ê estava realmente lendo ", eu acho que ficaria muito aborrecido. 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 ficando complacentes porque o primeiro código de rascunho que eles receberam foi frequentemente 100% perfeito. Eu tive que lidar com testadores preguiçosos que não fazem um trabalho adequado, mas eles não ficaram assim porque os programadores eram tão perfeitos. O melhor testador com quem já trabalhei me disse uma vez que, para um novo lançamento de software, ele estabeleceu uma meta pessoal para encontrar 100 bugs. Ok, 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 essa meta. Às vezes ele tinha que esticar as coisas, como chamar uma palavra mal-grafada em uma mensagem de "bug", mas, ei, tinha que ser consertado.

Eu realmente não acho que essa é uma idéia ruim . Há muitas coisas que especularia funcionar melhor:

1. Torne o controle de qualidade responsável pela qualidade de todas as formas possíveis. Por exemplo, fazendo do suporte sua responsabilidade também. Isso aumentará sua motivação para garantir que os produtos enviados tenham qualidade superior. Sempre é preciso menos esforço para descobrir uma inadequação (bug, obviamente falta de recursos, comportamento contra-intuitivo) e tentar entender o que seu usuário chateado está tentando explicar. E colocar um pouco dessa responsabilidade até mesmo em desenvolvedores pode aumentar sua motivação para ajudar o QA a fazer o seu trabalho da melhor maneira possível.

2. Tem 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 problemas. A avaliação da gravidade do defeito ou o 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 formas de o QA "melhorar" sempre.

Ainda assim, há um problema a ser observado se você introduzir erros intencionais: Como você sabe que o código "correto" já estava correto? Após o 2º controle de qualidade, você removeu todos bugs intencionais que não foram descobertos. Não há como saber que você não está apenas substituindo-os por códigos que foram quebrados de outra maneira ou que você não está ativando um comportamento que antes era inacessível (exemplo exagerado: alguns diálogos não foram abertos 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 bugs propositadamente ao software, mas é uma estratégia legítima para o seu conjunto de testes adicionar bugs no software como parte do processo de teste.

Ele é chamado de testes de mutação . A ideia é usar software para automatizar a criação de pequenas mudanças no código fonte (chamadas de mutantes). As mudanças são projetadas para criar comportamentos diferentes, por exemplo, poderíamos mudar

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

em

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

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

Eu gosto da ideia. Foi o general Patton quem disse: "Quanto mais você suar em paz, menos você sangra 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 de encontrar bugs não intencionais. (E você tem uma cópia do "original" para não ter que 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 erros intencionais.

Além disso, você pode ter uma ideia de como seus testadores são bons, 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á direcionando. E às vezes há conseqüências não intencionais. É o objetivo de manter o time de QA relaxado ou fazer com que alguns gerentes sintam que ele está realmente contribuindo com algo sem perceber que ele está atrapalhando.

Resultado positivo: a equipe de controle de qualidade trabalha com mais afinco para encontrar bugs. Quem sabe, talvez eles vejam isso como um desafio. É um jogo amistoso. 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. QA vê isso como mesquinho e adversário. Então, agora, eles entram em busca de hiper-bugs e retornam todos os tipos de pequenos problemas. Essa fonte não é renderizada corretamente quando eu faço uma captura de tela e a converto em um pdf e a visualizo em 500%.

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

Todos 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 um lançamento que possui erros de código intencionais? Isso afeta o moral dos trabalhadores e a produtividade em outras áreas? Aumentar o volume de negócios? Você nos diz.

Vindo de um mundo onde os desenvolvedores devem escrever e executar os testes eles mesmos, esse silo "testando" "QA" ao qual você está se referindo me assusta e me confunde, então tentarei responder dessa perspectiva. Como um aparte, engenheiros de QA qualificados, na minha perspectiva, (como é bem descrito na resposta do @ SparK), devem focar nas questões maiores de assegurar que o software satisfaça totalmente as histórias do usuário e tenha "qualidade" geral (em relação a o domínio para o qual o software é destinado), em vez de procurar por bugs.

O que me atraiu aqui é a menção do @ JamesMcleod de "injeção de defeitos" nos comentários da pergunta. Eu realmente acho que ter os desenvolvedores pensando em como eles poderiam injetar bugs no sistema é uma ótima idéia para direcionar o conceito de defesa em profundidade. Nenhum bug único deve ser suficiente para derrubar todo o sistema de forma descontrolada (sem logging claro e acionável), causar corrupção de dados ou, por si só, expor uma vulnerabilidade de segurança.

Fazer com que os desenvolvedores de cada componente criem defeitos intencionais, lidar com os de outros componentes e, em geral, inserir uma mentalidade mais antagônica sobre seu software poderia fazer muito para melhorar a robustez do software. Mesmo o benefício imediato pode ser significativo - eu exigiria que durante cada injeção de um novo tipo de defeito (que até agora não foi testado), o desenvolvedor imediatamente o cobriria com um novo teste, que será definido com uma bandeira que irá permitir que o bug viva na base de código sem ser perturbado por um curto período de tempo, e então ligado antes da entrega (e o defeito removido), para se transformar 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 Primeiros Socorros" : Quando seus sistemas precisam funcionar ", que descreve testes tão extensos da infra-estrutura de software a serem usados pela equipe de Obama para as eleições de 2012.

Como outros já disseram, não é tarefa do QA encontrar apenas bugs. Eu iria mais longe 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. Os conjuntos de testes devem ser executados antes mesmo que o novo código seja confirmado, e se os conjuntos de teste falharem, ele nunca deverá estar passando para o QA em primeiro lugar. Introduzir bugs intencionalmente significa que você definitivamente não pode passar por suas suítes de teste, então por que seu código vai para o controle de qualidade?

O trabalho de QA é validar o aplicativo em relação às 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 que o usuário deve ser capaz de fazer, da maneira mais utilizável e acessível possível. Ao fazer isso, é claro, eles podem se deparar com bugs, mas isso é um efeito colateral do que eles fazem, não o que eles fazem. Lembre-se de que QA significa garantia de qualidade, e não garantia sem erros.

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

Então, se você estruturá-lo corretamente, você pode usar essa técnica para estimar quantos erros não encontrados permanecem no produto que você está prestes a enviar. Então, imagine que você tenha artificialmente semeado 100 bugs em sua versão de teste, e os testadores encontram 50 deles. Então você pode inferir que há uma certa probabilidade de que, se eles também encontrarem 50 insetos não descobertos, talvez ainda restem 50.

Claro, isso é repleto de muitos problemas. Você pode decidir se envia com base nessas estatísticas, mas na vida real, você pode encontrar um problema muito desagradável, ou mil irritações menores.

Ainda assim - conhecimento é poder e, sem essa técnica, você tem menos ideia da qualidade de 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: testes de mutação .

É onde uma ferramenta automatizada pega seu código-fonte e insere deliberadamente bugs nele. (Por exemplo, exclua uma instrução escolhida aleatoriamente, altere uma AND para uma OR ou o que for.) Em seguida, ela executa a suíte de testes completa e verifica se os testes são aprovados.

Se todos os testes forem aprovados, existem duas possibilidades:

• A coisa que foi alterada não faz nada. Em outras palavras, você tem código morto.
• A alteração introduziu um bug que sua suíte de teste não está detectando. Você precisa de mais testes.

Note que, ao contrário da sua proposta, tudo o que descrevi acima é automatizado . Você não está desperdiçando tempo dos desenvolvedores inserindo erros desnecessários à mão. E você não está desperdiçando tempo dos testadores para encontrar bugs conhecidos. A única coisa que você está usando é o tempo da máquina, que é muito mais barato. (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 de mutação automatizada é uma abordagem muito melhor do que o cenário manual do qual você está falando.

Note que se você pedir a um desenvolvedor que insira bugs manualmente, o tipo de bug que você recebe provavelmente não é representativo do tipo de erros que os humanos podem cometer. (Por exemplo, se você ainda não percebeu que há uma possível condição de corrida, é improvável que você insira uma condição deliberada também). Se uma ferramenta automatizada consegue ser mais objetiva, é claro que…

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

Você pode, então, dividir intencionalmente o código de produção para verificar se os testes ainda funcionam.

Existem vários níveis em que isso é possível:

• Um desenvolvedor que acabou de refatorar um 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 acabou 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 (ou seja, baseada em protocolo), a empresa pode querer manter um conjunto de versões de produtos defeituosas conhecidas e executar testes contra elas, a fim de testar o teste de regressão.

Se essas coisas fazem sentido, depende. Se eu sou um desenvolvedor e eu levo apenas um minuto para injetar um bug, teste o teste da unidade, remova o bug - então porque 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 eu não iria cometer / entregar / fazer check-in / push acidentalmente. O mesmo vale para o testador e o teste de aceitação.

Se faz sentido para uma organização manter conjuntos de versões de produtos defeituosos conhecidos e o teste de regressão depende do teste. Para uma loja online eu não faria. Para embarcações automotivas, embarcadas aeroespaciais, cartões bancários ou cartões de TV paga, eu o faria.

Quanto esforço isso depende strongmente de como os testes são desacoplados do código de produção. Quanto mais dissociados forem os testes do código de produção, menor será o esforço para fazer isso, quanto mais coesivos forem os testes com o código de produção, maior será o esforço.

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

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

Um desenvolvedor que está verificando o código com defeito conhecido em o repositório está fazendo errado. (2)

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

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

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

Esta é uma tentativa de um argumento de "argumento de venda" mais curto possível, que deve fazer sentido imediato para desenvolvedores, testadores e gerentes.

Eu não recomendo deliberadamente injetar bugs em TODOS os builds enviados para o controle de qualidade.

Você poderia, de vez em quando, digamos uma vez por ano, fazer uma "auditoria de controle de qualidade" encoberta. Pegue uma base de código "testada e funcionando" e tantos novos recursos pequenos da sua lista de tarefas quanto possível. Implemente-os "um pouco mais desleixadamente" do que você normalmente faz. Pense nos casos de borda, escreva-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 sejam de trabalho do que você escreveu, certamente não é o seu QA que precisa de supervisão ...; -)