Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Wiki Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Sem Barreiras
  • WikiWiki
  • Wiki
  • qualidade

Last edited by fernanda.mello Jul 11, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

qualidade

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
  • Backend
  • Frontend

Informações gerais

Antes da entrega das histórias de usuário ao final de cada Sprint, estas histórias de usuário 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, inicialmente planejou-se integrar o quadro Kanban da ferramenta Azure DevOps com o Azure Test Plans, para descrever os cenários de teste e acompanhar os resultados de sua execução. No entanto, não foi possível realizar esta integração por esta ser uma ferramenta paga.

Assim, estabeleceu-se a estratégia de, na última semana de cada Sprint do projeto, gerar uma versão do aplicativo nas terças-feiras (um dia antes do freeze de código) com o que foi desenvolvido até então e realizar testes de todas as funcionalidades. Os eventuais bugs encontrados durante os testes são registrados em um canal de comunicação voltado para bugs na ferramenta 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.

Backend

Para cada tarefa de Backend executada, deverão ser realizados testes unitários utilizando as ferramentas JUnit 5 e Mockito. Não será utilizada nenhuma ferramenta para avaliação da cobertura de testes do projeto, então não será necessário ter uma alta cobertura, mas é preciso ao menos cobrir os cenários de teste mais importantes.

Frontend

Para as tarefas do Frontend que forem executadas, deverá ser disponibilizado ao menos um print dos estados de componente/tela que está sendo desenvolvido. Além disso, considerando questões de acessibilidade, testar as funcionalidades desenvolvidas utilizando o talkback no Android ou no emulador.

Clone repository

SemBarreiras-Logo__1_

Sem Barreiras

Home

Escopo

Processo

Design/Mockups

Configuração

Arquitetura

Gerência

Banco de Dados

Qualidade

Frontend

Backend