Teste do desenvolvedor vs.Testes da equipe de controle de qualidade – Qual é a divisão correta do trabalho?[fechado]

Question

Enquanto tentava defender mais testes de desenvolvedor, acho o argumento "Não é esse o trabalho de QA?" é muito usado.Na minha opinião, não faz sentido dar à equipe de controle de qualidade todas as responsabilidades de teste, mas ao mesmo tempo Spolsky e outros dizem que você não deveria usar os desenvolvedores de US$ 100/hora para fazer algo que um testador de US$ 30/hora poderia estar fazendo .Quais são as experiências de outras pessoas em uma empresa com uma equipe de controle de qualidade dedicada?Onde deve ser traçada a divisão do trabalho?

Esclarecimento:Eu quis dizer controle de qualidade como uma equipe de validação e verificação.Os desenvolvedores não deveriam fazer a validação (teste focado no cliente), mas onde está o ponto de divisão da verificação (teste funcional)?

Answer 1

É a diferença entre testes de "caixa preta" (onde você sabe o que o código deve fazer, mas não como funciona) e testes de "caixa branca" (onde saber como funciona orienta como você o testa).O teste de "caixa preta" é o que a maioria das pessoas pensa quando menciona a Garantia de Qualidade.

Trabalho para uma empresa onde a equipe de controle de qualidade também é desenvolvedora de software.(Isso restringe o campo bastante se você quiser adivinhar a empresa.) Conheço a opinião de Joel e minha experiência me leva a discordar parcialmente:pela mesma razão que um hacker "white hat" é mais eficaz em encontrar falhas de segurança, certos tipos de erros são encontrados com mais eficiência por testadores de caixa branca que sabem como escrever código (e, portanto, quais são os erros comuns - por exemplo, gerenciamento de recursos problemas como vazamentos de memória).

Além disso, como os desenvolvedores orientados para controle de qualidade fazem parte do processo desde a fase inicial de design, eles podem, teoricamente, ajudar a gerar código de maior qualidade ao longo do processo.Idealmente, para cada desenvolvedor trabalhando no projeto com foco mental na funcionalidade, você tem um desenvolvedor adversário com foco mental em quebrar o código (e assim torná-lo melhor).

Visto sob essa luz, é menos uma questão de usar desenvolvedores como testadores do que uma espécie de programação em pares desconectada, onde um desenvolvedor enfatiza o controle de qualidade.

Por outro lado, muitos testes (como funcionalidades básicas da interface do usuário) francamente não precisam desse tipo de habilidade.É aí que Joel tem razão.

Para muitas empresas, pude ver um sistema em que as equipes de programação trocam tarefas de revisão e teste de código entre si.Os membros da equipe de lógica de negócios, por exemplo, poderiam fazer um tour ocasional testando e revisando o código para a equipe de UI e vice-versa.Dessa forma, você não está "desperdiçando" o talento do desenvolvedor em testes em tempo integral, mas está ganhando as vantagens de expor o código ao (espero) escrutínio e punição de especialistas.Então, uma equipe de controle de qualidade mais tradicional pode realizar os testes da “caixa preta”.

Answer 2

Quando apropriado, as equipes de controle de qualidade devem ser capazes de realizar testes de segurança, regressão, usabilidade, desempenho, estresse, instalação/atualização e não desenvolvedores

Os desenvolvedores devem fazer testes unitários com cobertura de código para o código que está sendo escrito como um objetivo mínimo.

No meio, ainda há alguns testes a serem feitos

• teste completo do caminho do código
• Teste de componentes
• Teste de integração (de componentes)
• Teste de sistema (integração)
• etc.

A responsabilidade por estes é mista entre GQ e Desenvolvimento com base em algum acordo mútuo sobre o que faz mais sentido.Alguns testes de componentes só podem ser feitos por testes unitários, outros são testados 'suficientemente' durante testes de integração, etc.

Conversem entre si, descubram o que todos se sentem mais confortáveis ​​em fazer.Levará algum tempo, mas vale a pena.

