Papéis e Atividades > Conjunto de Papéis do Desenvolvedor > 
Designer de Teste > 
Identificar os Mecanismos de Testabilidade
Atividade:
| ||||||||||||||||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Normalmente, esta atividade é executada várias vezes em cada iteração. | |
| Papel: Designer de Teste | |
| Mentores de Ferramentas: |
|
| Informações Adicionais: |
|
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Compreender a arquitetura do software e seu relacionamento com os ambientes-alvo de implantação. |
Para executar esta atividade dentro do contexto apropriado, é importante ter uma compreensão adequada do software que está sendo desenvolvido, de sua arquitetura e dos principais mecanismos e características que ele suportará. Examine a documentação disponível referente à arquitetura do software para obter uma noção inicial e a suplemente com entrevistas e debates com o arquiteto de software, se necessário. Considere o impacto que cada ambiente-alvo de implantação pode ter nessas informações e observe novos fatores que possam ser relevantes para o esforço de teste.
| Finalidade: | Identificar os possíveis mecanismos de teste necessários para a abordagem de teste. |
Com seu conhecimento da arquitetura do software e de seus ambientes-alvo, examine as informações fornecidas na abordagem de teste. Considere os principais aspectos técnicos da abordagem e crie uma lista de sugestões de mecanismos que serão necessários para suportá-la. Eis uma lista parcial dos mecanismos comuns a serem considerados como sugestões: persistência, simultaneidade, distribuição, comunicação, segurança, gerenciamento de transações, recuperação, tratamento de detecção de erros e relatório, e controle de processo e sincronização.
Observe que esses mecanismos normalmente se aplicam aos esforços de teste manual e automatizado, embora um mecanismo específico possa ter mais ou menos relevância para o teste manual ou automatizado. Observe também que embora o mesmo mecanismo seja necessário para ambos os esforços de teste, as características da solução implementada geralmente serão diferentes.
| Finalidade: | Identificar as oportunidades para reutilizar as implementações existentes para as sugestões de mecanismo e identificar as implementações adicionais que precisarão ser desenvolvidas. |
Examine as ferramentas de teste disponíveis e as implementações de teste existentes e crie um inventário dos mecanismos que têm uma ou mais soluções. Embora esse passo seja mais obviamente relevante em termos do esforço de teste automatizado, há algumas considerações equivalentes para o esforço de teste manual.
Subtópicos:
Comece compilando uma lista das ferramentas disponíveis ou que você planeja adquirir. Lembre-se de que as ferramentas de automatização assumem várias formas e sua lista normalmente incluirá mais do que as ferramentas de implementação e execução de testes automatizados. Para cada ferramenta, examine os mecanismos fornecidos por ela. Por exemplo, a ferramenta de criação de scripts que você planeja usar fornece seu próprio mecanismo de persistência de dados e, se for o caso, é apropriada para suas necessidades ou será necessário suplementá-la? Outras perguntas podem incluir: a ferramenta de execução permite a execução simultânea de scripts de teste em várias máquinas cliente do host? A ferramenta de execução permite a distribuição de scripts de uma máquina mestre central para várias máquinas cliente do host?
Quando implementações de automatização de teste estiverem disponíveis, haverá outros mecanismos para inventário. Alguns aspectos dessas implementações estenderão ou suplementarão os mecanismos básicos fornecidos pelas ferramentas para torná-los mais úteis. Outros aspectos oferecerão implementações para mecanismos adicionais não fornecidos na ferramenta básica.
Em um nível básico, isso envolverá a revisão da guia de teste existente para a implementação e a execução do teste. Procure soluções de processo existentes para questões, como simultaneidade—como os testadores podem compartilhar conjuntos de dados, principalmente estruturas de dados existentes, sem afetar um ao outro de forma adversa; e distribuição—se a equipe de teste está distribuída, quais soluções estão disponíveis para a coordenação dos esforços de teste separados.
| Finalidade: | Comunicar as decisões tomadas sobre os mecanismos de teste necessários. |
Agora que você decidiu sobre os mecanismos de teste necessários, precisa comunicar sua escolha à equipe de teste e a outros envolvidos no esforço de teste. Recomenda-se documentar as decisões sobre os mecanismos de teste necessários para a automatização como parte da documentação Arquitetura de Automatização de Teste, e aquelas relacionadas ao teste manual como parte do Guia de Teste.
Como alternativa à documentação formal, você pode simplesmente registrar essas informações como um conjunto de observações de arquitetura e processo, acompanhadas de alguns diagramas explanatórios, possivelmente mantidos em um quadro branco. Durante a implementação e execução do teste, testadores individuais utilizarão essas informações para tomar decisões táticas.
Quando você identificar o possível requisito de interfaces de teste especiais que precisarão ser criadas no software que está sendo desenvolvido, considere registrar esse requisito criando um ou mais resumos de Especificações de Interface de Teste; esse resumo deve fornecer um nome, uma breve descrição e enumerar os principais requisitos ou características de interface de teste. Evite perder muito tempo nesses resumos; a lista de requisitos e características será detalhada posteriormente em Atividade: Definir Elementos de Testabilidade.
| 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 |
