Quando o desenvolvimento deve parar e o controle de qualidade deve começar?

Escrevemos uma especificação funcional completa para nossa equipe de desenvolvimento de dois. Não temos testadores profissionais, no entanto, contratamos, com a ajuda de nossa equipe de assistência técnica disponível, para realizar 'testes de controle de qualidade'.

No passado, tivemos problemas em que blocos completos de funcionalidade não funcionam ou o código entregue simplesmente não está de acordo com as especificações.

Minhas perguntas são: em que estágio os desenvolvedores devem parar de codificar para a equipe de controle de qualidade? É pedir demais aos desenvolvedores que revisem seu código em relação às especificações antes de entregarem à equipe de controle de qualidade?

Não deveria!

É muito difícil fazer todo o trabalho, parar e corrigir todos os problemas. Quando você resolve um problema encontrado durante o processo de controle de qualidade, pode aprender que seria melhor fazer algo diferente.

Em vez de pensar em tudo como um processo de bloqueio, tente torná-lo mais cíclico. Codifique algumas funcionalidades e teste-as. Codifique um pouco mais e teste-o (e as coisas antigas ainda funcionam). Esse processo mais fluido alivia a dificuldade de tentar carregar tudo de frente. Você ainda pode ter o conceito de congelamento de código (apenas consertar bugs) quando chegar perto do prazo, mas o ponto é testar cedo e com frequência.

Bem, se seções inteiras de código estão sendo entregues ao controle de qualidade em um estado não operacional, talvez você deva adicionar algum tipo de teste de unidade / integração ao seu processo. Não abuse do seu pessoal de controle de qualidade, fazendo-o descobrir que você falhou ao testar a unidade ou a integração do seu código.

É uma linha tênue, porque se o código é entregue de acordo com as especificações, significa que não há bugs (e não há necessidade de controle de qualidade!). O fato de o código não ser rotineiramente entregue às especificações é a razão pela qual fazemos o controle de qualidade em primeiro lugar.

Mas eu não acho que é disso que você está falando. O que você quer dizer é que a equipe de desenvolvimento parece um pouco preguiçosa com a codificação e há grandes coisas óbvias que parecem não funcionar. Estabelecer previamente que os testes de unidade precisam estar presentes para cada um dos recursos A, B e C (nas especificações) e, em seguida, revisar o código e os testes de forma independente (por um gerente ou gerente de equipe) deve ajudar a aliviar esse tipo de problema .

Eu diria que, no mínimo, os desenvolvedores deveriam ter testado o "caminho feliz". Que, se eles inserem os dados esperados, ele faz o que a especificação diz que deve fazer. Desenvolvedores que não fazem tanto assim devem ser questionados.

Também estou desapontado se um desenvolvedor não testou os casos óbvios: uma string muito longa para o banco de dados, texto obviamente inválido, se você digitar letras onde um número deve estar, etc. Se isso acontecer com frequência, perguntas devem ser feitas novamente .

No entanto, supondo que não seja mencionado especificamente na especificação, se um desenvolvedor limitar um nome apenas a maiúsculas e minúsculas, mas esquecer que alguns nomes têm apóstrofos ou permitir uma data de 29 de fevereiro de 2011 - isso é um pouco mais compreensível . A menos que estejam cometendo o mesmo erro repetidamente.

A equipe de controle de qualidade deve captar os casos extremos. Prefiro que o controle de qualidade seja testador de macacos: basta digitar lixo aleatório, verificando se eles podem quebrar o aplicativo dessa maneira.

No desenvolvimento da Web, o controle de qualidade deve tentar navegadores diferentes e encontrar plug-ins que podem afetar o código. Eles devem desativar o Javascript e o CSS e ver com o que podem se safar. Aquele tipo de coisa. Se você espera que os desenvolvedores façam isso, está gastando muito dinheiro com isso.

Se estiver sendo fornecida funcionalidade que não funcione, o problema não está entre desenvolvimento e controle de qualidade, mas entre desenvolvimento e proprietários do produto.

Os proprietários e desenvolvedores do produto devem fazer parte da mesma equipe e devem trabalhar juntos para definir o que precisa funcionar para considerar um recurso "concluído" e para garantir que o código atenda a essa necessidade.

Quando o código é entregue, o teste deve ser uma mera formalidade, porque os proprietários do produto devem ter trabalhado com os desenvolvedores ao longo do caminho para garantir que todos os casos de uso sejam cobertos.

(Se você tem testadores profissionais, eles devem fazer parte da equipe e devem estar envolvidos em todas as etapas.)

Temos um processo de triagem para projetos em que solicitamos aos desenvolvedores uma explicação / demonstração de seu código antes que ele entre no controle de qualidade. Incluímos não apenas os testadores de controle de qualidade, mas os proprietários do código, atendimento ao cliente e marketing / design. Isso tende a se concentrar nos desenvolvedores, pelo menos nos casos de uso fáceis, e às vezes a discussão resultante entre as várias equipes resulta em alterações nas especificações e um atraso na entrada no controle de qualidade. Quando podemos, envolvemos o controle de qualidade muito mais cedo no processo, o que ajuda a corrigir os erros enquanto o código ainda está quente - mas ainda fazemos o passo a passo antes do controle de qualidade "oficial" começar.

Às vezes eu disse que o código não deveria ser enviado ao controle de qualidade se você ficaria chateado se por engano fosse para produção em vez de controle de qualidade. Código com grande disfuncionalidade não pertence ao controle de qualidade (exceto em circunstâncias específicas)