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

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

User Stories

Fluxo inicial de seleções

US Descrição
US 01 Eu como usuário gostaria de identificar o hospital aonde trabalho para que possa recuperar informações específicas do hospital
US 02 Eu como usuário gostaria de selecionar a função que desempenho no hospital para que tenha acesso as atividades da minha posição
US 03 Eu como usuário gostaria de poder ter a minha função salva no app para que não precise selecionar sempre que inicio o app
US 04 Eu como usuário gostaria de selecionar uma tecnologia em que executo minhas atividades para o poder ter acesso as atividades desta tecnologia
US 05 Eu como usuário gostaria de poder ter uma tecnologia salva no app para que não precise selecionar sempre que inicio o app
US 06 Eu como usuário gostaria de cadastrar um paciente que vai iniciar um atendimento para que o usuário possa identificar as atividades realizadas nesse paciente
US 07 Eu como usuário gostaria de que se o paciente já foi cadastrado quero poder recuperar apartir do id o status de atendimento para que possa iniciar a contagem de uma nova atividade

Fluxo de coleta de tempos das atividades

US Descrição
US 09 Eu como usuário tendo acesso as atividades a serem realizadas quero poder selecionar uma atividade para iniciar a contagem de tempo
US 10 Eu como usuário durante a contagem de tempo gostaria de poder pausar a contagem, retomar, finalizar e pular para que consiga contar o tempo executado com precisão
US 11 Eu como usuário devo ter a possibilidade de executar mais de uma atividade simultaneas para que eu conte o tempo de todas as tarefas que faço no dia

Fluxo de exportação de Dados

US Descrição
US 12 Eu como usuário gostaria de ter acesso a um relatório simplificado dos tempos de atividades por função e por atividade para ter como forma de engajar a utilização do app
US 13 Eu como pesquisador devo ter a possibilidade de exportar um relatório no formato csv com medias, mediana e ICQ por atividade e função para que possa realizar análises dos dados

Requisitos não funcionais

Exemplos de fluxos 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

Exemplo.xlsx

Teste funcional do App

Os casos de teste do App iniciaram na ferramenta Monday e agora estão na ferramenta Airtable.

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?

  • Você já deve ter recebido um link no e-mail
  • Senão, fala no slack o teu e-mail que te adiciono (provável que precise fazer um cadastro no Airtable)

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.

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
  • Lucas Castro: 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 Airtable 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
  • Resultado do teste funcional da sprint 1: sprint1-testeFuncional.pdf
  • Resultado do teste funcional da sprint 2: DTool__Sprint_2-TesteFuncional-_Airtable.pdf
  • Resultado do teste funcional da sprint 3: DTool__Sprint_3_-_Airtable-Resultado.pdf
  • Resultado do teste funcional da sprint 4: DTool__Sprint_4_-_Airtable-Resultado.pdf
Clone repository
  • arquitetura
  • banco_dados
  • configuracao
  • docs usuario
  • gerenciamento_projeto
  • guia_desenvolvimento_backend
  • Home
  • instalacao
  • materiais_estudo
  • mockups
  • requisitos
  • reunioes
  • sprints
  • time