Roteiros de Teste Funcional - "Visualizando a funcionalidade na prática"

O Teste Funcional garante que todas as funcionalidades do sistema estão sendo executadas corretamente, bem como o comportamento do mesmo está ocorrendo conforme previsto na fase de levantamento de requisitos. Portanto, é essencial que criemos um roteiro de teste funcional levando em consideração a necessidade específica do usuário final, levando em consideração todas suas ações para com o sistema. 

Nesta fase, entende-se que as partes internas do componente está construída corretamente e agora iremos verificar se de fato a junção dos componentes está reagindo corretamente de acordo com as necessidades do usuário, funcionalidades e particularidades específicas do sistema. É importante lembrarmos que nesta fase também é necessária a modelagem dos casos de teste com erro em sua execução (Testes Negativos).

Existem diversas técnicas de modelagem de teste funcionais, abaixo estão elencadas algumas destas que estão descritas no Syllabus do exame CTAL-TA (ISTQB).:

Técnicas Baseada em Especificações
Partição de Equivalência
Análise de Valores-Limite
Tabela de Decisão
Gráficos Causa-Efeito
Testes de Transição de Estados
Técnicas de Testes Combinatórios
Teste de Caso de Uso
Teste de Estória de Usuário
Combinação de Técnicas

Técnicas Baseada na Experiência
Suposição de Erros
Teste Baseado em Checklists
Teste Exploratório

Teste de Características de Qualidade de Software
Teste de Acurácia
Teste de Adequação
Teste de Interoperabilidade
Teste de Usabilidade
Teste de Acessibilidade

Em outros post, entraremos a fundo em cada uma destas técnicas que influenciam na modelagem e levantamento dos casos de teste necessários para verificarmos corretamente o comportamento do sistema. 

Conceitualmente, para cada funcionalidade ou caso de uso do sistema deve haver um roteiro de teste funcional que deverá garantir que a mesma está gerando as saídas esperadas para o usuário final. Neste mesmo sentido, cada fluxo descrito no requisito deverá corresponder no mínimo a um caso de teste do roteiro, lembrando que existem fluxos básicos, alternativos e de exceção. O teste funcional deve sempre pensar no teste a partir da perspeciva do usuário do sistema.

Várias ferramentas de mercado realizam o gerenciamento e modelagem dos casos de teste, relacionando-os com seus casos de uso, fluxos e passos de execução,posteriormente também é possível gerar métricas e relatórios finais dos testes. Um exemplo é a ferramenta TestLink, em outros posts já disponibilizamos um guia específico de utilização deste software.

Abaixo estão descritos alguns casos de teste simples já relacionados com seus respectivos fluxos referentes ao caso de uso Consultar Cliente. Este exemplo contém apenas 1 fluxo básico, 1 alternativo e 1 de exceção.:




A estrutura do RTF é semelhante aos demais roteiros, porém seu conteúdo deve ser bem detalhado para que os executores do teste consigam realizar o teste corretamente.:

• Código/Número.: Normalmente pode-se colocar a referência do sistema a ser testado
• Funcionalidade/Caso de Uso.: Nomenclatura da funcionalidade
• Condição.: Cenário a ser testado
• Pré-Condições.: Situações necessárias para que o teste seja executado (Ex.: Perfis, Acessos, Configurações, Execuções anteriores)
• Dados de Entrada.: Passo-a-passo detalhado para que o testador consiga executar o teste com sucesso
• Resultado Esperado.: Saídas específicas geradas após a execução do teste
• Status do Teste.: Indicação da realização do teste (Ex.: Ok, Nok, Não testado)
• Local de Teste.: Indicação da tela, interface, local onde o executor realizou o teste
• Observações - Comentários pertinentes ao teste. Neste campo, pode-se indicar se refere a um Teste negativo, positivo ou regressão. Também pode-se indicar a técnica de teste utilizada ou ciclo de teste que está sendo executado.

