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
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dTool
  • wikiwiki
  • Wiki
  • requisitos

Last edited by Bianca Camargo Machado Jun 24, 2020
Page history
This is an old version of this page. You can view the most recent version or browse the history.

requisitos

Home Arquitetura Banco de Dados Configuração Gerenciamento do Projeto Instalação Materiais de Estudo Mockups Requisitos Reuniões Sprints

Acesso rápido:

  • Material
  • Próximos artefatos

Página dos Requisitos do Projeto

Exemplos e material de apoio

Considerações dos clientes da entrega da Sprint 0 - Considerações.docx

matrizes_e_fluxo_exemplo_só_fluxo.xlsx

fluxo_avc_microcusteio.xlsx

Teste funcional do App

Os casos de teste do App estão na ferramenta Monday.

O que é isso?

Como falamos antes, na API serão feitos testes unitários para certificar que as funcionalidades estão ok e estes testes unitários serão escritos por quem estiver responsável pela task e validado no code-review, então: sempre que uma alteração na API for feita é um critério de aceitação que esteja passando nestes testes unitários que vão ir sendo incrementados. Já, pro App, o que agrega mais valor com o tempo que temos pra desenvolver, são os testes funcionais, que basicamente validam se o que foi desenvolvido está de acordo com os requisitos. E para essa validação precisamos ter com o que comparar para validar = casos de teste. Nesses casos de teste estão documentados os comportamentos para User Stories que definimos e que estão no nosso Trello.

O que faço com isso?

Quando estiver desenvolvendo sua tarefa, vá na ferramenta e verifique se o que você está desenvolvendo possibilita que as situações documentadas aconteçam como esperado. Estes casos de teste podem/devem funcionar como um guia para você, sobre qual objetivo da tarefa (em conjunto com as outras documentações). E também, no final da sprint, antes da entrega, vamos pedir para que algumas pessoas testem o aplicativo e documente em que estado está cada caso de teste, no nosso caso pode ser: Blocked, Failed, Passed ou N/A. Como vocês podem imaginar, se todos os casos de teste de uma US estiverem marcados como Passed , a User Story alcançou todos os requisitos funcionais definidos até então (✔).

Como acesso a ferramenta?

  • Se você tiver o e-mail @acad.pucrs.br (alunos mais recentes não têm), é só acessar esse link e fazer login com esse email: https://dtool.monday.com/users/sign_up?invitationId=9623600591619738000
  • Senão, fala no slack o teu e-mail que te adiciono (provável que precise fazer um cadastro no Monday)
  • A ferramenta tem plataforma mobile e web, pode usar qualquer uma.

Status do teste

blocked => Tem dependência em outra funcionalidade para que seja possível testar este caso.

failed => Testado e não se comporta como especificado no caso de teste.

passed => Testado e se comporta como especificado no caso de teste;

na => Não é necessário testar, não se aplica à situação.

Funcionamento básico da ferramenta Slide1

Organização para a Sprint 1:

Divisão pra execução dos testes funcionais:

  • Bianca Camargo: US 04
  • Camila: US 01
  • Igor Brehm: US 05
  • Jessica Manoel: US 03
  • Rafael Araujo: US 01

Obs.:

  • Nem todo o código das USs foram entregues/estão na develop ainda, nestes casos acompanhe a sua respectiva US até o final da noite de domingo (12/04), se não for entregue até lá, marcar como Blocked, Failed ou N/A (dependendo da situação)
  • Se algum teste não passar (Blocked, Failed ou N/A), descreva o porque nos updates do caso de uso em questão
  • Realize, no mínimo, os testes descritos no Monday para cada US
  • Atualize o Test Status do casos de uso na ferramenta
  • Dúvidas/problemas sobre os testes funcionais devem ser discutidos no canal #teste-funcional
  • Ao finalizar seus testes, avise no canal #teste-funcional
  • Ao finalizar seus teste, atualize o card correspondente no trello (marcando no checklist que o teste funcional foi feito) e adicione um print do Test status dos casos de teste relacionados
  • O quanto antes o teste for realizado, melhor, pois maiores são as chances de possíveis ajustes de problemas encontrados até a entrega

[ANEXAR FOTO DO RESULTADO DOS TESTES FUNIONAIS, DEPOIS DE EXECUTADOS]

Próximos artefatos

Aqui devem ser citados e apresentados os USER STORIES, Diagrama dos Casos de Uso e todas as informações importantes sobre os Requisitos levantados pelos Stakeholders

  • Deve possuir as Imagens dos Use Cases
  • Deve possuir a Tabela dos User Stories
  • Tudo mais que precisa dos Requisitos
Clone repository
  • arquitetura
  • banco_dados
  • configuracao
  • docs usuario
  • gerenciamento_projeto
  • guia_desenvolvimento_backend
  • Home
  • instalacao
  • materiais_estudo
  • mockups
  • requisitos
  • reunioes
  • sprints
  • time