Criar um sistema completamente duplicado para garantia de qualidade (QA) de outra pessoa é uma prática ruim?

No trabalho, temos um sistema bastante complicado. Vamos chamar esse sistema, System_A. Nossa equipe de controle de qualidade criou outro sistema, chame esse sistema, System_B, para testar System_A.

A maneira como System_B é usado é a seguinte. Geramos entradas (usando o próprio System_B), IN, processamos essas entradas de volta através do System_B e geramos saídas, O_B. Portanto, o processo é o seguinte:

System_B(IN) -> O_B.

Em seguida, fazemos o mesmo para o System_A gerar suas próprias saídas, O_A:

System_A(IN) -> O_A.

A qualquer momento, assume-se que O_B é a saída esperada e O_A é a saída observada / real. Implícito é que O_B é a fonte "ouro" (a verdade). No entanto, encontramos uma combinação de problemas.

• O_A está errado, O_B está certo
• O_A está certo, O_B está certo
• O_A está errado, O_B está errado
• O_A está certo, O_B está errado

Quem determina o que é certo se O_B é considerado sempre correto (ou o que é esperado)? Bem, acontece que O_B às vezes (ou freqüentemente) está errado na inspeção e análise humana. As coisas passarão pelo controle de qualidade usando esse processo, e usuários reais reclamarão, e voltamos a descobrir que O_B estava errado, afinal.

A questão é a seguinte: é uma má prática criar um "sistema de teste" para testar o sistema real?

• E a encosta escorregadia? Então, não podemos argumentar que precisamos de outro sistema para testar o "sistema de teste"?
• O custo é definitivamente proibitivo, pois os desenvolvedores agora precisam aprender pelo menos duas bases de código, talvez com a complexidade do System_B maior que o System_A. Como quantificaríamos quão bom ou ruim ter o System_B por perto é para a organização?
• Um dos motivos "convincentes" originais para criar o System_B foi "automatizar" o teste. Agora, temos muito orgulho de ser totalmente automatizados (porque o System_B gera a entrada para inicializar o processo de uso próprio para também gerar a saída). Mas acho que fizemos mais mal e introduzimos mais complexidade, de maneira não quantificável. O trabalho do controle de qualidade deve ser totalmente automatizado? Essa razão é suficiente para justificar a criação de um sistema paralelo?
• Minha real preocupação é essa, mesmo que todos saibamos que o System_B está errado (com bastante frequência). Se System_B é tão bom no processamento da entrada e sua saída é a fonte de ouro, por que não substituir System_A por System_B? Para isso, ninguém no trabalho é capaz de fornecer uma resposta satisfatória.

Qualquer orientação sobre esse assunto é apreciada.

• O_A está errado, O_B está certo

Fix A

• O_A está certo, O_B está errado

Fix B

• O_A está certo, O_B está certo

Felizmente, eles também concordam.

• O_A está errado, O_B está errado

Felizmente, eles não concordam, então você saberá fazer algo a respeito.

Nenhum processo pega tudo. Claro, você duplicou seu código, mas pense nele como o 2 em O (2n). O controle de qualidade automatizado até os testes de integração é uma coisa maravilhosa. O teste manual é um obstáculo à inovação. Especialmente em mudanças transversais que exigiriam um teste completo. Além disso, como diferentes programadores implementam a mesma coisa, você pode fazê-los correr.

Deve haver pessoas diferentes para aumentar as chances de obter bugs diferentes. Eu não aconselho a criação do sistema B lidando com o sistema A. Tudo o que você fornece é um teste de regressão. Você pode obter a mesma coisa simplesmente salvando cópias antigas de O_A para comparar com novas.

A questão é a seguinte: é uma má prática criar um "sistema de teste" para testar o sistema real?

Se for, todos os testes são ruins.

• E a encosta escorregadia? Então, não podemos argumentar que precisamos de outro sistema para testar o "sistema de teste"?

Sim, podemos argumentar isso. Vamos chamar esse terceiro sistema, system_A. : P

• O custo é definitivamente proibitivo, pois os desenvolvedores agora precisam aprender pelo menos duas bases de código, talvez com a complexidade do System_B maior que o System_A. Como quantificaríamos quão bom ou ruim ter o System_B por perto é para a organização?

