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 típicos para implementar testes incluem gravar uma descrição textual na forma de um script a ser seguido (para testes manuais) e a programação, registro capturado ou geração de uma linguagem de programação baseada em script (para testes automatizados). 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:

• Scripts de Teste Manuais
• Scripts de Teste Programados
• Scripts de Teste Registrados ou Capturados
• Testes Gerados

Scripts de Teste Manuais

Muitos testes são melhor conduzidos manualmente e você deve evitar a ilusão de tentar automatizar os testes inapropriadamente. Os testes de usabilidade são uma área em que os testes manuais são, na maioria dos casos, uma solução melhor dos que os 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 de Destino com uma implementação manual. Essa abordagem permite que o testador conheça o item de destino, 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, observe que não é necessário nem aconselhável, ou mesmo possível, automatizar todos os testes que poderiam ser de alguma maneira conduzidos manualmente. A automaçã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 e na eficiência da criação e da manutenção de testes complexos. Entretanto, como ocorre com todas as ferramentas úteis, não é uma solução para todas as necessidades.

A automatização tem determinadas desvantagens: elas estão basicamente relacionadas à ausência de julgamento e raciocínio humanos durante a execução do teste. As soluções de automatização atualmente disponíveis simplesmente não têm capacidades 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 observadas do sistema aos estímulos. As atuais técnicas de teste automatizado e suas ferramentas de suporte têm normalmente capacidade limitada para perceber as implicações de certos comportamentos do sistema e têm capacidade mínima para inferir possíveis problemas através de raciocínio dedutivo.

Scripts de Teste Programados

É 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 eficaz, algumas considerações devem ser feitas para o design adequado: sem isto, a implementação provavelmente falhará. Se existe a possibilidade de o software desenvolvido ser modificado por diferentes pessoas ao longo do tempo, a situação normal, deve-se considerar a adoção de um estilo e uma forma comuns para o desenvolvimento de programas e garantir que sejam utilizados 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 de Destino. É 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. Assim como pode ser difícil detectar erros no Item de Teste de Destino, também pode ser difícil detectar erros 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.

Scripts de Teste Registrados ou Capturados

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:

• Capturando a interação com o cliente UI de um aplicativo, com base na interceptação das entradas enviadas a partir dos dispositivos de entrada periférica do cliente (mouse, teclado e assim por diante) ao sistema operacional do cliente. Em algumas soluções, isso é feito pela interceptação de mensagens de alto nível trocadas entre o sistema operacional e o driver de dispositivo que descreve as interações de alguma forma significativa. Em outras soluções, isso é feito pela captura de mensagens de baixo nível, geralmente baseadas nos movimentos do mouse ou em eventos de tecla para cima e para baixo.
• Interceptando as mensagens enviadas e recebidas na rede entre o aplicativo cliente e um ou mais aplicativos servidor. A interpretação bem-sucedida dessas mensagens está baseada normalmente no uso de protocolos padrão e reconhecidos de sistema de mensagens, como o HTTP, o SQL e assim por diante. Algumas ferramentas permitem a captura de protocolos de comunicação "base", como o TCP/IP, mas pode ser mais complexo trabalhar com Scripts de Teste dessa natureza.

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 compreender melhor esses problemas, recomendamos a análise do trabalho disponível na Internet dos autores a seguir: James Bach, Cem Kaner, Brian Marick e Bret Pettichord, bem como o conteúdo relevante na publicação Lessons Learned in Software Testing [KAN01]

Testes Gerados

Alguns dos softwares mais sofisticados para automatização de testes permite a geração real de vários aspectos do teste, tanto os aspectos procedurais como os aspectos dos Dados de Teste do Script de Teste, com base nos algoritmos de geração. Esse tipo de automatização pode desempenhar uma função útil em seu esforço de teste, mas não deve ser considerado como a única abordagem utilizada. A ferramenta Rational TestFactory e o recurso de geração de conjunto de dados Rational TestManager são implementações de exemplo deste tipo de tecnologia.

Configure o ambiente de teste, incluindo todo o hardware, software, ferramentas e dados. Certifique-se de que todos os componentes estejam funcionando corretamente. Em geral, isso envolverá alguma forma de reconfiguração do ambiente (por exemplo, reconfiguração do registro do Windows e outros arquivos de configuração), bem como a restauração de bancos de dados subjacentes a um estado conhecido e assim por diante, além de tarefas como colocar papel em impressoras. Embora algumas tarefas possam executadas automaticamente, alguns aspectos precisam da atenção de alguém.

