Papéis e Atividades > Conjunto de Papéis do Testador > 
Testador > 
Implementar Teste
Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Determinar a técnica apropriada para a implementação do teste. |
Selecione a técnica apropriada para a implementação do teste. Para cada teste a ser realizado, considere a implementação de pelo menos um Script de Teste. Em alguns casos, a implementação de determinado teste utilizará vários Scripts de Teste. Em outros, um único Script de Teste garantirá a implementação de diversos testes.
Os métodos mais comuns para a implementação dos Scripts de Teste são o manual, o programado, o registrado e o gerado. Todos os métodos serão abordados nas próximas seções.
Como ocorre com a maioria das abordagens, você obterá melhores resultados se usar uma combinação das técnicas a seguir. Embora você não precise usar todas elas, não se limite a utilizar apenas uma técnica.
Subtópicos:
Muitos testes devem ser realizados manualmente. Para testar a usabilidade, os testes manuais são, em grande maioria, uma solução melhor do que os testes automatizados. Em geral, os testes que precisam de validação da precisão e qualidade dos resultados físicos de um sistema de software também requerem validação manual. Como heurística geral, uma boa idéia é começar os primeiros testes de determinado Item de Teste-Alvo com uma implementação manual. Essa abordagem permite que o testador conheça o item-alvo, adapte comportamentos inesperados e determine a próxima ação a ser executada.
Há momentos em que os testes manuais são posteriormente automatizados e reutilizados como parte de uma estratégia de testes de regressão. No entanto, lembre-se de que não é necessário nem aconselhável — ou até mesmo possível — automatizar todos os testes que podem ser realizados manualmente. A automatização oferece vantagens em termos de velocidade e precisão na execução dos testes, como também em termos de visibilidade e comparação dos resultados detalhados. A automatização dinamiza a criação e a manutenção de testes complexos, mas, como ocorre com todas as ferramentas úteis, não é uma solução para todas os casos.
A automatização apresenta algumas desvantagens: basicamente estão relacionadas à ausência do julgamento e raciocínio humanos durante a execução de testes. As soluções atuais de automatização não têm as habilidades cognitivas de uma pessoa — e é bem provável que nunca as tenham. Durante a implementação de um teste manual, o raciocínio humano pode ser aplicado às respostas do sistema aos estímulos. Em geral, as técnicas de teste automatizadas e suas ferramentas de suporte têm uma capacidade mínima de perceber as implicações de certos comportamentos do sistema. Atualmente, não são capazes de inferir possíveis problemas através de raciocínio dedutivo.
É o método praticado pela maioria dos testadores que fazem uso da automatização. Em sua forma mais pura, essa prática é realizada da mesma maneira e com os mesmos princípios gerais da programação de software. Sendo assim, os métodos e as ferramentas usados na programação de software são, geralmente, aplicáveis e úteis à programação da automatização de testes.
Com a utilização de um ambiente padrão de desenvolvimento de software (como o Microsoft Visual Studio ou o IBM Visual Age) ou de um ambiente de desenvolvimento especializado para a automatização de testes (como o IDE fornecido pelo Rational Robot), o testador fica livre para utilizar efetivamente as características e a potência do ambiente de desenvolvimento.
Os aspectos negativos da programação de testes automatizados relacionam-se aos aspectos negativos da programação em si como técnica geral. Para que a programação seja eficiente, considere o design adequado: sem ele, a implementação provavelmente falhará. Se existe a possibilidade de o software desenvolvido ser modificado por diversas pessoas ao longo do tempo — a situação normal — é importante pensar em adotar um estilo e uma forma comuns para o desenvolvimento de programas, e garantir que sejam usados corretamente. As duas questões mais importantes referem-se ao mau uso dessa técnica.
Primeiro, existe o risco de o testador ficar muito absorvido com as características do ambiente de programação e levar muito tempo criando soluções modernas e sofisticadas para os problemas, que poderiam ser obtidas de modo mais simples. Com isso, o testador desperdiça tempo precioso com tarefas que são de programação, em detrimento de tarefas reais de teste e avaliação dos Itens de Teste-Alvo. É preciso disciplina e experiência para não cair nessa armadilha.
Em segundo lugar, existe o risco de introduzir erros no código do programa usado para implementar o teste devido a omissões ou erros humanos. Alguns desses erros podem ser facilmente depurados e corrigidos no curso natural da implementação do teste automatizado: outros não. Pode ser difícil detectar erros no Item de Teste-Alvo, como também no software de automatização de testes. Além disso, os erros podem ser introduzidos se os algoritmos usados na implementação de testes automatizados se basearem nos mesmos algoritmos incorretos usados pela própria implementação do software. Dessa forma, os erros não são detectados e permanecem ocultos por uma falsa segurança oferecida pelos testes automatizados que, aparentemente, são executados com êxito. Diminua esse risco usando, quando possível, algoritmos distintos nos testes automatizados.
Há várias ferramentas de automatização de testes que permitem registrar ou capturar a interação humana com um aplicativo de software e produzir um Script de Teste básico. Existem numerosas soluções de ferramentas para esses casos. A maioria das ferramentas produz um Script de Teste implementado com alguma forma de linguagem de programação de alto nível e normalmente editável. Os designs mais comuns funcionam de uma das seguintes maneiras:
Embora seja útil incluir essas técnicas como parte da sua abordagem de testes automatizados, alguns praticantes acham que elas são limitadas. Uma das principais preocupações é de que algumas ferramentas não fazem nada além de capturar a interação entre os aplicativos. Sem a inclusão adicional de pontos de observação que capturem e comparem estados do sistema durante a execução de scripts subseqüentes, o Script de Teste básico não pode ser considerado um teste totalmente completo. Quando esse for o caso, o registro inicial precisará ser posteriormente ampliado com um código adicional de programa personalizado para implementar os pontos de observação no Script de Teste.
Vários autores publicaram livros e ensaios sobre esse e outros assuntos relacionados à utilização do registro ou captura do procedimento de teste como uma técnica de automatização. Para ampliar seus conhecimentos sobre essas questões, verifique na Internet o trabalho disponível dos seguintes autores: James Bach, Cem Kaner, Brian Marick e Bret Pettichord, e o conteúdo relevante do livro Lessons Learned in Software Testing [KAN01]
Alguns dos softwares mais sofisticados para a automatização de testes permite a criação de vários aspectos do teste — aspectos procedurais ou aspectos dos Dados de Teste do Script de Teste — com base na geração de algoritmos. Esse tipo de automatização pode desempenhar um papel útil no seu esforço de teste, mas não deve ser considerado como a única abordagem utilizada. As características de geração de pool de dados do Rational TestFactory e do Rational TestManager são exemplos de implementações desse tipo de tecnologia.
| Finalidade: | Preparar o ambiente para o estado inicial correto. |
Configurar o ambiente de teste para assegurar que todos os componentes necessários (hardware, software, ferramentas, dados etc.) tenham sido implementados, estejam prontos no ambiente de teste e no estado correto para permitir a realização dos testes. Em geral, esse procedimento envolve alguma forma de redefinição básica do ambiente (por exemplo, o arquivo de Registro e outros arquivos de configuração), a restauração de bancos de dados básicos em um estado conhecido, além de tarefas, como carregar papel nas impressoras. Embora algumas tarefas possam executadas automaticamente, alguns aspectos precisam da atenção de alguém.
| Finalidade: | Verificar se todos os elementos de teste necessários estão presentes e garantir que o teste seja implementado corretamente. |
Principalmente aplicável para automatizar Scripts de Teste, pode ser vantajoso para fazer uma inspeção técnica manual inicial do teste a fim de confirmar se os pré-requisitos estão presentes. Durante a inspeção técnica, verifique a integridade do ambiente, o design do software e do teste. A inspeção técnica é mais relevante quando você usa uma técnica de registro interativa, e menos relevante quando você programa o Script de Teste.
Se o software está devidamente estável ou amadurecido, é possível ignorar esse passo, em que você diminui o risco de ocorrência de problemas em áreas onde a inspeção técnica manual não é suficientemente eficaz.
Subtópicos:
Durante essa inspeção técnica, confirme se as Previsões de Teste que você pretende usar são adequadas. Se ainda não foram identificadas, este é o momento de fazê-lo.
Tente confirmar, por meios alternativos, se as Previsões de Teste selecionadas fornecerão resultados precisos e confiáveis. Por exemplo, se você planeja validar os resultados do teste usando um campo da interface gráfica do usuário de um aplicativo que indique ter ocorrido atualização do banco de dados, poderá consultar independentemente o banco de dados de back-end para verificar o estado dos respectivos registros. Opcionalmente, você pode ignorar os resultados apresentados em uma caixa de diálogo de confirmação de atualização e confirmar a atualização procurando o registro por meio de uma função ou operação alternativas de front-end.
| Finalidade: | Preparar o ambiente e as ferramentas de suporte para o estado inicial correto. |
Em seguida, você deve restaurar o estado original do ambiente. Em geral, esse procedimento envolve alguma forma de redefinição básica do ambiente operacional (por exemplo, o arquivo de Registro e outros arquivos de configuração), a restauração de bancos de dados básicos em um estado conhecido, além de tarefas, como carregar papel nas impressoras. Embora algumas tarefas redefinidas possam ser executadas automaticamente, vários aspectos precisam de atenção humana.
Defina as opções de implementação das ferramentas de suporte. Dependendo do nível de sofisticação da ferramenta, várias opções podem ser usadas. Se as opções não forem definidas corretamente, a utilidade e o valor dos ativos de teste resultantes ficarão comprometidos. Sempre que possível, tente armazenar essas configurações e opções de ferramenta para que elas possam ser recarregadas facilmente com base em um ou mais perfis predeterminados.
No caso de ferramentas automatizadas para a implementação de testes, várias configurações distintas podem ser consideradas. No caso de testes manuais, pode ser uma simples questão de particionar uma nova entrada em um sistema de suporte para registrar os resultados em sistemas de registro de problemas e solicitações de mudança.
| Finalidade: | Implementar corretamente um Script de Teste reutilizável e identificar as Solicitações de Mudança necessárias. |
Com a Lista de Idéias de Teste, um ou mais Casos de Teste selecionados ou o Modelo de Análise de Carga de Trabalho, comece a implementar o teste. Primeiro, dê ao teste um nome identificado com exclusividade (caso ele ainda não tenha um nome) e prepare o IDE, a ferramenta ou o documento de captura para começar a registrar os passos específicos do teste. Trabalhe nas seções seguintes quantas vezes forem necessárias para implementar o teste.
Subtópicos:
Programe, registre ou gere as ações de navegação necessárias. Comece selecionando o método de navegação adequado. Para a maioria das classes de sistema atuais, um "Mouse" ou outro dispositivo apontador é o principal meio de navegação, e também o preferido. Por exemplo, o dispositivo indicador e de escrita usado com Personal Digital Assistants (PDA) equivale teoricamente a um Mouse.
Geralmente, o teclado é o meio de navegação secundário. Na maioria dos casos, a navegação será estabelecida por uma combinação de ações orientadas por mouse e por teclado.
Em alguns casos, você deverá considerar métodos que usam ativação por voz, luz, estímulos visuais e outras formas de reconhecimento. Esses meios podem ser mais problemáticos para os testes automatizados e exigir a inclusão de extensões especiais de teste no aplicativo, para que os elementos audiovisuais sejam carregados e processados no arquivo e não capturados dinamicamente.
Em algumas situações, você talvez queira — ou precise — realizar o mesmo teste usando vários métodos de navegação. Diversas abordagens podem ser aplicadas para esse fim, como, por exemplo: automatizar todos os testes usando um método e realizar subconjuntos parciais ou completos dos testes usando um outro. Separar os aspectos de navegação dos testes dos Dados de Teste que caracterizam o teste específico, oferecendo e criando uma interface de navegação que permita a qualquer método selecionado orientar o teste'; combinar métodos de navegação.
Em cada ponto do Script de Teste em que uma observação deva ser feita, use a Previsão de Teste adequada para capturar as informações desejadas. Em muitos casos, as informações obtidas do ponto de observação precisarão ser registradas e mantidas para serem usadas como referência em pontos de controle subseqüentes.
Quando usar um teste automatizado, decida como as informações observadas serão reportadas a partir do Script de Teste. Muitas vezes, é apropriado apenas registrar a observação em um Log de Testes central relativo ao tempo delta decorrido desde o início do Script de Teste. Em outros casos, observações específicas podem ser inseridas separadamente em uma planilha ou em um arquivo de dados para usos mais sofisticados.
Em cada ponto do Script de Teste que precise de uma decisão de controle, obtenha e avalie as informações adequadas para determinar a ramificação correta do fluxo de controle a ser seguida. Os dados recuperados a partir de pontos de observação anteriores são, em geral, informações para os pontos de controle.
Onde houver um ponto de controle e uma decisão sobre a próxima ação no fluxo de controle, recomenda-se registrar os valores de entrada no ponto de controle e o fluxo resultante selecionado no Log de Testes.
Durante a implementação de testes, você encontrará erros, omissões e outras questões que precisam ser solucionadas antes da completa implementação dos testes. Identifique cada erro encontrado e procure solucioná-los.
No caso da automatização de testes, podem ser erros de conclusão decorrentes de variáveis e funções não declaradas ou do uso inválido dessas funções. Verifique as listagens de erro do compilador e de outras fontes, até o Script de Teste não apresentar erros de sintaxe nem outros erros óbvios.
| Finalidade: | Criar e manter dados, armazenados separadamente dos scripts de teste, que são usados por esses scripts durante a execução do teste. |
Com freqüência, é mais apropriado manter os Dados de Teste externos ao Script de Teste. Dessa forma, você garante a flexibilidade, simplicidade e segurança da manutenção de Scripts e Dados de Teste. Os conjuntos de dados externos são úteis para os testes da seguinte maneira:
| Finalidade: | Garantir que o ambiente seja corretamente limpo após o desenvolvimento do Script de Teste. |
| Finalidade: | Verificar se o funcionamento do Script de Teste está correto executando o Script de Teste. |
Depois de concluir a implementação básica do Script de Teste, ele deverá ser testado para garantir que esteja implementando os testes individuais corretamente e de que sua execução também esteja correta.
Siga esse passo usando a mesma versão do Build do software usada para implementar os Scripts de Teste. Dessa forma, você elimina possíveis problemas decorrentes de erros introduzidos em builds subseqüentes.
| Finalidade: | Estabilizar o funcionamento do teste quando executado. |
É bastante comum a situação em que o trabalho feito e as abordagens usadas durante a implementação precisem de algum "ajuste" para que o teste seja executado em uma ou mais Configurações de Ambiente de Teste.
Prepare-se para gastar algum tempo com verificações, "tolerâncias das funções" de teste e com ajustes antes de afirmar que o teste foi implementado. Embora você possa adiar esse passo, não é recomendável fazê-lo: você pode terminar com um enorme registro de falhas que precisarão ser solucionadas posteriormente.
| Finalidade: | Deixar o ambiente no estado em que foi encontrado ou no estado necessário para a implementação do próximo teste. |
Esse passo pode parecer trivial, mas é importante criar o hábito de trabalhar efetivamente com os outros testadores da equipe — principalmente quando o ambiente de implementação é compartilhado. Também é importante estabelecer uma rotina que nos faça pensar sobre a natureza secundário do sistema.
Em um esforço de teste basicamente manual, identificar e solucionar problemas de restauração de ambientes é uma tarefa quase sempre simples. Não se esqueça de que os testes automatizados apresentam muito menos tolerância a problemas não previstos relacionados ao estado do ambiente.
| 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 |
