Decidir Como Utilizar Produtos de Trabalho

Decida sobre quais produtos de trabalho devem ser utilizados e como utilizar cada um deles.  Além de identificar quais produtos de trabalho devem ser utilizados, também é importante ajustar cada produto de trabalho a ser utilizado deforma a atender às necessidades do projeto. 

A tabela a seguir especifica quais produtos de trabalho de Implementação são recomendados e quais são considerados opcionais (ou seja, apenas podem ser utilizados em determinados casos). Para conhecer considerações de ajuste adicionais, consulte a seção de ajuste da página de descrição do produto de trabalho.

Cobertura de Teste de Unidade

Decida em que grau o teste de unidade será desempenhado e o nível de cobertura de código, cuja  escala varia de informal a 100%. Essa escala é descrita no Plano de Teste.

O nível de cobertura do teste unitário costuma ser determinado pelas necessidades dos testadores de sistemas e de integração, para os quais o código foi encaminhado. Os testadores de sistemas dependem da qualidade do código para efetuarem seu trabalho. Se houver muitos defeitos no código, esses testadores o devolverão aos implementadores com muita freqüência. Isso é sinal de um processo de desenvolvimento de baixa qualidade; a solução pode ser exigir que os implementadores realizem testes unitários mais completos.

É claro que não se pode esperar que o código não apresente mais nenhum defeito depois da execução do teste de unidade. No entanto, é necessário encontrar um equilíbrio "saudável" entre o teste de unidade e a qualidade.

O nível de cobertura do teste unitário também pode variar de acordo com as diferentes fases. Nem mesmo um projeto cuja segurança seja muito importante e que exija 100% de cobertura do código durante a construção e a transição costuma exigir esse mesmo nível durante a elaboração, porque muitas classes são implementadas apenas parcialmente nessa etapa.

Decidir Como Revisar Código

Decida qual será o grau de revisão de código. 

As vantagens das revisões de código são:

• Implementar e estimular um estilo de codificação comum no projeto. A revisão do código é uma maneira eficiente de fazer com que os membros do projeto sigam o Guia de Programação. Para assegurar isso, é mais importante revisar os resultados de todos os autores e implementadores do que revisar todos os arquivos de código-fonte.
• Localizar erros que os testes automatizados não detectam. As revisões de código localizam erros que não tenham sido detectados nos testes.
• Compartilhar conhecimento entre as pessoas e transferi-lo das mais experientes para as menos experientes.

As desvantagens das revisões de código são:

• Demanda tempo e recursos.
• Se a revisão não for feita de forma apropriada, pode ser ineficaz. Há um risco de a revisão do código ser feita "apenas porque precisa ser feita" e não como um complemento eficiente para testes automatizados.

Para obter informações adicionais sobre revisão do código, consulte também Tarefa: Revisar Código.

A revisão do código valoriza significativamente o projeto. Pode-se observar uma melhora no desempenho dos revisores em todos os projetos que medem os níveis de erros e de problemas de manutenção relacionados a revisões de código. Em muitas organizações, porém, é difícil fazê-las "decolar", por várias razões:

• Não foram coletados dados suficientes para verificar se a revisão do código realmente funciona.
• Foram coletados dados em demasia.
• Os implementadores são muito protecionistas em relação ao código.
• As revisões se prendem demais a formalidades.
• A administração das revisões exige muito esforço.

Para fazer o melhor uso possível das revisões de código, lembre-se:

• Colete apenas dados adequados.
• Meça o desempenho das revisões e exiba o resultado.
• Utilize as revisões sem "excessos".

Para obter informações adicionais sobre níveis de revisão, consulte Diretriz: Níveis de Revisão.