O que os desenvolvedores devem testar antes de enviar seu trabalho aos testadores? [fechadas]

Existe uma lista de verificação que o desenvolvedor deve revisar antes de passar seu trabalho para os testadores?

Além disso, quais são as condições / casos em que o desenvolvedor deve prestar atenção?

Existe uma lista de verificação que o desenvolvedor deve revisar antes de passar seu trabalho para os testadores?

Absolutamente. Idealmente, esta lista de verificação consiste em dois itens:

• Verifique se o ciclo de integração contínua terminou até a conclusão e
• Faça uma entrada em um sistema de rastreamento de erros / recursos para as alterações no controle de qualidade

A lista de verificação real está oculta por trás de sua estratégia de integração contínua. Como essa lista é gerenciada centralmente e totalmente automatizada, os desenvolvedores individuais não podem lançar seu código por cima do muro para "esquecer" o controle de qualidade para verificar algo importante antes de enviar seu trabalho para a equipe de controle de qualidade. Você sabe que os desenvolvedores geralmente se tornam "esquecidos" sob pressão do tempo, certo?

O sistema de integração contínua precisa executar uma construção e executar todos os testes de unidade e integração. Escusado será dizer que os desenvolvedores precisam disponibilizar novos testes de unidade para o sistema de integração contínua à medida que desenvolvem novos recursos e corrigem bugs.

Os desenvolvedores não devem tocar no que sai do sistema de integração contínua antes de entregá-lo ao controle de qualidade, nem mesmo para instalar e testá-lo rapidamente. Se o controle de qualidade disser que a construção não foi instalada, é necessário corrigir seu ciclo de integração contínuo para garantir que ele não cuspa artefatos não instaláveis ​​ou que não funcionem.

O segundo passo é agradável (marcar um bug corrigido ou um recurso completo), de modo que os desenvolvedores raramente se esquecem de fazê-lo.

Depende. Existem várias filosofias:

• O Test Driven Development deseja que você escreva Regression / Unit-Test antes mesmo de começar a codificar.
• o codificador conhece as partes complicadas do código e pode testar em conformidade
• um testador independente pode encontrar erros nos quais o desenvolvedor nunca pensou. Além disso, o testador pode estar mais familiarizado com a área em que o software está realmente empregado e pode fazer alguma validação ("Você está construindo a coisa certa?" Em comparação com a verificação "Você está construindo a coisa certa?") Também.

Portanto, o nível de teste de cada parceiro depende do seu projeto e da sua organização. É importante concordar com esse nível de antemão. Obviamente, o código deve pelo menos compilar e executar sem gerar erros.

Faz o que foi projetado para fazer? Ele lança as exceções apropriadas quando recebe informações incorretas? É utilizável? (que se aplica às APIs e às UIs).

Seu código deve estar - dentro do seu conhecimento - livre de erros antes de entregá-lo aos testadores. Você deve fazer os testes necessários para se sentir confortável com a qualidade do seu próprio código.

Tudo o que puder que o controle de qualidade não responda a você, fazendo com que seu gerente diga "você claramente não testou esta entrega". Você pode ter testes de unidade, integração, sistema e manual (ou seja, você) à sua disposição. Não fazer isso seria apenas desperdiçar o tempo do controle de qualidade.

Um funcionário de controle de qualidade que trabalhava para mim solicitava "provas" de que os desenvolvedores haviam testado a entrega. Podem ser resultados xUnit, saída de scripts ou mesmo uma lista de verificação em papel. Basta dizer que isso impediu os desenvolvedores de apenas encaminhar a saída da compilação.

Do ponto de vista do testador, o maior erro de um desenvolvedor é fornecer um código que não seja compilado.