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:

Sprint 1

Durante a Sprint 1, alguns Merge Requests foram aprovados mesmo com a análise do Sonar falhando devido a baixa cobertura de teste, pois a entrega de algumas tarefas atrasou e foi necessário disponibilizá-las o mais rápido possível no ambiente de desenvolvimento para viabilizar a integração das telas do Frontend com a API. Diante disso, o relatório do Sonar ao final da Sprint foi o da imagem abaixo.

Devido a este ponto, foi criada uma tarefa de débito técnico para aumentar a cobertura de testes unitários que será desenvolvida na primeira semana da Sprint 2.

Sprint 2

TODO

Sprint 3

TODO

Sprint 4

TODO