|
Para cada Item de Objetivo de Teste Requerido, Identificar Relacionamentos com Mecanismos de Teste
|
Finalidade:
|
Compreender um suporte de mecanismo de teste necessário aos itens de teste de destino.
|
Para cada item de teste de destino, revise a lista de mecanismos de teste e identifique aqueles que poderiam fornecer
suporte. Analisar como os mecanismos de teste selecionados estão envolvidos para fornecer uma solução de teste completo
e como eles podem ser adaptados para um ajuste melhor. Se nenhuma sugestão for localizada ou o esforço de adaptação for
significativo, define novos mecanismos de teste e tente encontrar um equilíbrio entre especificação e reutilização.
|
Identificar Elementos e Eventos Dinâmicos do Sistema
|
Finalidade:
|
Compreender a os aspectos de dinâmica e de tempo de execução do sistema.
|
Usando os requisitos de software e as informações de design disponíveis, identifique os eventos e elementos dinâmicos
do sistema. Usando os modelos de casos de uso, design, implementação e implementação, é possível identificar itens
relevantes, como classes de controle, processos, threads e eventos. Os locais para começar sua pesquisa incluem classes
estereotipadas como <<controle>>, realizações de casos de uso e elementos descritos na visualização
arquitetural do processo ou no modelo de implementação estereotipado como <<processo>> ou
<<encadeamento>>.
Em relação às restrições impostas pelo ambiente de teste, defina os requisitos físicos
|
Identificar Limites e Interfaces do Sistema
|
Finalidade:
|
Entender as responsabilidades do sistema como provedor de serviços e as dependências do sistema como
cliente.
|
Outro grupo útil de elementos a serem examinados são as Interfaces do sistema, principalmente as relacionadas aos
atores fora das fronteiras do sistema. Utilizando os Modelos de Design e Implementação, procure os elementos definidos
com o estereótipo <<interface>>. Examine também os modelos em busca da existência de classes estereotipadas
como <<limite>>.
Como testador, convém que você explore além dessas fronteiras de sistema para entender as expectativas dos sistemas
relacionados, tanto do cliente quanto dos provedores de serviços. Isso o ajudará a compreender melhor a necessidade em
termos de validação das interfaces e em termos da infra-estrutura de teste necessária para testar e possivelmente
simular essas interfaces.
|
Identificar Elementos da Infra-estrutura
|
Finalidade:
|
Identificar os elementos essenciais do esforço de teste que permitirão a execução do teste necessário.
|
Para que um esforço de teste iterativo seja bem-sucedido, é importante identificar e manter uma infra-estrutura
apropriada. Sem uma infra-estrutura que permita sua manutenção, o esforço de teste poderá perder rapidamente sua
manutenibilidade e usabilidade. Embora seja obviamente mais relevante para o esforço de teste automatizado, a
infra-estrutura de teste também é um aspecto importante para o esforço de teste manual.
Considerando os eventos e elementos dinâmicos do sistema, quais dependências eles gerarão na implementação de testes
individuais? Procure oportunidades que permitam desacoplar as dependências entre testes individuais e gerencie-as
através de pontos comuns de controle que forneçam uma camada de procedimento indireto. As áreas comuns a serem
exploradas quanto às dependências incluem a navegação de teste, o uso de dados de teste e as mudanças no estado do
sistema.
Usando as informações reunidas, considere os requisitos que determinarão a infra-estrutura de teste e os recursos que
ela precisará fornecer para permitir uma abordagem de teste bem-sucedida.
Subtópicos:
Alguns testes possuem uma estrutura comum ao cenário ou procedimento que é seguida quando um deles é executado, mas o
mesmo procedimento precisa ser conduzido várias vezes em diferentes itens de teste de destino. No caso da automatização
de testes, talvez seja útil criar scripts de teste ou funções de utilitário comuns que possam ser reutilizadas em
vários contextos diferentes para executar esses cenários de teste comuns de maneira eficiente. Isso fornecerá um ponto
central de modificação caso o cenário de teste precise ser alterado. Os exemplos citados incluem a condução de testes
de fronteira padrão em classes de elementos de interface apropriadas e a validação dos elementos de UI para a aderência
aos padrões de design de UI.
Quando for necessário conduzir testes em uma configuração de ambiente de teste específica, poderão ocorrer conflitos
nos valores dos dados de teste usados. Esse problema ocorre quando o ambiente é compartilhado por vários membros da
equipe de teste. Considere o uso de uma abordagem controlada por dados que desacople os valores dos dados de teste dos
scripts de teste que os utilizam e forneça um ponto central de coleta e modificação dos dados de teste. Isso resulta em
dois benefícios principais; a visibilidade dos dados de teste para todos os membros da equipe de teste, permitindo a
eles evitar possíveis conflitos no uso dos dados de teste, e um ponto central de modificação dos dados de teste quando
eles precisarem ser atualizados.
A maioria dos testes requer que o sistema esteja em um estado específico antes de sua execução e exige que o sistema
retorne a um estado conhecido específico após a conclusão dos testes. As dependências comuns incluem direitos de
segurança (função ou dados), dados sensitivos dinâmicos ou de contexto (por exemplo, datas do sistema, números de
pedido, preferências de ID do usuário etc.), ciclos de expiração de dados (por exemplo, senhas de segurança, expiração
de produtos, etc.). Alguns testes são altamente dependentes entre si; por exemplo, um teste pode criar um número de
pedido exclusivo e um teste subseqüente pode precisar despachar o mesmo número de pedido.
Uma solução comum é usar conjuntos de testes para seqüenciar os testes dependentes na ordem correta de estados do
sistema. Os conjuntos de testes poderão ser acoplados, em seguida, com utilitários apropriados de recuperação e
configuração de sistema. Para os esforços de teste automatizados, algumas soluções podem envolver o uso de um
armazenamento centralizado de dados dinâmicos do sistema e o uso de variáveis dentro dos scripts de teste que façam
referência às informações centralizadas.
Os testes algumas vezes precisam calcular ou derivar valores de dados apropriados de um ou mais aspectos do estado do
sistema de tempo de execução. Isso aplica-se aos valores dos dados de teste para os resultados informados e esperados.
Considere o desenvolvimento de utilitários que calculem os valores de dados derivados, simplificando a execução dos
testes e eliminando possíveis imprecisões causadas por falha humana. Onde possível, desenvolva esses utilitários de
modo que possam ser utilizados por esforços de teste manuais ou automatizados.
Para a automatização de testes, considere o isolamento de seqüências comuns de navegação e sua implementação usando
scripts de teste ou funções de utilitário centralizadas. Essas seqüências comuns de navegação poderão ser reutilizadas,
em seguida, em vários locais, fornecendo um ponto central de modificação caso a navegação seja posteriormente alterada.
Esses auxílios comuns de navegação simplesmente navegam o aplicativo de um ponto a outro; eles normalmente não executam
testes, verificando apenas seus estados inicial e final.
|
Identificar Necessidades de Design Específicas de Teste
|
Finalidade:
|
Identificar as necessidades da disciplina de teste, com possíveis restrições no processo de engenharia de
software, na arquitetura de software e no design e na implementação correspondentes.
|
Especialmente quando se trata de automatização de testes, é provável que as necessidades de implementação e avaliação
de testes apliquem algumas restrições no modo como a a equipe de desenvolvimento aprova o processo de engenharia de
software e na arquitetura e no design do software. É importante que a equipe de desenvolvimento de software não fique
muito tolhida em seu trabalho básico de desenvolvimento e que a equipe de teste tenha a possibilidade de executar o
teste necessário. Consulte a Tarefa: Obter Compromisso de Possibilidade de Teste para obter
informações sobre como apresentar as necessidades da equipe de teste para a equipe de desenvolvimento e localizar
soluções viáveis que atendam às necessidades de todas as disciplinas.
Usando as informações reunidas, considere os requisitos que o esforço de teste incluirá no esforço de desenvolvimento.
Subtópicos:
Considerando as interfaces identificadas, há algum requisito adicional que o esforço de teste precisará incluir no
design de software e expor subseqüentemente na implementação? Em alguns casos, interfaces adicionais serão necessárias
para suportar especificamente o esforço de teste ou interfaces existentes necessitarão de modos de operação adicionais
ou assinaturas de mensagem modificadas (mudanças nos parâmetros de entrada e retorno).
Em relação aos ambiente de implementação de destino (conforme capturados nas configurações do ambiente de teste) e à
própria programação de desenvolvimento, identifique as restrições e dependências incluídas no esforço de teste. Essas
dependências podem necessitar da provisão de stubs para simular elementos do ambiente não disponíveis ou com vários
recursos proibidos de serem estabelecidos para finalidades de teste ou para possibilitar o teste inicial dos
componentes do sistema parcialmente concluído.
Alguns testes talvez sejam importantes, mas demasiadamente caros para serem implementados como verdadeiros testes caixa
preta. Além disso, em ambientes de alta confiabilidade, é importante que seja possível testar e isolar erros o mais
rápido possível, permitindo uma rápida resolução. Nesses casos, talvez seja conveniente criar testes diretamente no
próprio software executável.
Várias abordagens diferentes podem ser consideradas para isso; duas das mais comuns incluem autotestes internos, em que
o software utiliza ciclos de processamento redundantes para executar testes de auto-integridade, e rotinas de
diagnóstico, que podem ser executadas no momento em que o software envia uma mensagem de evento de diagnóstico ou
quando o sistema é configurado para ser executado com rotinas de diagnóstico ativadas.
Algumas das opções de design e implementação da equipe de desenvolvimento permitirão ou inibirão o esforço de teste.
Embora algumas dessas opções sejam inevitavelmente necessárias, há muitas decisões menos importantes, principalmente na
área de implementação, que causam um impacto mínimo na equipe de desenvolvimento, mas um impacto significativo na
equipe de teste.
As áreas a serem consideradas incluem: Uso de protocolos padrão de comunicação reconhecidos; uso de componentes de
implementação de UI que podem ser reconhecidos pelas ferramentas de automatização de testes; aderência às regras de
design de UI, incluindo a nomenclatura de elementos de UI; uso consistente de convenções de navegação de UI.
|
Definir Requisitos de Possibilidade de Teste de Software
|
Finalidade:
|
Especificar os requisitos das funções de software necessárias para suportar a implementação e a execução de
testes.
|
Utilizando a tarefa anterior desempenhada na tarefa, defina os requisitos e as restrições específicos de teste que
devem ser considerados no design e na implementação do software.
É importante explicar claramente à equipe de desenvolvimento as razões pelas quais recursos específicos de teste
precisam ser construídos no software. Os principais motivos normalmente estarão contidos em uma destas áreas:
-
Para permitir a implementação de testes, manuais e automatizados, fornecendo uma interface entre o item de teste de
destino e o teste manual ou automatizado. Isso geralmente é mais relevante como um aspecto da automatização de
testes para ajudar a superar as limitações das ferramentas de automatização de testes no acesso ao aplicativo de
software tanto para entrada como para saída de informações.
-
Para permitir a condução de autotestes internos pelo próprio software desenvolvido.
-
Para permitir que itens de teste de destino sejam isolados do resto do sistema desenvolvido e testado.
As características específicas de teste criadas dentro do software precisam atingir um equilíbrio entre o valor de uma
característica de teste interna e o esforço necessário para implementá-la e testá-la. Como exemplos de características
de teste internas podem ser incluídos a produção de logs de auditoria, funções de autodiagnóstico e interfaces que
examinem o valor das variáveis internas.
Outro uso comum da funcionalidade específica de teste é durante o trabalho de integração em que é necessário fornecer
stubs para componentes ou subsistemas ainda não implementados ou incorporados. Há dois estilos de implementação
principais usados para stubs:
-
Os stubs e os drivers que são simplesmente "fictícios", sem nenhuma funcionalidade, exceto fornecer um valor
predefinido específico (ou valores), como valor de entrada ou de retorno.
-
Os stubs e drivers que são mais inteligentes e podem "simular" ou aproximar um comportamento mais complexo.
Esse segundo estilo de stub também permite isolar de modo eficiente componentes ou grupos de componentes do resto do
sistema oferecendo, portanto, flexibilidade na implementação e execução de testes. Segundo o comentário feito
anteriormente sobre características específicas de teste, é preciso tentar atingir um equilíbrio entre o valor de um
stub complexo e o esforço necessário para implementar e testar o stub. Use esse segundo estilo com prudência por dois
motivos; primeiro porque ele usa mais recursos para a implementação, e segundo porque ele ignora mais facilmente a
existência do stub e se esquece de removê-lo em seguida.
Registre suas descobertas em termos de requisitos específicos de teste diretamente nos modelos de design e
implementação ou usando uma ou mais especificações de interface de teste.
|
Definir Infra-estrutura de Teste
|
Finalidade:
|
Especificar os requisitos da infra-estrutura de teste necessária para suportar a implementação e a execução
de testes.
|
Utilizando a tarefa anterior desempenhada na tarefa, defina a infra-estrutura de teste necessária para suportar a
implementação e a execução do teste.
Lembre-se de que você está definindo as características de implementação da infra-estrutura; o principal objetivo é
definir as diversas partes da solução que implementará essa infra-estrutura.
Subtópicos:
Principais requisitos ou características da infra-estrutura de automatização de testes:
-
Modelo de Navegação: as abordagens comuns são round-trip, segmentada ou híbrida. Outras alternativas incluem a
utilização de uma estrutura de Ação do Word ou tabelas de navegação na tela
-
Acesso a Dados Externos: um método para acessar dados externamente a partir das instruções de teste
-
Relatório e Recuperação de Erros: rotinas comuns de manipulação de erros e wrappers de execução de recuperação do
Conjunto de Testes
-
Perfis de Segurança e de Acesso: IDs de usuário de execução de teste automatizado
-
A capacidade do software em conduzir autotestes
Registre suas decisões como definições nas seções de implementação da Arquitetura para Automatização de Testes,
processe a orientação em um ou mais Guias de Teste ou como Scripts de Teste/Conjuntos de Teste, ou teste as rotinas do
utilitário de biblioteca. Consulte o Produto de Trabalho: Arquitetura de Automatização de Teste para obter
sugestões adicionais.
Principais requisitos ou características da infra-estrutura de teste manual:
-
Repositório de Dados de Teste: um repositório comum para a definição de dados de teste.
-
Restauração e Recuperação: um método para restaurar ou recuperar a configuração do ambiente de teste para um estado
conhecido.
-
Para permitir que itens de teste de destino sejam isolados do resto do sistema desenvolvido e testado.
Registre suas decisões como orientação de processo em um ou mais Produto de Trabalho: Diretrizes Específicas do Projeto.
|
Avaliar e Verificar os Resultados
|
Finalidade:
|
Verificar se a tarefa foi concluída apropriadamente e se os produtos de trabalho resultantes são
aceitáveis.
|
Agora que o trabalho foi concluído, convém certificar-se de que o trabalho foi vantajoso e que não foi apenas um grande
consumo de papel. Você deve avaliar se o trabalho é de qualidade adequada e se ele é completo o suficiente para ser
útil aos membros da equipe que o utilizarão em seguida como entrada para o trabalho deles. Onde for possível, utilize
listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência são "suficientemente boas".
Faça as pessoas que realizam as tarefas de recebimento de dados, que dependem do seu trabalho como entrada,
participarem da revisão do trabalho temporário. Faça isso enquanto você tiver tempo disponível para tomar alguma ação
para resolver os problemas delas. Você também deve avaliar o trabalho em relação aos principais produtos de trabalho de
entrada para certificar-se de que eles foram representados de modo preciso e suficiente. Pode ser conveniente que o
autor do produto de trabalho de entrada revise o seu trabalho nesse sentido.
Não se esqueça que o RUP é um processo de entrega iterativo e que, em muitos casos, os produtos de trabalho evoluem com
o tempo. Nem sempre ele é necessário e, criar um produto de trabalho completo geralmente é contraproducente, pois ele
será usado apenas parcialmente ou não mais será usado em outros trabalhos. Isso acontece porque há uma grande
probabilidade de alteração na situação em torno do produto de trabalho e de que as suposições feitas durante a criação
do produto de trabalho estejam incorretas, antes do produto de trabalho ser utilizado, resultando em esforço perdido e,
portanto, em retrabalho dispendioso. Evite também a armadilha de gastar muitos ciclos na apresentação em detrimento do
valor do conteúdo. Nos ambientes de projeto em que a apresentação tem importância e valor econômico como um produto
liberado do projeto, convém utilizar um recurso administrativo para executar as tarefas de apresentação.
|
|
