|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência](gp)|[Time](time)|[Padronização](padronizacao)|[Git Workflow](git)|[Qualidade](qualidade)|
|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência](gp)|[Time](time)|[Padronização](padronizacao)|[Git Workflow](git)|[Qualidade](qualidade)|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
# Controle e garantia de qualidade
|
|
|
|
|
|
|
|
_Acesso rápido:_
|
|
|
|
- [Descrição](#descrição)
|
|
|
|
- [Como funciona na prática?](#como-funciona-na-pratica)
|
|
|
|
- [Ajustes sugeridos e realizados](#ajustes-sugeridos-e-realizados)
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
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 utilizando a 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.
|
|
|
|
|
|
|
|
## Como funciona na prática?
|
|
|
|
|
|
|
|
Ao final de cada Sprint, com a aplicação em sua versão final, utilizamos a coluna *Test [Sprint <número>]* do Trello para colocar os cards que serão utilizados para a execução dos testes funcionais. Cada card representa uma US e cada item do *checklist* é um caso de teste.
|
|
|
|
|
|
|
|
Se algum caso de teste não passar, isto deve ser descrito nos comentários e em caso de tempo para resolver a pendência, este item é direcionado para ser resolvido antes da entrega. Caso não tenhamos tempo hábil, dependendo da criticidade, será incluído como débito técnico para a próxima Sprint e a US considerada como pronta ou incluído como débito técnico para a próxima Sprint e US considerada não entregue.
|
|
|
|
|
|
|
|
## Passar nos casos de teste
|
|
|
|
|
|
|
|
Se o 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`:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Falhar nos casos de teste
|
|
|
|
|
|
|
|
|
|
|
|
#### Coluna de testes para a Sprint 1
|
|
|
|
|
|
|
|
<div align="center">
|
|
|
|
<img src="resources/tests.gif" height="400">
|
|
|
|
</div>
|
|
|
|
|
|
|
|
#### Quem executa os casos de teste?
|
|
|
|
|
|
|
|
TBD |
|
|
|
\ No newline at end of file |
