Papéis e Atividades > Conjunto de Papéis do Desenvolvedor > 
Designer de Teste > 
Definir Elementos de Testabilidade
Atividade:
| ||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Entender como cada mecanismo de teste necessário precisará suportar os itens de teste-alvo. |
Usando cada mecanismo de teste sucessivamente, reveja os itens de teste-alvo. Identifique os itens-alvo que necessitarão do suporte de cada mecanismo. Lembre-se de que os itens-alvo incluem o software que está sendo desenvolvido, além de elementos de software, sistemas operacionais e hardware de outros fabricantes. Os mecanismos de teste precisarão ser implementados para suportar o teste de qualquer um desses itens.
| Finalidade: | Entender os aspectos dinâmicos 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 implantação, é possível identificar itens relevantes, como classes de controle, processos, threads e eventos. Alguns locais para você iniciar a pesquisa incluem as classes com estereótipo <<controle>>, realizações de casos de uso e elementos descritos na visão de arquitetura do processo ou no modelo de implementação com estereótipo <<processo>> ou <<thread>>.
Em relação às restrições impostas pelo ambiente de teste, defina os requisitos físicos
| 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. Usando os Modelos de Design e Implementação, procure elementos definidos com o estereótipo <<interface>>. Examine também os modelos para verificar a existência de classes com o estereótipo <<fronteira>>.
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.
| 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-alvo. 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 dinâmicos ou contextuais (por exemplo, datas de sistema, números de pedido, preferências de identificação 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. Sempre que possível, desenvolva esses utilitários para que eles possam ser utilizados pelos 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.
| 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 e testes , é provável que as necessidades de implementação e avaliação de testes imponham algumas restrições no modo de execução do processo de engenharia de software pela equipe de desenvolvimento, bem como 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 Atividade: Obter Compromisso de Testabilidade para obter informações sobre como apresentar as necessidades da equipe de teste à equipe de desenvolvimento e como encontrar 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 ambientes-alvo de implantação (conforme capturados nas configurações de 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 do provimento de stubs para simular os elementos do ambiente não disponíveis ou com vários recursos proibidos de serem estabelecidos para fins de teste ou para permitir um 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á algumas 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.
Áreas a serem consideradas: Uso de protocolos de comunicação reconhecidos padrão; Uso de componentes de implementação de UI que podem ser reconhecidos por ferramentas de automatização de testes; Aderência às regras de design de UI, incluindo a nomeação de elementos de UI; Uso consistente das convenções de navegação de UI.
| Finalidade: | Especificar os requisitos das funções de software necessárias para suportar a implementação e a execução de testes. |
Usando o trabalho anterior executado na atividade, defina os requisitos específicos de teste e as restrições a serem consideradas no design e na implementação do software.
É importante explicar claramente à equipe de desenvolvimento os motivos pelos quais características específicas de teste precisam ser criadas no software. Os principais motivos normalmente estarão contidos em uma destas áreas:
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:
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.
| Finalidade: | Especificar os requisitos da infra-estrutura de teste necessária para suportar a implementação e a execução de testes. |
Usando o trabalho anterior executado na atividade, defina a infra-estrutura de teste necessária para suportar a implementação e a execução de testes.
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:
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 Artefato: Arquitetura para Automatização de Testes para obter outras sugestões.
Principais requisitos ou características da infra-estrutura de teste manual:
Registre suas decisões como orientação do processo em um ou mais dos artefatos Artefato: Guia de Teste.
| 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 |
