Processos e tipos de Testes

De Wiki Expresso V3
Ir para: navegação, pesquisa

Conteúdo

Introdução

O processo de teste de software visa fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.

A qualidade de uma aplicação pode variar significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

De forma geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.

Essa seção tem por objetivo definir o escopo dos testes para o Expresso.

Tipos de Testes

Gestão de testes funcionais manuais(TestLink)
Testes funcionais automatizados(Jenkins/Selenium)
Testes unitários automatizados(Jenkink/TDD/PhpUnit)
Testes de serviços(Jenkins/Jmeter)
Testes de performance(Jenkins/Jmeter)
Testes de segurança 
Testes de qualidade de código

A comunidade de testes inicialmente abordará somente a gestão de testes funcionais. Posteriormente, com o amadurecimento expandiremos para as demais gestões.

Workflow dos testes no Sprint de Desenvolvimento

O ciclo de testes está integrado com o sprint de desenvolvimento. Cada ticket é testado individualmente pelos testers antes de ser integrado em uma versão do ExpressoBR.

A seguir é apresentado uma lista das ferramentas usadas, o modelo BPMN e a descrição do processo.

Ferramentas

  • Redmine - ferramenta de gestão de demandas
  • Gerrit - Revisão de código
  • Jenkins - Servidor de integração continua
  • VMs com infraestrutura do ExpressoBR - cyrus, ldap, postgres, etc

BPMN - Business Process Model and Notation

Teste integracao jenkins.png

Processo

O processo de teste segue as seguintes etapas:

  1. O desenvolvedor passa o ticket para o backlog dos testers.
  2. Um tester começa a tratar o ticket e muda o status do ticket no redmine.
  3. O tester start o job jenkins. Ele irá configurar uma VM com o branch master e o ticket que deve ser revisado.
  4. Com a VM configurada, a funcionalidade do ticket é testada.
    1. Se o ticket funcionou, ele é aprovado e segue para integração de uma versão e volta para o sprint do desenvolvimento.
    2. Se o ticket não funcionou, ele volta para o sprint do desenvolvimento para correção
  5. O gerrit, ferramenta de gestão de revisão de código, é atualizado.
  6. O redmine, ferramenta de gestão de demandas é atualizado.

Exemplo prático

  1. O desenvolvedor João termina de realizar a implementação. Ele repassa o ticket #666 para o backlog do departamento de testes.
  2. Rafael esta sem tarefa. Ele checa o backlog e vê o teste #666 para ser revisado. Ele se apropria do ticket.
  3. Rafael acessa o Gerrit e pega o id do commit referente ao ticket #666.
  4. Rafael acessa o CI Jenkins e coloca como parâmetro o id do commit pego no passo anterior. Depois disse ele começa a criação da VM
  5. O jenkins cria a VM com base no branch master e aplica o commit do ticket #666
  6. Rafael revisa a implementação do ticket #666.
    1. Se tudo estiver ok, Rafael retorna o ticket para o desenvolvimento integrar e atualiza o status no Gerrit e Redmine
    2. Se ocorrer uma falha o ticket volta para o desenvolvedor corrigir.

Workflow dos testes de aceitação de uma versão (Release Candidate)

Para uma release nova, terminada em RC01, todos os testes de aceitação do testlink devem ser executados. Importante ressaltar que os testes devem ser todos repetidos para cada plataforma suportada (e.g. Firefox, IE, Chrome, etc).

Ferramentas

  • Redmine - ferramenta de gestão de demandas
  • Testlink - ferramenta para especificação e execução de testes de aceitação.

BPMN - Business Process Model and Notation

Teste release candidate.png

Processo

  1. Depto de desenvolvimento repassa o ticket da Relase Candidate para o dept de Testes
  2. Revisor de testes cria o plano de testes no testlink
    • Para cada plataforma (e.g. Firefox, Chrome, etc) todos os testes de aceitação devem ser feitos
    • Atualmente o testlink possui 415 testes de aceitação no total.
    • Eles devem ser repetidos para três plataformas: Firefox, IE9, Chrome
    • Então temos 3 testadores fazendo 415 testes cada. Total de 1245 testes a serem feitos
  3. Revisor estima tempo adequado para a execução de testes
  4. Testers começam os testes.
  5. Revisor revisa tickets individuais no Redmine. Estes são defeitos ou implementações novas na versão. Eles devem ser verificados individualmente.
  6. Testers terminam a execução
  7. Revisor reavalia o resultado dos testes do Testlink e os tickets individuais do Redmine e gera um relatório para a chefia do depto de Testes

Exemplo prático

  1. Eva, a chefia do desenvolvimento, libera uma RC01 para o depto de testes
  2. Adão, a chefia do depto de testes recebe o ticket da RC01 e determina que o revisor será Noé
  3. Noé, o revisor. cria um novo plano de testes no testlink
  4. Noé cria uma baseline nova - normalmente no formado ExpressoBr.YYYYMMDD.RC01
  5. Noé determina quais plataforma serão testadas (IE9, Firefox, Chrome)
    1. Noé atribui para cada plataforma todos os testes de aceitação
    2. Noé atribui uma plataforma para um testador
  6. Os testadores (Enoch, Samuel, Gildeão), executam todos os testes de aceitação para sua plataforma
  7. Noé analisa o relatório de erros feitos pelos testadores (Enoch, Samuel, Gildeão)
  8. Noé analisa os defeitos especificos da versão que constam no ticket do Redmine
  9. Noé cadastra no redmine os novos defeitos encontrados
  10. Noé, o revisor apresenta um sumário dos erros encontrados para a chefia Eva
  11. Adão, a chefia do dept de testes libera a versão para produção ou rejeita de volta para o desenvolvimento
Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Ferramentas