Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Point-Tills-Wiki Point-Tills-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
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Point Tils um aplicativo para interpretes de Lingua Brasileira de Sinais
  • Point-Tills-WikiPoint-Tills-Wiki
  • Wiki
  • qualidade

Last edited by Fernanda Ferreira de Mello Sep 14, 2025
Page history
This is an old version of this page. You can view the most recent version or browse the history.

qualidade

Home Escopo Processo Design/Mockups Configuração Arquitetura Gerência BD Qualidade Frontend Backend

Qualidade

Esta página centraliza informações sobre o processo de Quality Assurance do projeto.

Sumário

  • Informações gerais
  • Backend

Informações gerais

Antes da entrega das histórias de usuário ao final de cada Sprint, estas histórias devem ser testadas para garantir que estão tendo o comportamento esperado e, caso não estejam, corrigir estes problemas antes da entrega. Para isso, estabeleceu-se a estratégia de, durante o período de code freeze (quartas-feiras anteriores às reuniões com os stakeholders), gerar uma versão do aplicativo com o que foi desenvolvido até então e realizar testes de todas as funcionalidades ponta a ponta nos 2 dias que antecedem a entregas. Os eventuais bugs encontrados durante os testes devem ser registrados nos canais de Frontend e Backend do servidor do Discord.

Toda a equipe deve participar deste processo e isso possibilita que defeitos no aplicativo sejam identificados e, no caso daqueles mais simples, possam ser corrigidos em tempo hábil antes da entrega da Sprint.

Iteração Code Freeze
Sprint 1 10/09
Sprint 2 01/10
Sprint 3 22/10
Sprint 4 12/11

Backend

Para cada tarefa de Backend executada, deverão ser realizados testes unitários utilizando as ferramentas JUnit 5 e Mockito.

A fim de garantir que a cobertura de testes unitários esteja adequada, além de garantir a qualidade do projeto através da avaliação de vulnerabilidades de segurança, code smells e duplicação de código, optou-se por utilizar também a ferramenta Sonar Qube. Para isso, para cada Merge Request aberto no repositório de Backend, considera-se a Quality Gate Sonar way, de modo que o código precisa cumprir os critérios abaixo para que seja disponibilizado nos ambientes de desenvolvimento e de produção:

Critérios sobre novo código da Quality Gate do Sonar

Sprint 1

Relatório do Sonar ao final da Sprint 1

Sprint 2

TODO

Sprint 3

TODO

Sprint 4

TODO

Clone repository

Logo-Dark_Blue

Point Tils


Home

Arquitetura

Backend

Banco de Dados

Configuração

Design/Mockups

Escopo

Frontend

Gerência

Processo

Qualidade


Sprint 0

Sprint 1

Sprint 2

Sprint 3

Sprint 4