| ... | ... | @@ -13,25 +13,25 @@ Esta seção contém todos a metodologia escolhida para realização dos testes |
|
|
|
- [Descrição](#descrição)
|
|
|
|
- [Sumário](#sumário)
|
|
|
|
- [Testes](#testes)
|
|
|
|
- [Passar teste](#passar-teste)
|
|
|
|
- [Falhar testes](#falhar-testes)
|
|
|
|
- [Passar Teste](#passar-teste)
|
|
|
|
- [Falhar Testes](#falhar-testes)
|
|
|
|
- [Padrão de tasks](#padrão-de-tasks)
|
|
|
|
|
|
|
|
## Testes
|
|
|
|
|
|
|
|
O nosso processo de **QA** (*Quality Assurance*) é realizado utilizando a ferramenta **Trello**, nela mapeamos as tarefas relacionadas à qualidade, que se resumem aos casos de teste descritos inspirados na técnica **BDD** (*Behavior Driven Development*). Desta forma conseguimos aproveitar toda a descrição de critérios de aceitação das USs (*User Stories*) também na execução de casos de teste, tornando nosso processo mais eficiente e fácil de ser colocado em prática.
|
|
|
|
|
|
|
|
## Passar teste
|
|
|
|
## Passar Teste
|
|
|
|
|
|
|
|
Se determinado caso de teste **foi coberto pelo desenvolvimento**, então o caso de teste é marcado na *checklist*. Se todos os casos de teste passarem ou nenhum caso crítico falhar, a US é marcada com o label `PASSOU`.
|
|
|
|
|
|
|
|
Para qualquer aceite de merge requests, é necessário que todos os testes desenvolvidos tenham passado com sucesso. Caso contrário, não é possível aceitar o MR.
|
|
|
|
|
|
|
|
## Falhar testes
|
|
|
|
## Falhar Testes
|
|
|
|
|
|
|
|
Se o caso de teste **não foi coberto pelo desenvolvimento**, então o caso de teste **não** é marcado na *checklist* e a US é marcada com o label `FALHOU`.
|
|
|
|
|
|
|
|
Caso um dos testes falhe, é necessário que seja corrigido e verificado novamente para que nada esteja quebrado.
|
|
|
|
|
|
|
|
## Padrão de tasks
|
|
|
|
## Padrão de Tasks
|
|
|
|
|
