Os testadores precisam examinar o código-fonte?

Quão necessário é para os testadores fazerem testes em caixa branca, além dos testes em caixa preta? Como desenvolvedor, vejo valor em fazer com que uma pessoa com controle de qualidade repasse meu código e procure por pontos fracos, mas também parece que se um testador não técnico for minucioso e metódico o suficiente, eles poderão cobrir bem o aplicativo.

O teste da caixa branca pode revelar casos de teste importantes que não seriam óbvios ao olhar apenas para o aplicativo da perspectiva do usuário, mas o teste exclusivo da caixa preta pode levar menos tempo e aumenta significativamente o número de pessoas capazes de fazer o trabalho . Além disso, uma quantidade não trivial de testes de caixa branca deve ser executada pelo desenvolvedor antes que ele chegue ao testador, estou certo?

Os testes de caixa branca e caixa preta são duas habilidades diferentes - alguém habilitado em um não é necessariamente habilidoso no outro.

Muito do que o controle de qualidade faz será o teste da caixa preta - garantindo que o sistema funcione "conforme anunciado" e, nesse sentido, eles não precisam saber como o sistema funciona para fazer um bom trabalho. De fato, o conhecimento do código pode levá-los às mesmas armadilhas que capturam o desenvolvedor incauto fazendo seus próprios testes. É muito melhor que eles não tenham preconceitos de como o desenvolvedor pensa que o sistema deve funcionar.

Isso não quer dizer que não deve haver teste de caixa branca - que é (em parte) o que é o teste de unidade do desenvolvedor. Um bom conjunto de testes de unidade deve estar testando entradas válidas, entradas inválidas e entradas de caixa de borda. No entanto, não acho que seja sempre necessário que o controle de qualidade faça isso - se por outro motivo, não for realmente de responsabilidade do desenvolvedor.

No entanto, como SnOfus aponta em seus comentários, um bom teste de caixa branca pode ser extremamente útil.

Tive boa sorte na minha equipe com as análises de código dos testadores. Os testadores tendem a olhar o código da mesma forma que os aplicativos - eles se perguntam "de que maneira esse código não funcionaria" e geralmente encontram problemas que os programadores não encontram durante a revisão do código.

Para uma resposta mais longa, escrevi este artigo .

absolutamente

Como eu disse em resposta ao @ChrisF: O controle de qualidade existe para garantir que o código de produção funcione sempre . Sem ser exaustivo, isso significa saber quais plataformas são esperadas, qual será o estado da máquina implantada, quais são os requisitos de desempenho e ter certeza de que todas as linhas serão bem-sucedidas.

No IME, uma boa equipe de controle de qualidade escreverá, lerá e revisará mais código do que a equipe de desenvolvimento.

Se suas equipes de recursos e as (principais) equipes de correção de bugs não têm um desenvolvedor de controle de qualidade trabalhando para projetar a API, o fluxo de trabalho, a segurança e todos os outros aspectos do recurso / correção, você está realmente perdendo uma força que seu departamento de controle de qualidade pode trazer para o seu produto enquanto ele estiver sendo desenvolvido .

Não é necessário. Em vez de fazer com que uma pessoa com controle de qualidade analise seu código, recomendo que um desenvolvedor analise seu código. Além disso, se você estiver escrevendo testes de unidade à medida que desenvolve seu código, fazer com que uma pessoa com mente de controle de qualidade passe por seu código não é o melhor uso do tempo do controle de qualidade.

A pessoa do controle de qualidade não deve se concentrar em como o código foi escrito, mas no que o código faz.

A pessoa do controle de qualidade não deve focar em testes funcionais e aproveitar os requisitos para fazer esses testes. No final, testes de unidade e um testador funcional de controle de qualidade fazendo testes de caixa preta serão o melhor uso do tempo para todos.