| ... | ... | @@ -11,7 +11,7 @@ |
|
|
|
- [Prática](#prática)
|
|
|
|
|
|
|
|
## Objetivo
|
|
|
|
O objetivo do controle de qualidade neste projeto é garantir que as funcionalidades descritas pelas User Stories, sejam implementadas de forma a tratar todos os possíveis cenários e que o código produzido para isto, siga a arquitetura descrita em [Arquitetura](https://tools.ages.pucrs.br/denuncia-a-violencia/denuncia-a-violencia-wiki/-/wikis/arquitetura) (usar todas as camadas, respeitando a sua responsabilidade).
|
|
|
|
O objetivo do controle de qualidade, neste projeto, é garantir que as funcionalidades descritas pelas User Stories, sejam implementadas de forma que tratem todos os possíveis cenários e que o código produzido para isto, siga a arquitetura descrita em [Arquitetura](https://tools.ages.pucrs.br/denuncia-a-violencia/denuncia-a-violencia-wiki/-/wikis/arquitetura) (usar todas as camadas, respeitando as suas respectivas responsabilidades).
|
|
|
|
|
|
|
|
## Prática
|
|
|
|
1. Um dos responsáveis pela US cria uma branch para desenvolver a funcionalidade;
|
| ... | ... | @@ -19,4 +19,7 @@ O objetivo do controle de qualidade neste projeto é garantir que as funcionalid |
|
|
|
3. Um AGES III ou AGES IV, que não tenha participado da task, revisa o código para ver se a arquitetura e padrões estão sendo seguidos e executa o código de maneira local para testar a funcionalidade;
|
|
|
|
4. Se tudo estiver correto, aprova o merge request e realiza o merge. Se não, indica aonde há a necessidade de correção e aguarda a correção ser feita para repetir o passo 3.
|
|
|
|
|
|
|
|
## Backend
|
|
|
|
Para testar o comportamento das rotas implementadas no backend, também utilizamos a ferramenta Postman, para simular requests e checar seus resultados. Foi criado um repositório compartilhado na ferramenta, para que todos tivessem acesso aos testes de cada rota.
|
|
|
|
|
|
|
|
|
