Diretrizes:
|
| Artefato | Finalidade |
Adaptação (Opcional, Recomendada) |
| Sumário de Avaliação de Testes | Resume os Resultados do Teste para uso principalmente pela equipe de gerenciamento e outros envolvidos externos à equipe de teste. | Recomendada para a maioria dos projetos. |
| Resultados do Teste | Este artefato é o resultado analisado obtido dos dados brutos em um ou mais Logs de Testes. | 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. |
| Plano de Teste [de Iteração] | Define as metas de testes, seus objetivos, abordagem, recursos e produtos liberados referentes a uma iteração. |
Recomendada para a maioria dos projetos. É recomendável um Plano de Teste separado por iteração, a menos que o teste seja trivial. Nesse caso, inclua o Plano de Teste como uma seção do Plano de Iteração. Decida se manterá ou não um Plano de Teste "Mestre" além dos Planos de Teste de "de Iteração". Em geral, o Plano de Teste Mestre abrange informações de logística e de processos relacionadas ao ciclo de vida completo do projeto e provavelmente não será alterado. |
| 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. |
| 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 artefatos são considerados. Em alguns casos, 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 o principal produto liberado do esforço de teste. |
| Conjunto de Testes | Usado para agrupar Scripts de Teste relacionados e para definir seqüências de execução de Scripts de Teste necessárias para o funcionamento correto dos testes. | Recomendada para a maioria dos projetos. |
| Modelo de Análise de Carga de Trabalho | Usado para definir uma carga de trabalho representativa que permita avaliar os riscos associados ao desempenho do sistema sob carga. |
Recomendada para a maioria dos sistemas, especialmente aqueles cujo desempenho sob carga precise ser avaliado ou que apresentem um risco considerável de problemas de desempenho. Em geral, não é necessária para sistemas que serão implantados em um sistema de destino independente. |
| 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 verificar se estão completos e corretos e analisá-los antes que o esforço de implementação seja 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 pelo menos os Casos de Teste complexos sejam definidos na maioria dos projetos. Dependendo das obrigações contratuais, talvez seja necessário definir outros. Na maior parte dos outros casos, é recomendável usar a Lista de Idéias de Teste em vez dos Casos de Teste. Alguns projetos descreverão os Casos de Teste de forma abrangente e deixarão os detalhes para os Scripts de Teste. Uma técnica de adaptação eficaz é documentar os Casos de Teste como comentários nos Scripts de Teste. |
|
Classes de Teste no Modelo de Design Componentes de Teste no Modelo de Implementação |
Os Modelos de Design e de Implementação incluem Classes e Componentes de Teste caso o projeto precise desenvolver outros comportamentos especializados importantes para acomodar e suportar testes. |
Stubs são uma categoria comum de Classes e Componentes de Teste. |
| Log de Testes | A saída de dados brutos durante a execução do teste, geralmente a partir de testes automatizados. |
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. É melhor manter Logs de Teste caso você precise satisfazer determinados requisitos de auditoria ou se desejar analisar como os dados brutos são alterados no decorrer do tempo. |
| Arquitetura para Automatização de Testes | 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 para projetos cuja arquitetura de testes seja relativamente complexa. Em muitos casos, este artefato pode ser apenas um diagrama em um quadro branco, colocado em um local central para que as partes interessadas possam consultá-lo. |
| Especificação da Interface de Teste | Define um conjunto de comportamentos exigidos por um classificador (principalmente uma Classe, um Subsistema ou um Componente) para fins de acesso a testes (testabilidade). |
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. |
Para adaptar cada artefato, execute os passos descritos em Atividade: Elaborar Caso de Desenvolvimento, no tópico "Adaptar Artefatos por Disciplina".
Esta seção fornece algumas diretrizes que ajudarão você a decidir como revisar os artefatos de teste. Para obter mais detalhes, consulte Diretrizes: Níveis de Revisão.
Os Casos de Teste são criados pela equipe de teste e geralmente são considerados como Informal, pois são aprovados por alguém dessa equipe.
Quando for útil, os Casos de Teste podem ser aprovados por outros membros de equipe e devem ser considerados como Formal - Interno.
Se um cliente desejar validar um produto antes do lançamento, é possível selecionar um subconjunto de Casos de Teste como base para a validação. Esses Casos de Teste devem ser considerados como Formal - Externo.
Em geral, os Scripts de Teste são considerados como Informal, ou seja, são aprovados por alguém da equipe de teste.
Se os Scripts de Teste forem usados por muitos testadores e compartilhados ou reutilizados em muitos testes diferentes, deverão ser considerados como Formal - Interno.
É possível encontrar Classes de Teste no Modelo de Design e Componentes de Teste no Modelo de Implementação. Existem também dois outros artefatos relacionados, embora não específicos de teste: Pacotes no Modelo de Design e Subsistemas no Modelo de Implementação.
Esses artefatos são semelhantes aos artefatos de design e implementação. No entanto, são criados para fins de teste. Em geral, são guardados com os artefatos 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.
Geralmente, os defeitos são considerados como Informal e são tratados em um sistema de controle de defeitos. Em um projeto pequeno, é possível gerenciá-los como uma lista simples (por exemplo, usando a planilha de sua preferência). Esse gerenciamento é possível apenas em sistemas de pequeno porte. Quando o número de envolvidos e a quantidade de defeitos forem maiores, será necessário passar a usar um sistema de controle de defeitos mais flexível.
Outra decisão a ser tomada refere-se à necessidade ou não de fazer a distinção entre tratamento de defeitos - também conhecidos como sintomas ou falhas - e de erros. Em projetos pequenos, é possível controlar apenas os defeitos e tratar os erros de forma implícita. No entanto, à medida que o sistema cresce, costuma ser necessário fazer a distinção entre o gerenciamento de defeitos e de erros. 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.
Todo projeto cujos testes sejam não-triviais necessita de um Plano de Teste para cada Iteração. Como opção, você pode manter um Plano de Teste Mestre. Em muitos casos, ele é considerado como Informal, ou seja, não é revisado nem aprovado. Em situações nas quais o teste tenha uma visibilidade importante para os envolvidos externos, ele pode ser considerado como Formal - Interno ou até mesmo como Formal - Externo.
Você deve decidir a quem caberá a responsabilidade de verificar se uma iteração satisfez os critérios correspondentes. À medida que incluir cada iteração, esforce-se para definir com clareza e antecedência como o esforço de teste deverá demonstrar isso e como será medido. O indivíduo ou grupo decidirá se a iteração satisfez os critérios correspondentes, se o sistema atende aos critérios de qualidade desejados e se os Resultados do Teste são suficientes e satisfatórios para fundamentar as conclusões.
Veja a seguir exemplos de como lidar com a aprovação de iteração:
Essa decisão é importante - você não consegue atingir uma meta se não sabe qual ela é.
|
Rational Unified Process
|
