Política para registro de testes¶

Nessa política estão as diretrizes para realização dos testes de cards dos projetos Almaviva. Ambas se aplicam a qualquer ambiente, sejam eles DEV, HOM ou PROD.

É importante salientar que a não realização dos processos e itens contidos neste documento, aplicará em perda de qualidade e apontamentos em auditoria da Almaviva.

Criação de plano de testes¶

É importante que os testers/ QAs Almaviva se comprometam e tenham a responsabilidade de criar planos de testes itens que serão testados. Isso se faz importante, pois sem um planejamento adequado, podemos correr o risco de não criar estratégias adequadas na hora de realizar as validações, e com isso trazendo riscos ao ciclo de desenvolvimento que está em andamento. O plano de testes visa se antecipar aos possíveis problemas ou pendências no momento de realização dos testes, exemplo: Massa de dados, Disponibilidade de Ambiente e Recursos, Ferramentas e etc. O que o Syllabus BSTQB informa sobre o plano de testes:

Documenta os meios e o cronograma para atingir os objetivos do teste;
Ajuda a garantir que as atividades de teste realizadas atenderão aos critérios estabelecidos;
Serve como um meio de comunicação com os membros da equipe e outros stakeholders;
Demonstra que os testes seguirão a política e a estratégia de testes existentes (ou explica por que os testes se desviarão delas).

Cenários de Testes¶

Cenários de testes é forma de documentar e organizar como o processo de testes será conduzido, tanto o antes, como o após os testes. A criação dos cenários é o que precisa ser testado, e nessa etapa são criadas as descrições de como aquele testes deve ser conduzido. Após a realização dos testes de acordo é necessário evidenciar o trabalho realizado, afim de deixar registrado todas as informações coletadas nos testes. Deve ser adotado o seguinte formato para escrita baseada no BDD:

BDD	BDD Escrita
DADO	Que sou um usuário XPTO
QUANDO	Insiro meu cartão
ENTÃO	Acesso minha conta via Internet Banking e visualizo meu saldo atual em tela

Ou mais detalhado utilizando o "E"

BDD	BDD Escrita
DADO	Que sou um usuário XPTO
E	Necessito acessar o saldo de minha conta corrente Online
QUANDO	Insiro meu cartão
ENTÃO	Acesso minha conta via Internet Banking e visualizo meu saldo atual em tela

Evidências de testes¶

As evidências são informações fundamentais que não podem deixar de ser registradas após a realização dos testes. É de extrema importância que após a execução de um cenário de teste, que a evidências seja registrada e atrelada ao seu respectivo cenário/critério. Isso para que seja possível rastrear que todos os cenários/critérios foram mapeados, com isso garantindo a qualidade do produto e transparência do trabalho. Dando continuidade do exemplo passado no item anterior, as evidências seguiriam da seguinte forma:

Tarefa de Cenário de Teste¶

O time deverá estruturar os testes utilizando a Tarefa do Gitlab. Cada tarefa deve representar um único cenário. Para isso, os seguintes campos deverão ser preenchidos:

Título do cenário: O título deve ser curto, de fácil entendimento e deve ser precedido pelo título do card (Obrigatório).
- Exemplos:
  
  "CL18 - Cadastrar item de compra - Cenário 1: Validar status da compra"
  
  "CL18 - Cadastrar item de compra - Validar status da compra";
Status: A tarefa inicia com o estado "Open" (Obrigatório);
Assignee: Analista de testes responsável (Obrigatório);
Labels: A label "TESTES" deverá ser adicionada. (Obrigatório)

Além desta, pode-se inserir quaisquer outras labels que possam ajudar na identificação ou gestão do item;

Dates: Datas de abertura e fechamento (item desejado mas não obrigatório);
Milestone: Ciclo o qual o card "pai" foi relacionada e que a atividade será executada (Obrigatório);

Descrição:

Tipos de Testes

A seção "Tipos de Testes" pode ser incluída dentro da estrutura da HU ou da tarefa de teste, conforme decidido pelo time. Se optar por incluí-la na estrutura da HU, este item pode ser removido da tarefa de testes. O detalhamento de como utilizar cada tipo de teste consta no final do conteúdo desta política.

Cenário¶

DADO que sou [descrever o tipo de usuário do sistema]

E [descrever demais necessidades aplicadas nesse cenário]

QUANDO [descrever o momento ou a ação que será executada]

ENTÃO [descrever o resultado esperado para a ação]

Detalhamento dos tipos de testes¶

Teste Funcional: Avaliar o funcionamento de um componente ou sistema, verificando se as funções desempenham o comportamento esperado. O principal objetivo desse teste é verificar a correção ou a adequação funcional.

Teste Regressivo: Confirmar que nenhum comportamento adverso foi adicionado ao sistema após uma alteração, inclusão ou correção realizada, no qual aquele componente ou sistema já tenha sido testado anteriormente. O comportamento inesperado pode afetar o mesmo componente ajustado, outros não ajustados ou mesmo sistemas conectados que possuem dependência. É indicado, antes de realizar testes de regressão, avaliar a análise de impacto do item ajustado, para evitar testes desnecessários. Esse tipo de teste é muito indicado para automação, uma vez que são repetidos diversas vezes a cada nova versão. É indicado possuir esse tipo de teste integrado na esteira CI, assim como replicá-lo para outros níveis de testes, como por exemplo, componentes, sistema e aceite.

Teste de Integração ou Sistema: Validar interfaces do sistema com outros sistemas e serviços internos e externos. É importante que o ambiente de teste (desenvolvimento) mantenha a fidelidade (semelhança) com o ambiente operacional (produção).

Teste de Carga ou Desempenho: Validar o comportamento e o processo de carga de dados, assim como o desempenho de envio e resposta nas transações realizadas pelo sistema.

Teste de Aceitação: Validar os critérios de aceite elaborados na etapa de requisitos funcionais. Eles são baseados nas regras de negócio especificadas pelo usuário e podem ser validados pelo usuário final, Analista de negócio / requisito ou mesmo pelo Analista de Testes, quando este é designado em contrato. Normalmente, essa validação é realizada em UAT (User Acceptance Testing), pois é mais focada no comportamento do usuário.

Teste de Segurança: Validar as características de segurança do sistema relacionadas à qualidade de segurança do software. Identificar possíveis vulnerabilidades que possam permitir que o software seja hackeado ou invadido. Normalmente, o teste de segurança é realizado com o apoio de outros softwares preparados para esse tipo de teste. Esse tipo de teste é classificado na ISO/IEC 25010 como teste não funcional.

Template: Tarefa de Cenário de Teste

Exemplo: Tarefa de Cenário de Teste

IMPORTANTE: Ver Política para Registro de Bugs, Erros ou Defeitos

Referências¶

https://bstqb.org.br/b9/ctfl

syllabus_ctfl_4.0br.pdf