Teste com qualidade

Ao longo dos tempos, a forma de trabalhar com testes de software vem alterando de acordo com evoluções nos processos de metodologias de trabalho diferenciados.

Sabemos da necessidade de teste de software que é a execução do produto para verificar e/ou validar se está procedendo como descrito na especificação, bem como se funciona de acordo com as configurações do ambiente onde será utilizado. Pois a liberação de versões de qualidade e confiáveis faz com que a marca tenha visibilidade e cresça no mercado.

O teste tem por objetivo antecipar possíveis falhas em um produto, fazendo com que as causas das falhas possam ser corrigidas antes de sua entrega final. Outro objetivo é prover informações suficientes para tomadas de decisões sobre a distribuição do software ou quais estratégias para as próximas fases do desenvolvimento e implantação em produção nos clientes.

Na prática podemos ver vários níveis de execução de testes que nos auxiliam no caminho para maior qualidade do produto, como:

• Teste de Unidade verificando o comportamento das menores unidades do código;
• Teste de Integração testando os módulos combinados entre si, ou seja, testados agrupados — nesse teste pode ser que um módulo dependa do outro, como por exemplo um processo que depende de alguns cadastros prévios;
• Teste de Sistema que verifica os requisitos num ambiente de produção — esse nível de teste está no escopo da técnica de caixa-preta, e dessa forma não requer conhecimento da estrutura interna do sistema;
• Teste de Regressão que é uma técnica que consiste na aplicação de testes em versões mais recentes do software usando como resultado esperado o retorno de versões anteriores, para garantir que não surgiram novos defeitos em componentes já analisados, ou que alguma alteração em determinado ponto do sistema não causou efeito colateral;
• E, por fim, o nível de Teste de Aceitação realizado antes de sua disponibilização do produto — pode ser executado pelo cliente para ver se está de acordo com o que foi solicitado por ele ou por um testador para liberação de nova versão no mercado.

Há também a divisão por tipos de teste que colaboram para maior qualidade do produto e dependem do alvo a ser atingido como:

• Teste funcional que avalia funções do sistema em execução e também podem estar descritos de diversas formas como em especificações, regras de negócios, épicos, estórias descritas pelos POs (Products Owners), casos de uso ou até mesmo em legislações;
• Teste Não Funcional onde são verificadas características do produto como usabilidade, performance, segurança ou a robustez do sistema, são testes comportamentais do sistema;
• Teste Estrutural que são usados para avaliar a estrutura ou arquitetura do componente, se está correta, completa e especificada;
• E, ainda, este de Confirmação e Regressão que servem para avaliar possíveis efeitos colaterais das alterações em códigos legados (regressão) e para avaliar a correção no produto (confirmação).

Na maioria das vezes é recomendado a automação tanto do teste de regressão quanto de confirmação para que ao executar a switch automatizada sirva de regressão.

Ainda existem técnicas de caixa branca que possuem embasamento na estrutura interna de um componente ou sistema e técnicas de caixa preta realizadas através da execução do produto como usuário. O teste utilizando a técnica de caixa preta será facilitado se houver criação de cenários de testes baseados no dia a dia do usuário para a execução do produto, geralmente analisando uma documentação, chamada de especificação, no momento dessa criação.

Como exemplos de testes de caixa-preta temos como exemplos:

• Teste com valores válidos como entrada de dados que devem ser aceitos pelo módulo refletindo em saídas corretas.
• Já os testes com valores inválidos devem ser rejeitados pelo módulo, apresentando uma mensagem que avisa ao usuário o motivo da não aceitação de determinado valor.

As partes podem ser executadas para qualquer tipo de dados relacionados ao teste, como por exemplo: valores de código que podem ser numéricos, alfanuméricos, aceitar ou não caracteres, etc.

Podem também relacionar com o tempo, antes ou depois de algum evento. Ou, então, por parâmetros de integração, como componentes de integração preenchidos ou não.

Seria recomendável utilizar pequenas partes de testes e aumentar o escopo gradativamente para que não ocorra o risco de mascarar falhas por combinações de testes.

Existe a possibilidade de mascarar uma falha quando há uma sobreposição de falhas, correndo o risco de corrigir somente a última e o produto final não estar corretamente testado.

A análise de valor limite é um tipo de teste de partição de equivalência utilizado para dados numéricos ou sequenciais. Também é muito comum em testes com datas.

Valores mínimos e máximos de um determinado campo no módulo do produto são seus valores limites.

Valor Limite