Answer 3

Sempre deve haver alguns testes de desenvolvedor.Se um desenvolvedor estiver produzindo muitos bugs, ele estará perdendo tempo corrigindo-os posteriormente.É importante que os desenvolvedores não desenvolvam a atitude que diz, tudo bem, se eu deixar um bug, ele será detectado e terei a chance de corrigi-lo.

Tentamos manter um limite para bugs produzidos.Se esse limite for ultrapassado durante o teste, o desenvolvedor será responsável por isso.Cabe a você decidir qual é esse limite (para nós pode variar de projeto para projeto).

Além disso, todos os testes unitários são feitos pelos desenvolvedores.

Answer 4

Estou no setor há apenas um ano, mas, pela minha experiência, os desenvolvedores são responsáveis ​​pelos testes unitários de seus recursos, enquanto o controle de qualidade é responsável pelos cenários de teste.Espera-se também que o controle de qualidade teste quaisquer condições de limite.

Answer 5

Estou colando minha resposta a uma pergunta em nosso fórum interno.Se você tiver uma hora ou mais..ouça a música de Mary Poppendieck Competindo com base na velocidade vídeo. Recomendado

Observação (por testadores - refiro-me à equipe de controle de qualidade)

Desenvolvedor/Testes unitários ________=_______ Teste de usabilidade e exploratório testando

'==================================================================

Aceitação/Testes de cliente ___=_____ Teste de propriedade

Imagine que isso seja um quadrado com quatro quadrantes.:)

A metade esquerda deve ser automatizada.

• Os testes do desenvolvedor verificam se o código funciona como o codificador queria.Ferramentas:NUnit / xUnit / qualquer ferramenta caseira
• Os testes do cliente verificam se o código funciona como o cliente desejava.Os testes devem ser muito fáceis de escrever, não devem exigir que o cliente aprenda .NET/Java.Caso contrário, o cliente não escreverá esses testes (embora possa precisar da ajuda de um desenvolvedor).O Fit, por exemplo, usa tabelas HTML que podem ser escritas em Word.Ferramentas:As ferramentas de regressão de ajuste também estão aqui.Repetição de gravação.

A metade direita utiliza melhor o tempo e o esforço de bons testadores.por exemplo.Nenhum teste automatizado pode dizer se o diálogo X é utilizável.Os humanos são melhores nisso do que as máquinas.

• Usabilidade.Tente quebrar o sistema (capture cenários de falha não tratados, insira valores nulos).Basicamente, pegue coisas que o desenvolvedor perdeu.
• O teste de propriedade novamente requer humanos.Aqui você verifica as propriedades exigidas pelo cliente que são exigidas pelo seu sistema.por exemplo.Desempenho - sua caixa de diálogo de pesquisa atende ao tempo de resposta de 2 segundos?Segurança - alguém pode invadir este sistema?etc.Disponibilidade – seu sistema fica online 99,99% do tempo?

Os testadores não deveriam perder tempo executando planos de teste na metade esquerda.É responsabilidade dos desenvolvedores garantir que o código funcione como o cliente e o desenvolvedor pretendiam.Os testadores podem de fato ajudar o cliente a formular os testes de aceitação.

Answer 6

O teste deve ser o mais automatizado possível, o que o transforma novamente em trabalho de desenvolvimento se os testadores estiverem escrevendo código que será adicionado ao conjunto de testes automatizados.

Além disso, descobri que realizamos muito controle de qualidade na revisão de código, pois as pessoas sugerem casos extras e extremos que desejam ver adicionados aos testes de unidade que estão sendo revisados ​​(junto com o código que testam, é claro) .

Answer 7

Minha posição geral é que os testadores nunca devem encontrar bugs em nível de unidade (incluindo casos limite).Os bugs encontrados pelos testadores devem estar no nível do componente, da integração ou do sistema.É claro que, a princípio, os testadores podem encontrar bugs do "caminho feliz" e outros bugs simples, mas essas anomalias devem ser usadas para ajudar os desenvolvedores a melhorar.

