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

qualidade · Changes

Page history
Update qualidade authored Sep 06, 2025 by Fernanda Ferreira de Mello's avatar Fernanda Ferreira de Mello
Hide whitespace changes
Inline Side-by-side
qualidade.md
View page @ 8b967d68
......@@ -9,17 +9,27 @@ Esta página centraliza informações sobre o processo de *Quality Assurance* do
- [Informações gerais](#informacoes-gerais)
- [Backend](#backend)
- [Frontend](#frontend)
## Informações gerais
TODO
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](https://junit.org/junit5/) e [Mockito](https://site.mockito.org/).
TODO
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](https://www.sonarsource.com). 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:
![image](uploads/4471f3f68fb30277603e98aee0f3787f/image.png)
### Sprint 1
......@@ -35,8 +45,4 @@ TODO
### Sprint 4
TODO
## Frontend
TODO
\ No newline at end of file
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