Esse é um exemplo de análise de valor limite:

Férias de um funcionário devem ser pagas antes do vencimento do segundo período aquisitivo, caso contrário ocorre pagamento de férias em dobro referente aos dias que ultrapassarem esse limite.

Supondo que a admissão foi 14/02/2020 e ainda há 30 dias pendentes para gozo de férias, então a data limite para o gozo de férias deve ser 15/01/2022, porque são os 30 dias que antecedem o segundo vencimento do período aquisitivo.

Pensando em teste com valor limite temos:

• Férias iniciando antes do dia 15/01/2022–30 dias de gozo — Não paga férias em dobro
• Férias iniciando em 15/01/2022– 30 dias de gozo — Não paga férias em dobro
• Férias iniciando depois de 15/01/2022–30 dias de gozo — Paga férias em dobro dos dias que ultrapassarem o limite de 13/02/2022

Pensando no teste acima, ainda pode ser verificada a quantidade de dias pagos, como férias em dobro, por exemplo:

• Férias iniciando em 16/01/2022–30 dias de gozo — paga 1 dia de férias em dobro.
• Férias iniciando em 13/02/2022–30 dias de gozo — paga 29 dias de férias em dobro
• Férias iniciando em 14/02/2022–30 dias de gozo — paga 30 dias de férias em dobro
• Férias iniciando depois 14/02/2022–30 dias de gozo — paga 30 dias de férias em dobro

O teste que deriva de tabela de decisão ocorre de modo que, se determinada combinação de dados for executada, o sistema comporta de uma forma e caso contrário, o sistema se comporta de outra maneira.

Tudo isso de acordo com a especificação que é onde se encontram os insumos para orientar o cenário de teste. Para criação do cenário a ser executado basta identificar as entradas ou condições e as saídas que são resultados do processamento dessas entradas.

Geralmente temos um valor booleano para a tomada de decisão, por exemplo, sendo um parâmetro no sistema marcado, o comportamento deve seguir uma linha de raciocínio e se estiver desmarcado, segue outra linha de raciocínio.

Além disso, existe uma marcação que pode ser visualizada pelo usuário e que internamente é uma decisão. Por exemplo, utilizando cores, como quando determinado documento for aberto, ficará com uma marcação cinza. Assim que for enviado para aprovação, ficará vermelho e quando for aprovado, ficará verde.

Nesse caso, o teste seguirá a verificação da seguinte forma: se estiver na etapa aprovada, não poderá ficar cinza ou vermelho e, assim, seguindo de forma sucessiva às demais verificações de cores do teste.

Existe ainda a possibilidade de usar técnicas baseadas na experiência, que vêm do conhecimento e a intuição do indivíduo em regras de negócios e tecnologia do produto.

Não só a técnica sistêmica deve ser considerada, mas também o conhecimento e testes intuitivos podem ser úteis para determinados cenários que não são facilmente identificados pelo processo formal.

Para escolher qual técnica usar, devem ser verificados vários ângulos como:

• o tipo de sistema,
• requisitos,
• fator de risco,
• objetivo do teste,
• documentação disponível,
• tempo para entrega,
• conhecimento do testador,
• custo,
• modelo do teste

E até mesmo um conhecimento prévio de como está o desenvolvimento do produto em relação a qualidade, se terá mais ou menos defeitos a serem encontrados.

É recomendado que no processo de teste haja uma estruturação de etapas para uma organização dos testes seguindo especificação, modelagem a ser executada, sequência de execução, especificação de procedimentos, automação e rastreabilidade.

Por mais que o processo de produção do software tenha sua evolução, o que é base para o teste continua da mesma forma.

São conceitos que um indivíduo terá em seu campo de visão para utilizar no momento de executar a tarefa de teste. O teste deve estar presente do início ao fim do ciclo de vida do software para a comodidade e sucesso do cliente.

Atualmente, a marca se destaca de acordo com a qualidade do produto oferecido no mercado, então faz-se mister oferecer um produto robusto que demonstra confiabilidade e retorno de valor ao cliente.

Documentos Base de Referência:

ISTQB. Certified Tester Syllabus Foundation Level. Disponível em: https://bstqb.org.br/b9/doc/syllabus_ctfl_3.1br.pdf. Acesso em: 24 abr. 2022.

BLOG DO LUIZ LADEIRA. INTRODUÇÃO A TESTE DE SOFTWARE. Disponível em: https://luizladeira.wordpress.com/tag/teste-de-software/. Acesso em: 24 abr. 2022.