Após esta breve descrição sobre Roteiro de Teste Funcional, encerramos esta série específica de três posts. Caso tenham alguma dúvida, sugestão ou necessidade específica entre em contato.

Testar é garantir a informação!

Roteiros de Teste integrado - "Consolidando Relacionamentos"

Após dissertarmos à respeito dos rtu's (roteiros de teste unitário), passaremos a explicar de forma macro todos os conceitos referentes 
ao teste de integração entre componentes, os RTI's. Aparentemente, parece simples porém na prática percebemos no mercado uma real dificuldade na identificação do que deve ser testado em nível de integração que ainda não tenha sido testado em nível unitário e não será posteriormente testado em nível funcional.

Sendo assim, inicialmente necessitamos ter bem definido em nossas mentes o conceito de teste integrado. Teste de integração é a fase do teste de software em que módulos são combinados e testados em grupo. Ela sucede o teste de unidade, em que os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo (integrado) é testado num ambiente que simula o ambiente de produção (Origem: Wikipédia, a enciclopédia livre).

Nesta fase da elaboração do Roteiro de Teste Integrado, podemos utilizar ainda as técnicas de teste caixa-branca (Considerar a estrutura interna do componente) e caixa preta (Considerar a estrutura externa, front-end), pois em muitos casos é essencial sabermos os valores de entrada e saída de "n" variáveis distintas bem como a chamada de módulos específicos, liberação de marcas e mudança de status em flags do sistema.

É importante ressaltar que nesta fase, o resultado final da funcionalidade ainda não interessa, pois esta validação será feita na fase do Roteiro de Teste Funcional, por exemplo.: "Verificar se após o usuário digitar seu nome e senha, seus dados foram retornados corretamente conforme o esperado pela funcionalidade e definido anteriormente na fase de levantamento de requisitos junto ao cliente".

Basicamente, podemos testar componentes do sistema de forma integrada de acordo com as seguintes técnicas abaixo listadas (Lembrando que todas as integrações possíveis entre componentes devem ser consideradas e inseridas no roteiro).:

Teste Incremental.: Componentes ou sistemas são integrados e testados sozinhos ou em pequenos grupos por vez, até que todos os componentes ou sistemas sejam testados (Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ). Sendo assim, consideramos que os testes são construídos e testados pequenos incrementos, em que erros são mais fáceis de corrigir (Ex.: Top Down e Bottom Up).

Top Down.: Componente na parte superior da hierarquia de componentes é testado primeiro, e os componentes nos níveis mais baixos são simulados por stubs(Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ).

Bottom up.: Componentes de nível mais baixo são testados em primeiro lugar, e, então utilizados para facilitar o teste de componentes de nível mais alto(Glossário de Termo de Teste - ISTQB, CTFL, Versão 1.3 ).

Big bang.: Elementos de um software ou hardware, ou ainda de ambos, são combinados todos de uma vez, ao invés de em estágios, em um componente ou sistema geral(Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ). 

Teste de Regressão.: Quando um novo componente for integrado ao sistema, o mesmo pode apresentar erros que anteriormente não ocorriam. Portando, deve-se testar novamente os casos que já foram conduzidos anteriormente visando a descoberta de novas falhas.

Em muitos casos há a integração entre plataformas distintas (Ex.: Camada Front-End.NET e camada de negócios e acesso em Mainframe), e nestas situações também devem ser consideradas as interações entre os componentes para garantir a real eficácia e vínculo entre os argumentos e parâmetros dos mesmos. Além disso, também é importante testarmos situações de erro exceção, ou seja, casos em que a chamada do componente não é realizada com sucesso.

Um Roteiro de Teste Integrado estruturado de maneira simples, deve conter informações como.:

