fernanda.mello| 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
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
Durante a Sprint 2, conseguimos atingir todos os critérios para que a Quality Gate do Sonar passasse. Ainda assim, alguns Merge Requests do Backend estavam sendo abertos e aprovados mesmo sem atingir a cobertura de ao menos 80% de testes unitários sobre o código novo.
Sprint 3
Ao final da Sprint 3, a Quality Gate do Sonar passou novamente. No entanto, repetiu-se as situações de Merge Requests serem abertos no repositório de Backend sem incluir testes unitários, o que indicou para o time que ainda não estamos abraçando o desenvolvimento de testes unitários como uma parte essencial do processo de desenvolvimento. Além disso, percebeu-se que alguns testes criados estavam fora do padrão, existindo alguns testes unitários repetidos e classes de teste responsáveis por validar comportamentos de classes diferentes.
Com isso, foi criada uma tarefa de débito técnico para a Sprint 4, cujo objetivo é: revisar os testes já existentes, aumentar a cobertura de testes unitários, e também reduzir a quantidade de issues apontadas pelo Sonar (code smells e bugs).
Sprint 4
TODO