Os testes são aplicados a tipos diferentes de destinos, em diferentes estágios ou níveis de esforço de trabalho. Esses níveis são normalmente distintos por essas funções que são melhores habilitadas para projetar e conduzir os testes e em que as técnicas são mais apropriadas para os testes em cada nível. É importante assegurar que um equilíbrio de ênfase seja retido em diferentes esforços de trabalho.

Teste de Desenvolvedor

O teste do desenvolvedor indica os aspectos do design de teste e a implementação mais apropriada para a equipe de desenvolvedores. Isso contrasta com o Teste Independente. Na maioria dos casos, a execução do teste inicialmente ocorre com o grupo de teste do desenvolvedor que projetou e implementou o teste, mas é uma boa prática para os desenvolvedores para criar seus testes de modo que fiquem disponíveis para execução de grupos de teste independentes.

Tradicionalmente, o teste do desenvolvedor foi considerado principalmente em respeito ao teste de unidade. Enquanto alguns desenvolvedores também executam testes de integração em níveis variados, isso depende muito da cultura e outras questões de contexto. Recomendamos que o teste do desenvolvedor cubra mais do que apenas as unidades independentes de teste em isolamento.

Teste Independente

O teste independente indica que o design de teste e a implementação mais apropriadamente executados por alguém que é independente da equipe de desenvolvedores. Você pode considerar essa distinção um superconjunto, que inclui a Verificação Independente & Validação. Na maioria dos casos, a execução do teste inicialmente ocorre com o grupo de teste independente que projetou e implementou o teste, mas os testadores independentes devem criar os testes para torná-los disponíveis para os grupos de teste do desenvolvedor executarem. O Boris Beizer dá a seguinte explicação sobre o objetivo diferente que o teste independente tem no teste do desenvolvedor:

"A finalidade do teste independente é fornecer uma perspectiva diferente e, portanto, testes diferentes; além disso, conduzir esses testes em um ambiente [...] mais rico do que é possível para o desenvolvedor." [BEI95]

Teste Independente de Envolvidos

Uma visualização alternativa do teste independente é que representa o teste que tem como base as necessidades e preocupações de vários envolvidos. Portanto, é chamado de Teste de Envolvidos. Essa é uma distinção importante, ajuda a incluir um conjunto maior das preocupações dos envolvidos que podem tradicionalmente ser consideradas, estendendo de algum modo o "cliente" genérico com os envolvidos, como a equipe de suporte técnico, instrutores técnicos e equipe de vendas, além de clientes e usuários.

Como um comentário final, a noção do XP de testes do cliente está relacionada a esta categorização de teste independente no RUP.

Teste de Unidade

O teste de unidade enfoca a verificação dos menores elementos testáveis do software. Normalmente o teste de unidade é aplicado aos componentes representados no modelo de implementação para verificar se os fluxos de controle e de dados estão cobertos e se eles funcionam conforme o esperado. O Implementador executa o teste de unidade na medida em que a unidade é desenvolvida. Os detalhes do teste de unidade são descritos na disciplina Implementação.

Teste de Integração

O teste de integração é executado para assegurar que os componentes no modelo de implementação operem adequadamente quando combinado para executar um caso de uso. O objetivo do teste é um pacote ou conjunto de pacotes do modelo de implementação. Em geral, os pacotes que estão sendo combinados são provenientes de diferentes organizações de desenvolvimento. O teste de integração detecta imperfeições ou erros nas especificações da interface do pacote.

Em alguns casos, a suposição dos desenvolvedores é que os outros grupos como os testadores independentes executarão os testes de integração. Essa situação apresenta riscos para o projeto de software e finalmente para a qualidade do software porque:

• as áreas de integração são um ponto comum do defeito de software.
• os testes de integração executados por testadores independentes normalmente utilizam técnicas de caixa preta e estão normalmente lidando com componentes de software maiores.

Uma abordagem melhor é considerar no teste de integração a responsabilidade do desenvolvedor e dos testadores independentes, mas fazer da estratégia de cada equipe um esforço de teste não sobrepõe significativamente. A natureza exata dessa sobreposição tem como base as necessidades do projeto individual. Recomendamos que você estimule um ambiente em que os desenvolvedores e os testadores do sistema independente compartilhem uma única visão de qualidade. Consulte Conceito: Teste de Desenvolvedor para obter informações adicionais.

Teste do Sistema

Tradicionalmente, o teste do sistema é feito quando o software está funcionando como um todo. Um ciclo de vida iterativo permite que o teste do sistema ocorra muito mais cedo, assim que os subconjuntos bem formados do comportamento de caso de uso são implementados. Normalmente o destino é os elementos de funcionamento de ponta a ponta do sistema.

Teste de Aceitação

O teste de aceitação do Usuário é a ação de teste final realizada antes da implementação do software. A meta do teste de aceitação é verificar se o software está pronto e se pode ser utilizado pelos usuários para desempenhar essas funções e tarefas para as quais o software foi construído. Consulte Conceito: Teste de Aceitação para obter informações adicionais.

Há outras noções de teste de aceitação que são geralmente caracterizadas por uma entrega de um grupo ou de uma equipe para outra. Por exemplo, um teste de aceitação de construção é o teste feito para aceitar o encaminhamento de uma nova construção de software a partir do desenvolvimento para o teste independente.

Um comentário sobre a seqüência e a cronometragem dos níveis de teste

Tradicionalmente, pensam que o teste de unidade é implementado logo na iteração como o primeiro estágio de teste: todas as unidades requeridas para serem transmitidas antes dos estágios subseqüentes são conduzidas. No entanto, em um processo de desenvolvimento iterativo, essa abordagem é uma regra geral, inapropriada. Uma abordagem melhor é identificar os testes de unidade, de integração e do sistema que oferecem mais potencial para a localização de erros e, em seguida, implementá-los e executá-los com base em uma combinação do maior risco e do ambiente de suporte.