Subtópicos:

• (Opcional) Inspeção Manual do Teste
• Identificar e Confirmar a Adequação de Previsões de Teste
• Reconfigurar o Ambiente de Teste a as Ferramentas

(Opcional) Inspeção Manual do Teste

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. O objetivo é verificar se todos os elementos requeridos para implementar o teste com êxito estão presentes.

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.

Identificar e Confirmar a Adequação das Previsões de Teste

Confirme se as Previsões de Teste que você planeja utilizar 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 de teste utilizando um campo exibido por meio da UI do aplicativo que indique ter ocorrido atualização do banco de dados, considere consultar independentemente o banco de dados de backend para verificar o estado dos registros correspondentes no banco de dados. 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.

Reconfigurar o Ambiente de Teste e as Ferramentas

Em seguida, você deve restaurar o ambiente, incluindo as ferramentas de suporte, para o estado original. Conforme mencionado em etapas anteriores, isso normalmente envolve alguma forma de reconfiguração básica do ambiente operacional, restauração de bancos de dados subjacentes para um estado conhecido e assim por diante, 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 de teste, que variam dependendo da sofisticação da ferramenta. Onde possível, considere armazenar as configurações de opções de cada ferramenta para que elas possam ser recarregadas facilmente com base em um ou mais perfis predeterminados. No caso de testes manuais, isso incluirá tarefas como, por exemplo, particionar uma nova entrada em um sistema de suporte para registrar os resultados de teste ou conectar a um sistema de log de problemas e de controles de mudanças.

No caso de ferramentas automatizadas para a implementação de testes, várias configurações distintas podem ser consideradas. Se as opções não forem definidas corretamente, a utilidade e o valor dos ativos de teste resultantes ficarão comprometidos.

Utilizando a Lista de Idéias de Teste, ou um ou mais artefatos de Casos de Teste selecionados, comece a implementar o teste. Comece designando ao teste um nome exclusivamente identificável (se já não houver algum) e prepare o IDE, a ferramenta de captura, a planilha ou o documento para começar a registrar as etapas específicas do teste. Trabalhe nas subseções a seguir quantas vezes forem necessárias para implementar o teste.

Observe que para alguns testes ou tipos de testes específicos, pode não ser vantagem documentar as etapas explícitas requeridas para conduzir o teste. Em determinados estilos de testes exploratórios , a repetição do teste não é um resultado esperado. Para muitos testes simples, uma descrição breve da finalidade dos testes será suficiente em vários casos para permitir que ela seja reproduzida.

Subtópicos:

• Implementar Ações de Navegação
• Implementar Pontos de Observação
• Implementar Pontos de Controle
• Resolver Erros de Implementação

Implementar Ações de Navegação

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 atuais classes de sistema, um "Mouse" ou outros dispositivo apontador é o meio principal e preferido para navegação. 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. Eles podem ser mais problemáticos para a automatização de testes e podem exigir a inclusão de extensões especiais da interface de teste no aplicativo para permitir que os elementos audiovisuais sejam carregados e processados no arquivo em vez de serem capturados dinamicamente.

Em algumas situações, talvez você queira, ou precise, executar o mesmo teste utilizando vários métodos de navegação. Existem diferentes abordagens que podem ser adotadas para alcançar isso, por exemplo: automatizar todos os testes utilizando um método e executar manualmente todos ou um subconjunto dos testes utilizando outros; separar os aspectos de navegação dos testes a partir dos Dados de Teste que caracterizam o teste específico, fornecendo e construindo uma interface de navegação lógica que permite que o método seja selecionado para conduzir o teste; simplesmente misture e combine os métodos de navegação.

Implementar Pontos de Observaçã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 Teste 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.

Implementar Pontos de Controle

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 Teste.

Resolver Erros na Implementação de Testes

Durante a implementação do teste, você provavelmente introduzirá erros na própria implementação do teste. Esses erros podem ser o resultado de coisas omitidas na implementação do teste ou podem estar relacionados a coisas que não foram consideradas no ambiente de teste. Será necessário resolver esses erros antes do teste poder ser considerado completamente implementado. Identifique cada erro encontrado e procure solucioná-los.

