Uma atividade essencial no desenvolvimento de todo e qualquer projeto é o planejamento. Um plano tem o papel semelhante ao de um ‘mapa’. Sem um mapa, um plano ou qualquer outra fonte de informação similar, você não conhecerá seus objetivos, nem onde quer chegar e jamais terá a certeza de ter alcançado sua meta.

O Teste de software é uma das atividades do processo de desenvolvimento de sistema de software, que visa executar um programa de modo sistemático com o objetivo de encontrar falhas. Perceba que isto requer verificação e validação de software. Nesse sentido, definir quando as atividades de verificação e validação iniciam e terminam, como os atributos de qualidade serão avaliados e como os releases do software serão controlados, são questões que devem ser acompanhadas ao longo do processo de software.

Basicamente, o Mapa de teste é uma forma de integralidade relacionada a um requisito (baseada em requisitos) ou aos critérios de design e implementação do código (baseada em códigos), como a verificação de casos de uso (baseada em requisitos) ou a execução de todas as linhas de código (baseada em códigos).

Complicou o entendimento? Vamos simplificar.

Mapa de cobertura de testes, Mapa essencial de testes, cobertura de testes, mapa de testes, temos vários nomes dados a este método de planejamento que, em síntese, é um meio utilizado para demonstrar em um formato mais ágil e de rápido entendimento, os prováveis testes que teremos, sendo eles baseados em uma história, requisito, design, código fonte, dentre outros.

Com o Mapa, podemos elencar de forma estrutural os elementos principais dos testes e suas variações.

Qualquer tarefa sistemática de teste baseia-se em, pelo menos, uma estratégia de cobertura de teste. Essa estratégia orienta o design de casos de teste declarando a finalidade geral do teste. A declaração da estratégia de cobertura pode ser tão simples quanto verificar todo o desempenho.

Quanto mais quebras houver em seu mapa maior será a cobertura de testes a ser atingida, tendo como retorno maior assertividade, mensuração de tempo e coleta de evidências. Vide exemplo abaixo:

Dada a História: Comprar um Produto via Cartão de Crédito.

  1. Cenário simples: Criar apenas o teste de nome “Validar Campos do Formulário”
    1. Teríamos apenas 1(um) teste para validar, porém ele não possui cobertura de todas as validações possíveis, ou mesmo que tais validações sejam colocadas em etapas dentro dos testes, sua mensuração e quantificação quanto ao tempo de execução e qualidade do teste seriam prejudicadas.
  2. Cenário Coberto: Criar uma lista de testes bem clara de seus objetivos, os quais teríamos para seus atributos as respectivas variações e validações:
    1. Validar Campos do Formulário – Validar preenchimento – Nome do titular do cartão
      1. Campo Obrigatório;
      2. Limite com 55 caracteres;
    2. Validar Campos do Formulário – Validar preenchimento -Número do cartão
      1. Campo Obrigatório;
      2. Limite com 55 caracteres;
    3. Dentre outros.
    4. Validar Campos do Formulário – Validar regras de negócio
      1. Realizar uma compra informando cartão de crédito válido;
      2. Realizar uma compra informando cartão de crédito inválido;
  • Realizar uma compra informando cartão de crédito com validade expirada;
  1. Realizar uma compra informando cartão de crédito com CVV incorreto;
  2. Dentre Outros

Neste formato de exemplo, conseguimos demonstrar a princípio 8(oito) testes possíveis, sendo 2(dois) para Preenchimento de campos e 6(seis) para regras de negócio.

O mapa de testes pode ser utilizado nas mais diversas frentes, sendo as principais e mais utilizadas: Usabilidade, Desempenho, Funcionalidade, Confiabilidade e Suportabilidade.

Importante ressaltar que:

  • Ao fazer uso a cobertura de testes alguns cuidados devem ser tomados, pois este meio quando usado de maneira incorreta acarreta, em uma falsa métrica de qualidade.
  • A cobertura de testes não cobre falhas no levantamento de requisitos e não consegue sinalizar possíveis erros de lógica de programação.
  • É uma técnica auxiliar, porém não é absoluta.

 

Fonte(s):

 

Leandro Damasceno – Gerente de Testes