| ... | ... | @@ -17,17 +17,26 @@ Esta seção contém todos a metodologia escolhida para realização dos testes |
|
|
|
- [Falhar testes](#falhar-testes)
|
|
|
|
- [Padrão de tasks](#padrão-de-tasks)
|
|
|
|
|
|
|
|
## índice de Qualidade
|
|
|
|
|
|
|
|
|
|
|
|
## Testes
|
|
|
|
As features implementadas seguem dois tipos de testes:
|
|
|
|
* Teste Unitário - Feito pelo desenvolvedor que implementou a task durante a etapa final de desenvolvimento da mesma.
|
|
|
|
|
|
|
|
TBD
|
|
|
|
* Teste de integração - Feito por um colega, normalmente antes de realizar a publicação da implementação.
|
|
|
|
|
|
|
|
## Passar teste
|
|
|
|
|
|
|
|
TBD
|
|
|
|
O time utilizou quadros no site Trello para refletir a situação de determinada tarefa: DESENVOLVIMENTO, PRONTO PARA PUBLICAR, PUBLICADO e PRONTO.
|
|
|
|
|
|
|
|
Implementações em DESENVOLVIMENTO que foram aprovadas no teste de integração serão movidas para PRONTO PARA PUBLICAR.
|
|
|
|
|
|
|
|
O colega responsável irá mover implementações aprovadas no teste de integração de PUBLICADO para PRONTO.
|
|
|
|
|
|
|
|
## Falhar testes
|
|
|
|
|
|
|
|
TBD
|
|
|
|
Falhas encontradas durante o desenvolvimento devem ser corrigidas antes da solicitação de merge. Para os testes de integração, dependendo da etapa da sprint em que a falha foi identificada, esta pode ser reportada ao autor da tarefa ou, para o caso de não ser uma falha crítica, entrar em débito técnico para a próxima sprint.
|
|
|
|
|
|
|
|
## Padrão de tasks
|
|
|
|
|
| ... | ... | |