No caso da automatização de testes que utiliza uma linguagem de programação, isso pode incluir erros de compilação decorrentes de variáveis e funções não declaradas ou do uso inválido dessas funções. Verifique as mensagens de erro exibidas pelo compilador ou por qualquer outras origens de mensagens de erro, até que o Script de Teste não apresente erros sintáticos e outros erros básicos de implementação.

Observe que durante a execução subseqüente do teste, outros erros na implementação do teste podem ser localizados. Inicialmente, eles podem aparecer como defeitos no item de teste de destino - você precisa tomar cuidado ao analisar defeitos de teste se confirmar que os defeitos estão realmente no item de teste de destino, e não em algum aspecto da implementaçã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:

• Dados de Teste externos ao Script de Teste eliminam referências embutidas em código no Script de Teste
• Dados de Teste externos podem ser modificados facilmente, geralmente com impacto mínimo do Script de Teste
• Casos de Teste adicionais podem ser facilmente suportados pelos Dados de Teste com pouca ou nenhuma modificação de Script de Teste
• Dados de Teste externos podem ser compartilhados por muitos Scripts de Teste
• Scripts de Teste podem ser desenvolvidos para usarem Dados de Teste externos a fim de controlar a lógica de ramificação condicional no Script de Teste.

Especialmente no caso da automatização de testes, provavelmente você precisará gastar algum tempo estabilizando os trabalhos do teste quando ele estiver sendo executado. 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.

Recuperar o Ambiente de Teste para um Estado Conhecido

Mais uma vez, você deve restaurar o ambiente para seu estado original, limpando após o trabalho de implementação do teste. Conforme mencionado em etapas anteriores, isso normalmente envolve alguma forma de reconfiguração básica do ambiente operacional, restauração de bancos de dados subjacentes para um estado conhecido e assim por diante, além de tarefas, como carregar papel nas impressoras. Embora algumas tarefas possam executadas automaticamente, alguns aspectos precisam da atenção de alguém.

Configurar Ferramentas e Iniciar a Execução do Teste

Especialmente no caso de automatização de testes, as configurações nas ferramentas de suporte devem ser alteradas. O objetivo é verificar os trabalhos corretos do Script de Teste executando o Script de Teste.

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.

Resolver Erros de Execução

É muito comum a situação em que o trabalho feito e as abordagens utilizadas durante a implementação precisem de algum ajuste para permitir o teste seja executado de um modo não assistido, especialmente em relação à execução do teste sob várias Configurações do Ambiente de Teste.

No caso de automação de teste, prepare-se para gastar algum tempo verificando a função do teste "dentro das tolerâncias" e ajustando-as até que funcionem confiavelmente, antes de declarar o teste como implementado. Embora você possa retardar esta etapa para mais tarde no ciclo de vida (por exemplo, durante o desenvolvimento de Conjunto de Testes), isso não é recomendável: caso contrário, isso poderia resultar em um backlog de defeitos que precisam ser tratados.

Embora essa etapa pareça trivial, é 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.

Usando os requisitos de Rastreabilidade descritos no Plano de Teste, atualize os relacionamentos de rastreabilidade conforme necessário.

Agora que o trabalho foi concluído, é recomendável verificar se o trabalho foi vantajoso. 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 as listas de verificação fornecidas no RUP para verificar se a qualidade e a integridade estão suficientemente boas.

Permita que as pessoas que utilizarão seu trabalho como entrada durante a execução das tarefas de recebimento de dados façam parte da revisão do trabalho provisó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 seu trabalho em relação aos principais produtos de trabalho de entrada para se certificar de que eles foram representados ou considerados de modo exato e suficiente. Pode ser útil fazer com que o autor do produto de trabalho de entrada revise seu trabalho nessa base.

Não se esqueça de que o RUP é um processo de entrega interativo e que, em muitos casos, os produtos de trabalho evoluem com o tempo. Como tal, nem sempre é necessário, e em muitos casos é contraproducente, formar completamente um produto de trabalho que será utilizado apenas parcialmente ou que nem será utilizado imediatamente no trabalho subseqüente de recebimento de dados. Isso acontece porque há uma grande probabilidade de que a situação em torno do produto de trabalho sofra alterações e de que os pressupostos feitos quando o produto de trabalho foi criado se provem incorretos, antes que esse produto seja utilizado, resultando em retrabalho e, portanto, esforço perdido.

Evite também a armadilha de gastar muitos ciclos na apresentação em detrimento do valor do próprio 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 ou novato para executar o trabalho em um produto de trabalho de forma a aprimorar sua apresentação.