Pelo número de clientes satisfeitos que nos pagam para brincar com armas nerf. Você se livrou do custo dos testes manuais. Você criou algo cuja utilidade será comprovada toda vez que um bug for detectado por ele. O bug detectado no início custa muito menos do que o relatado no final.

• Um dos motivos "convincentes" originais para criar o System_B foi "automatizar" o teste. Agora, temos muito orgulho de ser totalmente automatizados (porque o System_B gera a entrada para inicializar o processo de uso próprio para também gerar a saída). Mas acho que fizemos mais mal e introduzimos mais complexidade, de maneira não quantificável. O trabalho do controle de qualidade deve ser totalmente automatizado? Essa razão é suficiente para justificar a criação de um sistema paralelo?

A complexidade do System_B é maravilhosamente isolada do System_A. Não é mais difícil adicionar recursos ao System_A porque o System_B existe. É realmente mais fácil, porque o System_B lhes dá confiança para avançar rapidamente.

• Minha real preocupação é essa, mesmo que todos saibamos que o System_B está errado (com bastante frequência). Se System_B é tão bom no processamento da entrada e sua saída é a fonte de ouro, por que não substituir System_A por System_B? Para isso, ninguém no trabalho é capaz de fornecer uma resposta satisfatória.

Isso é um erro de digitação? O System_B geralmente está errado, então é o padrão-ouro que você deseja usar para substituir o System_A?

Eu vou assumir que você quis dizer que System_A geralmente está errado. Realmente não importa qual deles está errado com mais frequência. O que estiver errado é aquele que precisa de trabalho. Esses sistemas não decidem o certo e o errado, os desenvolvedores decidem. O que o teste faz é produzir um desagrado que significa que algo não está certo. Os desenvolvedores descobrem o que é isso. Lembre-se, não há padrão ouro sendo produzido aqui. Há apenas acordo ou desacordo. O desacordo exige que o trabalho precise ser feito. Parte desse trabalho é descobrir onde.

Quando você tem um sistema em produção que é realmente usado pelos clientes, é essencial ter um sistema de controle de qualidade para verificar correções de erros e novas funcionalidades. Do ponto de vista da qualidade, deve ser a réplica o mais próxima possível do sistema de produção. Dessa forma, se você garantir que o sistema de produção e seu sistema de controle de qualidade sejam idênticos, o que funciona em um deve funcionar no outro. Se não for esse o caso, os sistemas não são idênticos, as entradas não são idênticas e / ou as saídas são mal interpretadas.

Isso vale duplamente, se o seu sistema é de missão crítica e precisa estar disponível 24 horas por dia, 7 dias por semana. Você não pode atribuir o luxo a não ter um sistema de controle de qualidade, porque deve minimizar absolutamente o tempo de inatividade no sistema de produção. E se for um sistema 24/7, a réplica exata do sistema de produção é uma recomendação muito, muito forte.

Agora, a desvantagem óbvia dessa abordagem é o custo. Dobra os custos de hardware e aumenta os custos de implantação e manutenção. Além disso, uma replicação contínua dos dados do sistema de produção para o controle de qualidade teria que ser implementada, para minimizar a possibilidade de resultados diferentes devido à diferença nos dados com os quais os sistemas trabalham.

Em geral, é possível encontrar um equilíbrio ao reduzir alguns dos componentes do sistema de controle de qualidade em relação ao sistema de produção, para que a maioria das funcionalidades possa ser testada corretamente. Esses geralmente são servidores redundantes, tamanho de servidores ou número de estações de trabalho. No entanto, é minha experiência que algum bug sempre é encontrado exatamente na parte que foi redimensionada e, em seguida, é um pesadelo reproduzir o problema e implementar a correção, mantendo o tempo de inatividade mínimo permitido no sistema de produção.

Sempre que você testar um sistema, você precisa saber qual é o resultado esperado.

O problema de ter um sistema gerando esse resultado esperado é obviamente 'como faço para testar esse sistema'

Mesmo assim, não é comum ver pessoas usarem planilhas, por exemplo, para gerar conjuntos de resultados esperados.

No final do dia, você realmente precisa de um humano para interpretar os requisitos do sistema e produzir manualmente o resultado esperado. Se você tiver um sistema, faça isso e verifique apenas as diferenças, então você está pulando o teste.