• Número do Caso de Teste.: Número Sequencial ou Código específico
• Condição ou Cenário.: Integração a ser testada
• Pré-Condições de execução.: Situações necessárias para que o teste seja executado (Ex.: Perfis, Acessos, Configurações, Execuções anteriores)
• Dados de Entrada.: Informações ou passos necessários para execução do teste
• Resultado Esperado.: Saídas geradas após a execução do teste
• Status do Teste.: Indicação da realização do teste (Ex.: Ok, Nok, Não testado)
• Local de Execução do Teste.: Local ou ferramenta em que a integração será testada
• Ciclo/Etapa do Teste.: Indicação do ciclo de teste a ser testado
• Observações.: Comentários pontuais pertinentes ao caso de teste

Para finalizar, vejamos na imagem abaixo todas as possibilidades e técnicas de integração que podem ser testadas no projeto "CalculoSimples".:

Testar é garantir a informação!

Roteiros de Teste Unitário - "Pequenas partes que garantem a qualidade"

De acordo com a definição do ISTQB (International Software Testing Qualification Board), o Teste Unitário (ou teste de componente) corresponde ao teste realizado com os componentes individuais de um software, considerando componente como um item mínimo de software que pode ser testado isoladamente. Trata-se de uma parte importantíssima do teste de software, pois garante que a menor unidade do sistema está funcionando corretamente considerando diversas possibilidades de entrada de dados.

Na prática, podemos entender como trechos de código específicos, consistências, métodos, rotinas, chamadas a outros módulos, entre outros testes que podem existir dentro de um item de software. Lembrando que há uma distinção de testes unitários para linguagens de plataforma distribuída (Por exemplo.: .NET, Java, PHP) e para Mainframe que basicamente se restringe a testes existentes em componentes construídos na linguagem Cobol. A quantidade de tipos distintos de itens de teste e componentes é muito maior na plataforma distribuída.

Portanto, vamos nos ater a um exemplo específico de uma classe do projetoCalculoSimples.

No roteiro de teste unitário, teremos uma cobertura mínima de 6 casos de teste (5 casos de sucesso e 1 de erro) e a variação da quantidade dependerá das entradas dos parâmetros que resultarão em saídas específicas.

É comum considerarmos no mínimo um caso de teste de execução com sucesso e todos os outros casos referentes à situações de erro, porém o ideal é criar casos de teste para todos as possibilidades e desvios lógicos existentes no componente. Neste caso específico só há uma situação de erro descrita, porém se  tivéssemos definido mais tratamentos, todos deveriam ser considerados no Roteiro de Teste Unitário. Já as chamadas dos métodos InserirValor() e TransacaoXAB01() serão considerados somente em nível de integração, pois fazem referência a outras classes.

Talvez você esteja se questionando como esta classe será testada, uma vez que este teste se refere a menor unidade do sistema e as demais partes que se relacionam com este componente talvez ainda não tenham sido construídas. Para isto, deve-se criar um componente Driver, ou seja, um componente controlador que irá realizar a chamada desta classe. Em algumas situações também pode-se criar um stub que é um dispositivo que serve para simular um componente chamado pelo programa principal, caso fosse o escopo do teste.

O ideal é que todo roteiro de teste ao ser criado considere algumas premissas básicas para que o teste seja executado com sucesso.:

 - Possibilidade de Automação
 - Possibilidade de Reprodução e Repetibilidade
 - Facilidade na Implementação
 - Execução Ágil
 - Possibilidade de Reuso / Uso Futuro

Minimamente todo roteiro de teste unitário deve conter as seguintes colunas.:

 - Número Sequencial do Caso/Item de teste
 - Condição que o caso de teste irá testar
 - Dados de entrada que possibilitarão o teste
 - Resultado esperado do teste
 - Local físico/lógico que o teste será executado
 - Status do teste
 - Observações pertinentes ao teste

No mercado existem diversos frameworks e técnicas de teste unitário que abordaremos detalhadamente em outros posts.

No imagem a seguir, pode-se visualizar um exemplo contendo o dois casos unitários modelados (1 positivo e 1 negativo) da classe Matemática.

Testar é garantir a informação!