Os programadores devem ajudar os testadores a projetar testes?

Quanto os programadores devem ajudar os testadores a projetar testes?

Eu não acho que eles devam ajudar. Minha preocupação é que, se eles ajudarem os testadores a projetar testes para seu próprio código, eles 'infectarão' os testadores com seus próprios preconceitos e pontos cegos sobre esse código.

Eu sinto que os requisitos devem ser suficientes para fornecer as informações necessárias para os testadores criarem seus testes. Se há alguma parte da implementação que os programadores consideram preocupante, acho que é seu dever implementar testes de unidade para testar essa parte ou até executar seus próprios testes informais do sistema para testá-la.

Nem todos que eu conheço concordam com isso (e eu entendo alguns de seus pontos até certo ponto). O que os outros pensam sobre isso? Isso é discutido na literatura em algum lugar?

Concordo. Os programadores podem ajudar os testadores a entender as especificações funcionais, a encontrar recursos para pesquisa, mas não devem poluir a mente dos testadores com suas próprias idéias sobre como abordar os testes.

Acho que há espaço para desenvolvedores e testadores coexistirem pacificamente no campo do controle de qualidade. :)

Mais especificamente, acho que os desenvolvedores devem ser responsáveis ​​pelo primeiro nível de teste - testes de unidade e testes básicos de integração para garantir que o material funcione na maioria dos casos antes de entregá-lo aos testadores.

Cabe aos testadores criar testes de aceitação com base em requisitos completamente independentes de qualquer detalhe de implementação (isso geralmente é chamado de 'teste de caixa preta'). Se houver uma discrepância no modo como testadores e desenvolvedores entendem os requisitos, é um problema que deve ser tratado pelo gerente de projeto (se houver) ou para garantir que todos estejam na mesma página na fase de design do recurso.

Eu acho que tanto o teste quanto o desenvolvimento são esforços colaborativos ; portanto, é claro (IMO), os desenvolvedores devem fornecer idéias de teste aos testadores. Eu não acho que isso os infecte ou prejudique os testadores. O testador, é claro, deve aprimorar esses testes com muitas outras abordagens de teste.

Também sou um grande fã de testadores, ajudando os desenvolvedores - fiz um brainstorming de idéias de design com os desenvolvedores e emparelhei com eles para corrigir bugs (e apontei os bugs e sugeri as correções) muitas vezes na minha carreira, e acho que não '. já maculei um desenvolvedor com cooties de testador.

Se você não vê isso como um esforço colaborativo, basta ter o código "jogado por cima do muro" do dev para testar ... e você acabará com uma qualidade inferior. Essa é a verdade no meu mundo, mas (é claro), sim.

A meu ver, não é o trabalho do controle de qualidade testar meu código. O trabalho do testador é garantir que meu código cumpra todos os requisitos para essa tarefa.

Quando passo algo para o controle de qualidade, certifico-me de que eles sabem a tarefa que eu estava realizando, não as especificidades do meu código. Eu nunca transmito nada ao controle de qualidade que contenha erros de "cabeça de osso". Isso desperdiça meu tempo, o tempo deles ... e o tempo de quase todo mundo.

No meu último trabalho, tivemos controle de qualidade desde o início. Isso ocorreu nas sessões de coleta de requisitos, nas reuniões do projeto e nas reuniões de design. Eles ouviram e fizeram perguntas e, enquanto os desenvolvedores escreviam código, escreviam seus planos de teste. Funcionou muito bem e pegamos muitos problemas que provavelmente teriam escapado.

Eu acho que você está completamente errado aqui. Fui testador e desenvolvedor e me beneficiei bastante como testador com a orientação dos desenvolvedores em áreas que eles consideravam de alto risco ou frágil; como desenvolvedor, quero que os testadores encontrem os problemas que ainda não investiguei profundamente.

Não havia "poluição", a menos que seu código fosse esgoto bruto, e isso seria por um motivo completamente diferente.

Os requisitos fazem um trabalho terrível de comunicar os problemas técnicos com os quais um profissional de controle de qualidade se importaria, porque elaboram, na melhor das hipóteses, apenas o que os analistas de negócios conseguiram capturar. Bons desenvolvedores estarão cientes de que seu código é otimizado em torno do "caminho feliz" e desejarão saber o que deixaram sem serem considerados. Eles terão pelo menos uma intuição do que pode dar errado e de quais áreas eles gostariam que o controle de qualidade investigasse. Eles também sabem qual é o cenário geral de risco em torno de um recurso específico com base em seu design.

