Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Comunicacao HSL Wiki Comunicacao HSL Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Comunicacao HSL
  • Comunicacao HSL WikiComunicacao HSL Wiki
  • Wiki
  • qualidade

Last edited by Leonardo Vargas Soares Oct 20, 2021
Page history
This is an old version of this page. You can view the most recent version or browse the history.

qualidade

Home Escopo e Cronograma Processo Design/Mockups Configuração Arquitetura Código BD Qualidade Utilização Instruções AWS

Controle de Qualidade

Descrição

Esta seção contém todos a metodologia escolhida para realização dos testes do projeto.

Sumário

  • Controle de Qualidade
    • Descrição
    • Sumário
    • Testes
    • Passar teste
    • Falhar testes
    • Padrão de tasks

Testes

O nosso processo de QA (Quality Assurance) é realizado utilizando a ferramenta Trello, nela mapeamos as tarefas relacionadas à qualidade, que se resumem aos casos de teste descritos inspirados na técnica BDD (Behavior Driven Development). Desta forma conseguimos aproveitar toda a descrição de critérios de aceitação das USs (User Stories) também na execução de casos de teste, tornando nosso processo mais eficiente e fácil de ser colocado em prática.

Passar teste

Se determinado caso de teste foi coberto pelo desenvolvimento, então o caso de teste é marcado na checklist. Se todos os casos de teste passarem ou nenhum caso crítico falhar, a US é marcada com o label PASSOU.

Para qualquer aceite de merge requests, é necessário que todos os testes desenvolvidos tenham passado com sucesso. Caso contrário, não é possível aceitar o MR.

Falhar testes

Se o caso de teste não foi coberto pelo desenvolvimento, então o caso de teste não é marcado na checklist e a US é marcada com o label FALHOU.

Caso um dos testes falhe, é necessário que seja corrigido e verificado novamente para que nada esteja quebrado.

Padrão de tasks

Clone repository
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • codigo
  • configuracao
  • design_mockups
  • escopo
  • Home
  • instrucoes
  • instrucoesAws
  • processo
  • qualidade
  • utilizacao