|
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 Teste 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.
|
Produto de Trabalho
|
Finalidade
|
Adaptação (Opcional, Recomendada)
|
|
Resumo de Avaliação de Teste
|
Resume os Resultados do Teste para uso principalmente pela equipe de gerenciamento e outros
investidores externos à equipe de teste.
|
Recomendada para a maioria dos projetos.
Onde a cultura do projeto é relativamente informativa, pode ser apropriado simplesmente registrar os
resultados do teste em vez de criar resumos formais de avaliação. Em outros casos, os Resumos de
Avaliação de Teste podem ser incluídos como uma seção em outros produtos de trabalho de Avaliação, como
Avaliação de Iteração ou Registro de Revisão.
|
|
Resultados do Teste
|
Este produto de trabalho é o resultado analisado obtido dos dados brutos em um ou mais Registros do
Teste.
|
Recomendada. A maioria das equipes de teste mantém alguma forma de registro razoavelmente detalhado dos
resultados de testes. Em geral, os resultados de testes manuais são registrados diretamente aqui e
combinados aos Logs de Testes depurados de testes automatizados.
Em alguns casos, as equipes de teste criarão o Sumário de Avaliação de Testes diretamente dos Logs de
Testes.
|
|
Registro do Teste
|
A saída de dados brutos durante a execução do teste, geralmente produzida por testes automatizados.
|
Opcional.
Muitos projetos que realizam testes automatizados terão alguma forma de Log de Teste. A diferença
entre os projetos está no fato de os Logs de Teste serem mantidos ou descartados após a obtenção
dos Resultados do Teste.
Você poderá reter os Logs de Teste se precisar cumprir determinados requisitos de auditoria, se
desejar executar análise sobre como os dados brutos da saída de teste são alterados ao longo do
tempo ou se estiver inseguro no princípio de toda a análise que possa ser necessário apresentar.
|
|
Conjunto de Teste
|
Utilizado para agrupar testes relacionados individuais (Scripts de Teste) juntos em subconjuntos
significativos.
|
Recomendada para a maioria dos projetos.
Também necessário para definir quaisquer seqüências de execução do Script de Teste que sejam
necessárias para que os testes funcionem corretamente.
|
|
Lista de Idéias de Teste
|
É uma lista enumerada de idéias, quase sempre parcialmente formadas, que devem ser consideradas como
testes cuja realização pode ser útil.
|
Recomendada para a maioria dos projetos.
Em alguns casos, essas listas serão definidas informalmente e descartadas depois que os Scripts de
Teste ou os Casos de Teste tiverem sido definidos a partir delas.
|
|
Estratégia de Teste
|
Define o plano estratégico de como o esforço de teste será conduzido em relação a um ou mais aspectos
do sistema de destino.
|
Recomendada para a maioria dos projetos.
Uma única Estratégia de Teste por projeto ou por fase em um projeto é recomendada na maioria dos
casos. Opcionalmente, você poderia reutilizar as estratégias existentes onde apropriado ou poderia
subdividir ainda mais as Estratégias de Teste com base no tipo de teste que estiver sendo conduzido.
|
|
Plano de Teste
|
Define metas de testes mais granulares, bem como objetivos, motivações, abordagem, recursos,
planejamento e produtos de trabalho que controlam uma iteração.
|
Recomendada para a maioria dos projetos.
Recomenda-se um Plano de Teste separado por iteração é para definir a estratégia de teste granular
específica. Opcionalmente, você pode incluir o Plano de Teste como uma seção no Plano de Iteração.
|
|
Plano de Teste
|
Define metas de testes de alto nível, bem como objetivos, abordagem, recursos, planejamento e produtos
de trabalho que controlam uma fase ou o ciclo de vida inteiro.
|
Opcional. Útil para a maioria dos projetos.
Um Plano de Teste Master define a estratégia de alto nível para o esforço de teste sobre grandes
partes do ciclo de vida de desenvolvimento do software. Opcionalmente, você pode incluir o Plano de
Teste como uma seção no Plano de Desenvolvimento de Software.
Considere se manterá um Plano de Teste "Master" além dos Planos de Teste de "Iteração". O Plano de
Teste Master abrange principalmente informações de logística e de processo que normalmente estão
relacionadas ao ciclo de vida completo do projeto e provavelmente não será alterado entre as iterações.
|
|
Script de Teste, Dados de Teste
|
Os Scripts de Teste e os Dados de Teste são a realização ou a implementação do teste, sendo que o
primeiro incorpora os aspectos procedurais, e o segundo, as características de definição.
|
Recomendada para a maioria dos projetos.
Os projetos diferem quanto ao grau de formalidade com que estes produtos de trabalho são tratados. Em
alguns casos, eles são informais e transitórios e a equipe de teste é julgada com base em outros
critérios. Em outros casos, especialmente com testes automatizados, os Scripts de Teste e os Dados de
Teste associados (ou algum subconjunto deles) são considerados os principais produtos liberados do
esforço de teste.
|
|
Caso de Teste
|
Define um conjunto específico de inputs de teste, condições de execução e resultados esperados.
Documentar casos de teste permite que eles sejam revisados quanto à integralidade e exatidão e
considerados antes do esforço de implementação ser planejado e realizado.
É útil principalmente quando o input, as condições de execução e os resultados esperados são
particularmente complexos.
|
É recomendável que na maioria dos projetos, onde as condições necessárias para conduzir um teste
específico são complexas ou extensas, você defina Casos de Teste. Também será necessário documentar
Casos de Teste onde eles forem um produto liberado contratualmente obrigatório.
Na maior parte dos outros casos, é recomendável manter a Lista de Idéias de Teste e os Scripts de
Teste Implementados em vez dos Casos de Teste de texto detalhado.
Alguns projetos simplesmente descreverão os Casos de Teste em um alto nível e adiarão os detalhes
para os Scripts de Teste. Um outro estilo normalmente utilizado é documentar as informações do Caso
de Teste como comentários nos Scripts de Teste.
|
|
Modelo de Análise de Carga de Trabalho
|
Um tipo especializado de Caso de Teste. Utilizado para definir uma carga de trabalho representativa
que permita avaliar os riscos de qualidade associados ao sistema em operação sob a carga.
|
Recomendada para a maioria dos sistemas, especialmente aqueles cujo desempenho sob carga precise
ser avaliado ou que apresentem outros riscos de qualidade significativos associados à operação do
sistema sob carga.
Em geral, não é necessária para sistemas que serão implementados em um sistema de destino
independente.
|
|
Classes de Possibilidade de Teste no Modelo de
Design
Elementos de Possibilidade de Teste no Modelo de
Implementação
|
Se o projeto precisar desenvolver comportamento especializado adicional significativo para ajustar
e suportar testes, estas questões serão representadas pela inclusão de Classes de Possibilidade de
Teste no Modelo de Design e dos Elementos de Possibilidade de Teste no Modelo de Implementação.
|
Onde Necessária.
Stubs são uma categoria comum de Classes de Teste e Componente de
Teste.
|
|
Arquitetura de Automação de Teste
|
Fornece uma visão geral da arquitetura do sistema de automatização de testes, usando várias visões
de arquitetura distintas para descrever diferentes aspectos do sistema.
|
Opcional.
Recomendada em projetos em que a arquitetura de teste é relativamente complexa, quando um número
grande de pessoas da equipe estará colaborando com a construção de testes automatizados ou quando o
sistema de automatização de testes será mantido durante um longo período de tempo.
Em alguns casos, isso pode ser apenas um diagrama de quadro branco que esteja registrado
centralmente para que as partes interessas possam consultá-lo.
|
|
Especificação da Interface de Teste
|
Define um conjunto de comportamentos requeridos por um classificador (especialmente, uma Classe,
Subsistema ou Componente) para as finalidades do teste (testabilidade). Os tipos comuns incluem
acesso ao teste, comportamento de stubs, log de diagnóstico e previsões de teste.
|
Opcional.
Em muitos projetos, há acessibilidade suficiente para testes nas operações visíveis em classes,
interfaces do usuário, etc.
Algumas razões comuns para criar Especificações da Interface de Teste incluem extensões de
interface do usuário para permitir que ferramentas de teste da interface gráfica do usuário
interajam com as rotinas de log de mensagens de diagnóstico e de ferramentas, especialmente para
processos em lote.
|
Esta seção fornece algumas diretrizes que ajudarão você a decidir como revisar os produtos de trabalho de teste. Para
orientação geral, consulte Diretriz: Níveis
de Revisão.
Defeitos
O tratamento de revisões de Defeitos é muito dependente do contexto, no entanto, elas são geralmente tratadas como
Informal, Formal - Interna ou Formal - Externa. Este processo de revisão é geralmente aplicado ou
pelo menos assistido pelo gerenciamento de workflow em um sistema de trilha de defeitos. Como um comentário geral, o
nível de formalidade de revisão geralmente está relacionado à gravidade ou ao impacto observado do defeito, no entanto,
fatores como a cultura do projeto ou o nível de formalidade geralmente têm um efeito sobre a opção de manipulação da
revisão.
Em alguns casos, pode ser necessário considerar a separação da manipulação de defeitos, também conhecidos como sintomas
ou avarias, das falhas; a origem real do erro. Em projetos pequenos, normalmente é possível gerenciar monitorando
apenas os defeitos e manipular as falhas de forma implícita. No entanto, à medida que a complexidade do sistema
aumenta, pode ser vantajoso separar o gerenciamento de defeitos das falhas. Por exemplo, vários defeitos podem ser
causados pelo mesmo erro. Assim, se um erro é corrigido, é necessário localizar os defeitos relatados e informar os
usuários que os enviaram. Isso só será possível se os defeitos e os erros puderem ser identificados separadamente.
Plano de Teste e Estratégia de Teste
Todo projeto cujos testes sejam não-triviais necessitará de alguma forma de Plano de Teste ou Estratégia. Geralmente,
você precisará de um Plano de Teste para cada iteração e alguma forma de controlar a Estratégia de Teste.
Opcionalmente, você pode criar e manter um Plano de Teste Master. Em muitos casos, esses produtos de trabalho são
revisados como Informal; ou seja, eles são revisados, mas não aprovados formalmente. Quando a visibilidade dos
testes tem importância para os envolvidos externos à equipe de teste, deve-se tratar isso como Formal - Interno
ou Formal - Externo.
Scripts de Teste
Os Scripts de Teste são geralmente tratados como Informal; ou seja, eles são aprovados por alguém na equipe de
teste. Se os Scripts de Teste forem utilizados por vários testadores, e compartilhados ou reutilizados por vários
testes diferentes, eles deverão ser tratados como Formal - Interno.
Casos de Teste
Os Casos de Teste são criados pela equipe de teste e, dependendo do texto, geralmente são revisados utilizando um
processo Informal ou simplesmente não são revisados. Onde apropriado, os Casos de Teste podem ser aprovados por
outros membros da equipe, neste caso podem ser tratados como Formal - Interno, ou por envolvidos externos, neste
caso seriam Formal - Externo.
Como uma heurística geral, recomendamos que você planeje revisar formalmente apenas os casos de teste em que isso se
faz necessário, que geralmente serão limitados a um pequeno subconjunto representando os casos de teste mais
significativos. Por exemplo, se um cliente desejar validar um produto antes de sua liberação, algum subconjunto dos
Casos de Teste poderá ser selecionado como a base para essa validação. Esses Casos de Teste devem ser tratados como
Formal - Externo.
Testar Produtos de Trabalho em Design e Implementação
As Classes de Testabilidade estão localizadas no Modelo de Design e os Elementos de Testabilidade no Modelo de
Implementação. Também há dois outros produtos de trabalho relacionados (embora não específicos do teste): Pacotes no
Modelo de Design e Subsistemas no Modelo de Implementação.
Esses são produtos de trabalho de design e implementação, no entanto, eles são criados com o propósito de suportar a
funcionalidade de testes no software. Em geral, são guardados com os produtos de trabalho de design e implementação.
Lembre-se de nomeá-los ou rotulá-los de forma a distingui-los claramente do design e da implementação do sistema
central. Revise esses produtos de trabalho seguindo os procedimentos de revisão para os produtos de trabalho Design e
Implementação.
À medida que você entrar em cada iteração, tente definir de modo claro e direto como o esforço de teste será avaliado
como suficiente e a base de medida dessa avaliação. Faça essa análise com a pessoa ou grupo responsável por tomar a
decisão de aprovação.
Veja a seguir exemplos de como lidar com a aprovação de iteração:
-
A equipe de gerenciamento de projeto aprova a iteração e avalia o esforço de teste, revisando os resumos de
avaliação de teste.
-
O cliente aprova a iteração, revisando os resumos de avaliação de teste.
-
O cliente aprova a iteração com base nos resultados de uma demonstração que testa um subconjunto específico de
todos os testes. Esse subconjunto de testes deverá ser definido e combinado com antecedência, preferivelmente logo
no início da iteração. Esses testes são tratados como Formal - Externo e são geralmente chamados de
testes de aceitação.
-
O cliente aprova a qualidade do sistema realizando seus próprios testes independentes. Novamente, a natureza desses
testes deve ser claramente definida e combinada com antecedência, preferivelmente no início da iteração. Esses
testes são tratados como Formal - Externo e são geralmente chamados de testes de aceitação.
Essa decisão é importante, você não consegue atingir uma meta se não sabe qual ela é.
|