Como um testador ausente da orientação da equipe de desenvolvimento, às vezes segui uma abordagem errada que gerava bons relatórios de erros, mas não exercitava completamente os caminhos de código de alto risco e problemas maiores, que poderiam ter sido evitados através de uma melhor colaboração com a equipe de desenvolvimento, enviada aos clientes.

Embora um testador certamente não deva limitar-se a testar apenas o que o desenvolvedor diz ser importante, ele não será prejudicado ao saber quais são as preocupações dos desenvolvedores sobre o código. Às vezes, eles podem ajustar sua abordagem com base no conhecimento da implementação. Somente se um testador for particularmente míope, ele considerará a opinião do desenvolvedor sobre quais são os riscos como a palavra final; eles não fecharão completamente as coisas que o desenvolvedor identifica como de baixo risco, mas investirão mais esforços em coisas que possam ter um impacto maior no cliente.

É provável que a equipe de controle de qualidade veja áreas com grande escopo de teste combinatório que os coletores de requisitos ou desenvolvedores de um sistema, mas eles podem não estar cientes dos componentes do sistema que possuem um tipo mais sutil de fragilidade que se beneficia da conscientização do design ou implementação do sistema.

Na minha experiência, a colaboração entre controle de qualidade e desenvolvimento produz produtos de melhor qualidade. Eu nunca recomendaria fazer apenas uma transferência de caixa preta.

Como testador, não tenho nenhuma objeção aos programadores que sugerem casos de teste (embora isso não signifique que vou me ater apenas a esses casos de teste) ou descrevendo detalhes da implementação. Às vezes, pode ser realmente útil ter alguém dizendo "Eu acho que esse bit pode ser arriscado, eu realmente gostaria que você testasse esse bit completamente". Conhecer alguns detalhes da implementação me ajuda a aplicar anos de experiência para escolher os testes que acho que provavelmente falharão. Às vezes, apenas uma breve menção significa que alguns testes aumentam repentinamente a minha lista de prioridades.

Isso me macula? Eu meio que fico impressionado com a idéia de que os programadores se esforçam cavalheiresco para preservar a pureza do meu testador, mas realmente - não, isso é um mito. Mais informações geralmente provocam ainda mais perguntas para mim, não menos. Eu acho que é uma coisa de mentalidade - não encontro bugs porque sou ignorante, encontro problemas porque sou um tipo cético e pouco confiável, que é teimoso demais para acreditar em tudo. Em todos os sistemas que testei, descobri que encontrei mais problemas e outros "interessantes", mais profundamente entendo.

Gosto de revisar os planos de teste e sugerir casos de teste adicionais nos quais o controle de qualidade pode não ter pensado. Não tenho certeza de como isso "infectaria os testadores com meus próprios preconceitos".

Eu me encontrei nessa posição estranha que eu preciso implementar e escrever casos de teste no Selenium depois, já que temos pouco pessoal de controle de qualidade. Acredito que o desenvolvimento orientado a testes seria extremamente útil, mas ainda não está adaptado em minha loja.

Uma coisa que acho útil para escrever testes é encontrar erros quando escrevo testes. Penso em uma perspectiva diferente para me ajudar a escrever um código mais robusto. Mas é verdade que a cobertura do teste pode ser limitada. Nesse caso, os QAs sempre podem nos informar o que eles gostariam que fossem cobertos. Ou, podemos adicionar passivamente mais testes quando vemos erros.

Estou fazendo controle de qualidade e, diferentemente da maioria dos domínios, saber como usar nosso código é muito mais difícil do que aprender qualquer linguagem de programação. Portanto, contamos com os desenvolvedores para nos fornecer casos de teste para seus novos recursos whizzbang, porque não saberíamos como. De qualquer forma, os problemas de controle de qualidade são mais para capturar regressões e coisas que quebram do que o teste original de novos recursos. Em qualquer caso, quando o resultado é uma computação complexa, é difícil saber o que é uma resposta correta e o que é uma resposta errada, ou mesmo se uma terminação anormal é uma coisa boa ou ruim.

De qualquer forma, um desenvolvedor, se ele for honesto, provavelmente conhece algumas das vulnerabilidades de seus bebês. Ele provavelmente sabe em quais valores de parâmetro, ele precisa selecionar diferentes algoritmos ou domínios em uma pesquisa de tabela ou o que quer. Sabendo que, se ele é sincero sobre testes rigorosos, deve poder gerar um conjunto de testes de tamanho razoável que cubra grande parte do código.