Papéis e Atividades > Conjunto de Papéis do Desenvolvedor > 
Designer de Teste > 
Estruturar a Implementação de Testes
Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Entender como o teste será avaliado e as implicações no modo de implementação dos Conjuntos de Testes específicos para avaliar os Itens de Teste-Alvo. |
Começando com uma revisão do Plano de Teste para determinar as necessidades de avaliação, considere como a avaliação da extensão do teste e da qualidade do software pode ser determinada usando a Abordagem de Teste declarada. Considere qualquer necessidade especial que precise ser tratada relacionada a Itens de Teste-Alvo específicos.
| Finalidade: | Entender os elementos de testabilidade disponíveis, os mecanismos suportados por eles e os benefícios oferecidos. |
Reveja os mecanismos úteis para permitir o teste neste ambiente e identifique os elementos de testabilidade específicos que implementam esses mecanismos. Isso inclui a revisão de recursos, como qualquer biblioteca de funções que tenha sido desenvolvida pela equipe de teste e os stubs ou harnesses implementados pela equipe de desenvolvimento.
A testabilidade é atingida através de uma combinação de desenvolvimento de um software testável e definição de uma abordagem que suporte os testes de forma apropriada. Portanto, a testabilidade é um aspecto importante do desenvolvimento de componentes para as equipes de teste, assim como é uma parte importante do esforço de desenvolvimento de software. A obtenção da Testabilidade (a capacidade de testar efetivamente o produto de software) tipicamente envolverá a combinação de:
O Conjunto de Testes atual possui o requisito a ser distribuído? Nesse caso, utilize os elementos de testabilidade que suportam distribuição. Esses elementos serão tipicamente características de ferramentas de suporte de automatização específicas que distribuirão o Conjunto de Testes, executarão o conjunto remotamente e retornarão o Log de Teste e outras saídas para a determinação de resultados centralizados.
O Conjunto de Testes atual possui o requisito para ser executado simultaneamente com outros Conjuntos de Testes? Nesse caso, utilize os elementos de testabilidade que suportam a simultaneidade. Esses elementos serão tipicamente uma combinação de ferramentas de suporte específicas e funções de utilitário que permitirão que vários Conjuntos de Testes sejam executados simultaneamente em diferentes máquinas físicas. A simultaneidade exige design e gerenciamento de Dados de Teste cuidadosos para assegurar que nenhum efeito colateral inesperado ou não planejado ocorra, como dois testes simultâneos atualizando o mesmo registro de dados.
| Finalidade: | Descrever os Conjuntos de Testes a serem implementados. |
Enumerar um ou mais Conjuntos de Testes que (quando executados) fornecerão um resultado completo e significativo de valor para a equipe de teste, permitindo relatórios subseqüentes para os envolvidos. Tente equilibrar o nível de detalhes, de modo que sejam suficientes para fornecer informações específicas para a equipe de projeto, mas não tão detalhados a ponto de não poderem ser gerenciados.
Onde já existem Scripts de Teste, você provavelmente poderá montar sozinho o Conjunto de Testes e suas partes constituintes e, em seguida, passar o trabalho de estabilização do Conjunto de Testes para ser concluído por um Implementador de Conjunto de Testes.
Para Conjuntos de Testes que requerem a criação de novos Scripts de Testes, forneça também alguma indicação dos Scripts de Teste — ou de outros Conjuntos de Testes — que acredita que serão referidos por esse Conjunto de Testes. Se for fácil enumerá-los, faça isso. Caso contrário, você poderá fornecer apenas uma breve descrição que descreva a cobertura de conteúdo esperada do principal Conjunto de Testes e deixar a cargo do implementador do Conjunto de Testes a tomada de decisões táticas sobre exatamente quais Scripts de Teste serão incluídos.
| Finalidade: | Refinar a estrutura do Conjunto de Testes para trabalhar com as atribuições de responsabilidade da equipe. |
Talvez seja necessário subdividir ainda mais ou reestruturar os Conjuntos de Testes identificados para acomodar a Estrutura de Divisão do Trabalho (WBS) na qual a equipe está trabalhando. Isso ajudará a reduzir o risco de ocorrência de possíveis conflitos de acesso durante o desenvolvimento do Conjunto de Testes. Algumas vezes, as ferramentas de automatização de testes podem impor restrições sobre o modo de trabalho dos indivíduos com componentes de automatização, portanto, reestruture os Conjuntos de Testes para acomodar isso conforme necessário
| Finalidade: | Identificar os Dados de Teste e o Estado do Sistema que precisam ser compartilhados ou passados entre os Scripts de Teste. |
Na maioria dos casos, os Conjuntos de Testes podem simplesmente chamar os Scripts de Teste em uma ordem específica. Isso será suficiente em muitos casos para assegurar que o estado correto do sistema seja passado através de um Script de Teste para o próximo.
No entanto, em certas classes de sistema, os dados dinâmicos de tempo de execução são gerados pelo sistema ou derivados como resultado das transações que ocorrem dentro dele. Por exemplo, em um sistema de entrada e despacho de pedidos, em cada entrada de um pedido, um número de pedido exclusivo é gerado pelo sistema. Para permitir que um Script de Teste automatizado despache um pedido, um Script de Teste de entrada de ordem precedente precisa capturar o número exclusivo gerado pelo sistema e passá-lo para o Script de Teste de despacho do pedido.
Em casos como esse, você precisará considerar o mecanismo de comunicação de Script entre Testes que será apropriado para usar. Alternativas típicas incluem a passagem de parâmetros, leitura e gravação de valores em um arquivo de disco e utilização de variáveis globais de tempo de execução. Cada estratégia apresenta aspectos positivos e negativos que a torna mais ou menos apropriada em cada situação específica.
| Finalidade: | Identificar e registrar as dependências de tempo de execução entre os elementos do Conjunto de Testes. |
Isso está principalmente associado ao seqüenciamento dos Scripts de Teste e possivelmente aos Conjuntos de Testes para processamento em tempo de execução. Testes executados sem o estabelecimento das dependências corretas correm o risco de falharem ou de relatarem dados anômalos.
| Finalidade: | Utilizar um diagrama para documentar e explicar a realização da implementação de teste. |
Se tiver acesso a uma ferramenta de desenho ou de modelagem UML, pode ser que você deseje criar um diagrama do Modelo de Implementação de Teste que descreva os elementos-chave do software de teste automatizado. Você também poderá diagramar alguns aspectos-chave da Arquitetura para Automatização de Testes de forma semelhante.
Outra abordagem possível é desenhar esses diagramas em um quadro branco facilmente visível para a equipe de teste.
| Finalidade: | Fazer ajustes necessários para manter a integridade da implementação do teste. |
À medida que o projeto for avançando, é provável que ocorram mudanças nos Conjuntos de Testes: novos Scripts de Teste serão acrescentados e antigos Scripts de Teste serão atualizados, reordenados ou excluídos. Essas mudanças são uma parte natural da manutenção do Conjunto de Testes e você precisa aceitá-las em vez de evitá-las.
Se os Conjuntos de Testes não forem mantidos ativamente, eles serão interrompidos rapidamente e cairão em desuso. Abandonado por alguns builds, um Conjunto de Testes poderá exigir um esforço extenso para ressuscitar, sendo mais fácil, talvez, abandoná-lo e criar um novo a partir do zero. Consulte a seção Mais Informações: na tabela de cabeçalhos desta página para obter mais diretrizes sobre como manter Conjuntos de Testes automatizados.
| Finalidade: | Permitir a análise do impacto e a geração de um relatório de avaliação dos itens rastreados. |
Usando os requisitos de Rastreabilidade descritos no Plano de Teste, atualize os relacionamentos de rastreabilidade conforme necessário.
| Finalidade: | Verificar se a atividade foi concluída corretamente e se os artefatos resultantes são aceitáveis. |
Agora que você concluiu o trabalho, convém verificar se ele foi proveitoso e garantir que você não apenas consumiu uma grande quantidade de papel. Avalie se a qualidade de seu trabalho é apropriada e se ele está completo o suficiente para ser útil aos membros da equipe que o utilizarão depois como entrada em seu próprio trabalho. Sempre que possível, use as listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência estão satisfatórias.
Faça com que as pessoas que executam as atividades subordinadas e que dependem de seu trabalho como input participem revisando o seu trabalho provisório. Faça isso enquanto ainda dispõe de tempo para executar algum tipo de ação em relação às questões levantadas por elas. Avalie também seu trabalho, comparando-o com os principais artefatos informados para verificar se eles foram representados de forma precisa e satisfatória. Talvez seja útil solicitar ao autor do artefato informado para rever seu trabalho baseado nisso.
Lembre-se de que o RUP é um processo iterativo e de que, em muitos casos, os artefatos evoluem com o tempo. Portanto, normalmente não é necessário — e, em geral, é improdutivo — formar um artefato completo que será usado apenas parcialmente ou que nem será usado no trabalho imediatamente subseqüente. Isso porque há uma grande probabilidade de a situação que envolve o artefato ser alterada — e as suposições feitas no momento de criação do artefato acabarem sendo incorretas — antes de o artefato ser usado, resultando em desperdício de esforço e em um dispendioso retrabalho. Evite também a armadilha de ficar perdendo tempo com inúmeros ciclos de apresentação em detrimento do valor do conteúdo. Em ambientes de projeto em que apresentações têm grande importância e são considerados produtos liberados, utilize um recurso administrativo para tarefas de apresentação.
|
Rational Unified Process |