Parte do seu problema pode ser usar desenvolvedores de US$ 100 por hora e testadores de US$ 30 por hora :}.Mas, independentemente do custo, acho que sabendo que os bugs encontrados no início do ciclo de desenvolvimento são inevitavelmente mais baratos, você provavelmente ainda economizaria dinheiro fazendo com que os desenvolvedores fizessem mais testes.Se você tiver uma equipe de desenvolvimento altamente paga e testadores de hackers, provavelmente encontrará muitos dos grandes problemas óbvios, mas perderá muitos dos bugs mais obscuros que voltarão para assombrá-lo mais tarde.

Então, suponho que a resposta à sua pergunta é que os testadores devem testar tanto quanto você quiser.Você pode demitir todos os seus testadores e fazer com que os desenvolvedores façam todos os testes, ou pode contratar um exército de testadores e deixar os desenvolvedores verificarem o que quiserem.

Answer 8

Existem 2 tipos de grupos de controle de qualidade: aqueles que desejam manter o status quo.Sempre fizemos isso.Eles naturalmente odeiam e se livram daqueles que tentam tornar as coisas mais eficientes e, portanto, vão além de sua zona de conforto.Isso aconteceu comigo mais de uma vez.Infelizmente, os gerentes de controle de qualidade são tão incompetentes quanto suas equipes de controle de qualidade.Portanto, um gerente de controle de qualidade que gerencia há 6 anos eliminará qualquer automação e introduzirá muitos processos apenas para justificar sua existência. É responsabilidade da alta administração reconhecer isso.Existem pessoas um tanto técnicas que conhecem ferramentas.Infelizmente uma linguagem de programação não é uma ferramenta, mas uma visão.Trabalhar com essas pessoas realmente depende do quanto elas estão dispostas a aprender e do quanto a administração está disposta a correr o risco de mudar as coisas.Os testes devem ser escritos da mesma forma que um código principal é escrito em uma estrutura orientada a objetos de fácil manutenção.Eu acho que os desenvolvedores deveriam revisar os testes de controle de qualidade.Na maioria das vezes descobri que a automação não testava nada.Infelizmente qa obra é considerada de classe baixa, então os desenvolvedores não se incomodam.Eu mesmo tenho sorte quando consigo o apoio de um desenvolvedor influente em um grupo, que está disposto a explicar meus esforços a um gerente.Funciona apenas metade das vezes, infelizmente.Os testadores IMHO devem reportar ao gerente de desenvolvimento.E toda equipe deve assumir a responsabilidade pelo que os testes de controle de qualidade realmente testam.

Answer 9

Aqui estão algumas maneiras pelas quais o teste do desenvolvedor é o mais eficiente/maior retorno:

• O desenvolvedor modifica uma biblioteca compartilhada enquanto trabalha em um recurso - o desenvolvedor tem insights sobre possíveis efeitos colaterais que o controle de qualidade/validação não tem
• O desenvolvedor não tem certeza do desempenho da chamada da biblioteca e escreve um teste de unidade
• O desenvolvedor descobre o caminho do caso de uso não considerado nas especificações que o código deve suportar, escreve o código, atualiza as especificações, escreve o teste

É discutível quanto trabalho de teste deve ser realizado pelo desenvolvedor no terceiro exemplo, mas eu argumento que é mais eficiente para o desenvolvedor porque todas as minúcias relacionadas de muitas camadas de documentação e código já estão em sua memória de curto prazo.Esta tempestade perfeita pode não ser alcançada por um testador após o fato.

Estamos falando de controle de qualidade ou validação?Penso no controle de qualidade nos moldes de listas de verificação de inspeção, aplicação de padrões de código, diretrizes de UI, etc.Se estamos falando de validação, não faz sentido que os desenvolvedores gastem muito tempo criando e executando casos de teste formais, mas os desenvolvedores devem fornecer toda a justificativa e documentação de design necessária para criar bons testes.