09‐ User Story's
DOR
- Especificações dos campos (id, nome, fator, offset, unidade, etc.) estão detalhadas.
- O design da interface foi aprovado e pode ser encontrado no Figma.
- Documentação de integração com o backend está disponível no Swagger.
Critérios de Aceitação
- Deve ser possível cadastrar parâmetros com campos obrigatórios: id, nome, fator, nome_json, descricao, categoria_id, criado e alterado.
- A interface deve exibir mensagens de validação para campos obrigatórios não preenchidos.
- Os parâmetros cadastrados devem ser exibidos imediatamente em uma tabela para consulta.
- Deve ser possível editar e excluir parâmetros já cadastrados.
- Deve haver tratamento de erros.
DOD
- Interface de cadastro funcional e responsiva.
- Dados validados e enviados corretamente para o backend.
- Testes unitários garantem a funcionalidade.
- O cadastro aparece corretamente na listagem de parâmetros.
- Documentação do código foi atualizada.
- Testes de aceitação realizados com sucesso.
DOR
- API para listagem de parâmetros está disponível no Swagger.
- Design da tela de listagem aprovado, disponível no Figma.
- Casos de uso e critérios de aceitação definidos.
Critérios de Aceitação
- A interface deve listar todos os parâmetros cadastrados, com detalhes como nome, unidade e fator.
- Os parâmetros listados devem ser organizados em ordem alfabética ou por outra métrica definida.
- Deve haver um mecanismo de busca ou filtragem para facilitar a localização de parâmetros específicos.
DOD
- Tela lista os parâmetros corretamente.
- Dados são carregados de forma dinâmica do backend.
- Testes unitários cobrem carregamento e exibição.
- Implementado feedback para erros de carregamento.
- Testes de aceitação confirmam a funcionalidade.
DOR
- Campos que podem ser alterados foram especificados.
- API de atualização no backend foi documentada no Swagger.
- Design da interface de edição aprovado, disponível no Figma.
Critérios de Aceitação
- Os parâmetros existentes devem ser editáveis diretamente pela interface de gerenciamento.
- Após a alteração, os dados atualizados devem ser refletidos imediatamente na listagem.
DOD
- Alterações podem ser feitas e salvas com sucesso.
- Testes unitários garantem validações e funcionamento correto.
- Logs de alterações são registrados no sistema.
- Testes de aceitação validados com diferentes cenários.
DOR
- API de atualização no backend foi documentada no Swagger.
- Design da interface de edição aprovado, disponível no Figma.
- Critérios de exclusão definidos (e.g., parâmetros não vinculados a dados históricos).
Critérios de Aceitação
- Deve ser possível excluir parâmetros da interface.
- Mensagens de confirmação de exclusão devem ser exibidas.
- Parâmetros deletados não devem ser listados após a exclusão.
- A interface deve exibir um feedback de erro caso o parâmetro não possa ser excluído.
DOD
- Parâmetros são excluídos corretamente da listagem.
- Testes unitários validam a lógica de exclusão.
- Testes de aceitação realizados para garantir que as exclusões sejam refletidas no sistema.
DOR
- Campos de entrada para o cadastro foram especificados (nome, localização, etc.).
- API do backend pronta para receber os dados, está documentada no Swagger.
- Design da interface de cadastro aprovado, disponível no Figma.
Critérios de Aceitação
- Para cadastrar estações, os campos obrigatórios devem estar preenchidos: id, nome, endereço, status.
- Estações recém-cadastradas devem ser exibidas na lista na interface.
- Deve haver validação para evitar duplicação de estações.
DOD
- Estação cadastrada é exibida corretamente na listagem.
- Validações aplicadas e testadas com sucesso.
- Testes unitários para validações e interações de interface implementados.
- Testes de aceitação realizados.
DOR
- API de listagem de estações disponível no Swagger.
- Design da interface estações aprovado, disponível no Figma.
Critérios de Aceitação
- Todas as estações cadastradas devem ser listadas na interface com informações detalhadas, como localização, ativo, nome, id e parâmetros.
- Deve haver opções de busca e filtros para encontrar estações por nome, localização, id ou status.
DOD
- Listagem de estações funcional e responsiva.
- Feedback implementado para casos de erro.
- Testes unitários cobrem carregamento de dados e exibição.
- Testes de aceitação validaram o acesso às estações.
DOR
- API para atualização no backend está documentada no Swagger.
- Design da interface de alteração de estações aprovado, disponível no Figma.
Critérios de Aceitação
- Deve ser possível editar todas as informações da estação, exceto o id.
- As alterações devem ser imediatamente refletidas no sistema após a confirmação.
DOD
- Alterações são persistidas e refletidas na listagem.
- Testes unitários e integração garantem o funcionamento.
- Documentação atualizada para o recurso.
DOR
- API para deletar as estações no backend está documentada no Swagger.
- Design da interface de alteração de estações, e do pop-up aprovados, disponível no Figma.
Critérios de Aceitação
- Estações podem ser inativadas da interface de gestão.
- Mensagens de confirmação devem ser exibidas antes da exclusão.
- Estações removidas não devem ser listadas após a exclusão.
- Caso a estação tenha dados vinculados que impossibilitem a exclusão, deve ser exibida uma mensagem de erro.
DOD
- Estações são removidas corretamente da listagem.
- Testes unitários validam a lógica de exclusão.
- Testes de aceitação realizados para garantir que as exclusões sejam refletidas no sistema.
DOR
- Campos necessários para cadastro (nome, email e senha) foram definidos.
- API para criação de usuários documentada e funcional no Swagger.
- Design da interface de cadastro aprovado no Figma.
Critérios de Aceitação
- Campos obrigatórios: nome, email, senha.
- Validação para garantir que o email não seja duplicado no sistema.
- Email deve ter a estrutura válida.
DOD
- Usuário pode ser cadastrado e listado na aplicação.
- Validações de campos obrigatórios e senha implementadas.
- Testes unitários cobrem o fluxo de cadastro.
- Erros de cadastro são tratados e exibidos ao usuário.
- Testes de aceitação realizados.
DOR
- API para listagem de usuários está documentada e funcional no Swagger.
- O design da interface de listagem foi aprovado no Figma.
- Casos de uso e critérios de aceitação foram definidos.
Critérios de Aceitação
- Todos os usuários cadastrados devem ser listados com informações como nome, email e data de criação.
- Deve ser possível filtrar ou buscar usuários pelo nome ou email.
- A listagem deve ser paginada para facilitar a navegação.
DOD
- Listagem de usuários funcional e paginada.
- Busca e filtros implementados corretamente.
- Feedback de erro implementado em caso de falha ao carregar os dados.
- Testes unitários cobrem listagem, busca e filtros.
- Testes de aceitação realizados com sucesso.
DOR
- API para atualização de usuários documentada e funcional no Swagger.
- Design da interface de edição aprovado no Figma.
Critérios de Aceitação
- Deve ser possível editar os dados de um usuário, exceto o ID.
- Validações devem ser aplicadas, como email duplicado ou formato inválido.
- As alterações devem ser refletidas imediatamente na interface.
DOD
- Alterações realizadas com sucesso e refletidas na listagem.
- Validações de dados testadas e funcionando corretamente.
- Testes unitários cobrem o fluxo de edição.
- Logs de alterações registrados no sistema.
- Testes de aceitação validados.
DOR
- API de exclusão de usuários funcional e documentada.
- Casos de uso definidos.
Critérios de Aceitação
- Deve ser possível excluir um usuário da plataforma.
- Usuário excluído deve ser removido imediatamente da listagem.
- Mensagem de confirmação de exclusão deve ser exibida antes da ação.
- Caso o usuário tenha dependências no sistema, uma mensagem de erro deve ser exibida.
DOD
- Exclusão realizada com sucesso e refletida na listagem.
- Testes unitários e de aceitação confirmam a exclusão correta.
DOR
- Campos necessários para o cadastro de alertas foram definidos (nome, tipo, descrição, prioridade, etc.).
- API para criação de alertas documentada no Swagger.
- Design da interface aprovado no Figma.
Critérios de Aceitação
- Campos obrigatórios para cadastro: nome, tipo, prioridade e descrição.
- Deve ser possível associar alertas a estações ou usuários.
- Mensagens de validação devem ser exibidas para campos obrigatórios não preenchidos.
DOD
- Alertas cadastrados aparecem corretamente na listagem.
- Validações de dados implementadas e funcionando.
- Testes unitários garantem o funcionamento do fluxo de cadastro.
- Logs de criação registrados no sistema.
- Testes de aceitação realizados.
DOR
- API para listagem de alertas documentada e funcional no Swagger.
- Design da interface de listagem de alertas aprovado no Figma.
Critérios de Aceitação
- Todos os alertas cadastrados devem ser listados com detalhes como nome, tipo, prioridade e status.
- Deve haver um sistema de busca e filtros para encontrar alertas por tipo, prioridade ou estação associada.
- Os alertas devem ser paginados para facilitar a navegação.
DOD
- Listagem de alertas funcional e paginada.
- Busca e filtros implementados corretamente.
- Feedback de erro implementado em caso de falha no carregamento.
- Testes unitários cobrem listagem, busca e filtros.
- Testes de aceitação realizados com sucesso.
DOR
- API para atualização de alertas está documentada e funcional no Swagger.
- Design da interface de edição foi aprovado no Figma.
Critérios de Aceitação
- Deve ser possível editar todos os dados de um alerta, exceto seu ID.
- Validações devem garantir a consistência das alterações (e.g., status válido).
- As alterações devem ser refletidas imediatamente na listagem.
DOD
- Alterações realizadas com sucesso e refletidas na interface.
- Validações testadas e funcionando corretamente.
- Testes unitários cobrem o fluxo de edição de alertas.
- Logs de alterações registrados no sistema.
- Testes de aceitação validados.
DOR
- A funcionalidade de cadastro de parâmetros para estações deve ser capaz de vincular um parâmetro a uma estação específica.
- A interface de cadastro deve ser responsiva e clara.
Critérios de Aceitação
- Deve ser possível cadastrar parâmetros específicos para cada estação.
- Parâmetros cadastrados devem ser exibidos corretamente na estação correspondente.
- Mensagem de erro deve ser exibida caso o cadastro falhe.
- O sistema deve validar se os parâmetros estão corretamente associados à estação.
DOD
- Parâmetros para estações podem ser cadastrados corretamente.
- Testes de aceitação validados.
DOR
- API para atualização de parâmetros de estação está funcional.
- Interface de alteração foi aprovada.
Critérios de Aceitação
- Parâmetros de estação devem ser alterados corretamente na interface.
- Após a alteração, os parâmetros atualizados devem ser refletidos na estação associada.
- Mensagens de erro devem ser exibidas caso a alteração não seja bem-sucedida.
DOD
- Parâmetros alterados são atualizados corretamente.
- Testes de integração garantem a alteração de parâmetros de estação.
DOR
- API ou serviço de integração para recebimento de dados das estações funcional.
Critérios de Aceitação:
- O sistema deve ser capaz de receber todos os dados das estações automaticamente a cada 15 minutos.
- Deve haver validação para garantir que os dados recebidos sejam consistentes com os parâmetros configurados.
- Dados inválidos devem ser rejeitados.
- Caso nenhum dado chegue no momento esperado, devemos disparar uma log para que o adm seja reportado sobre isso, a fim de garantir a integridade dos dados.
DOD
- Dados das estações são recebidos corretamente no sistema.
- Mensagens de erro implementadas para problemas na integração.
- Testes unitários cobrem a integração com o backend.
- Testes de aceitação validaram o recebimento de dados em diferentes cenários.
DOR
- Regras de processamento dos dados documentadas.
Critérios de Aceitação:
- Dados recebidos devem ser processados para remover inconsistências e estruturar a informação.
- Os dados tratados devem estar disponíveis para visualização e análise.
- Todos os dados devem passar por validação para garantir que os mesmos vieram com a unidade de medida correta.
- Todos os dados devem realizar a verificação se é necessário utilizar algum fator de conversão ou offset.
DOD
- Dados recebidos são tratados e armazenados corretamente.
- Logs de erros implementados para problemas de processamento.
- Testes unitários validam a lógica de transformação dos dados.
- Testes de aceitação realizados com diferentes cenários de entrada.
DOR
- API para consulta de parâmetros de estação está configurada e funcional.
- Design da interface de consulta aprovado.
Critérios de Aceitação
- Parâmetros de cada estação devem ser consultados pela interface.
- Deve ser possível filtrar parâmetros por nome ou categoria.
- A interface deve exibir corretamente os parâmetros de cada estação.
DOD
- Parâmetros são consultados corretamente.
- Testes de aceitação garantem que os dados corretos são exibidos.
DOR
- A interface deve listar todos os parâmetros de estação de forma clara.
- A funcionalidade de exibição foi aprovada.
Critérios de Aceitação
- A lista de parâmetros deve ser organizada por estação.
- Cada parâmetro deve mostrar informações como nome, categoria e valor.
- Os parâmetros devem ser exibidos de forma responsiva e amigável ao usuário.
DOD
- Parâmetros são exibidos corretamente na interface.
- Testes de usabilidade confirmam a clareza da exibição.
DOR
- Fluxo de navegação entre páginas definido e aprovado.
- Interface do sistema validada com base em boas práticas de UX/UI.
- Critérios de aceitação claros para usabilidade.
Critérios de Aceitação:
- Menus e navegação funcionam de forma intuitiva e fluida.
- Mensagens de erro e feedbacks de navegação são claros.
DOD
- Menus de navegação testados e funcionando corretamente.
- Feedback de navegação claro e fácil de entender.
- Testes de usabilidade realizados com feedback positivo dos usuários.
- Testes unitários garantem a funcionalidade dos menus.
DOR
- Os dados dos sensores devem ser recebidos pelo consumer e devem ser enviados para o backend através do broker mqtt (mosquito) para que o banco de dados Redis.
- Critérios de aceitação definidos.
DOD
- Dados são recebidos automaticamente e exibidos corretamente no sistema.
- Logs registrados para monitoramento do fluxo automatizado.
- Testes unitários cobrem o processamento automatizado dos dados.
- Testes de aceitação realizados com sucesso.
Critérios de Aceitação:
- O sistema deve ser capaz de se conectar automaticamente aos sensores das estações para receber dados.
- Logs detalhados devem ser gerados para cada transação automatizada.
- Caso haja falhas na comunicação, o sistema deve tentar se reconectar de forma automática em intervalos pré-definidos.
DOR
- API para atualização de parâmetros de estação está disponível.
- Interface de edição foi aprovada e definida.
Critérios de Aceitação
- Deve ser possível alterar parâmetros para uma estação.
- As alterações devem ser refletidas imediatamente após a edição.
- Mensagens de erro devem ser exibidas em caso de falhas na alteração.
DOD
- Alterações de parâmetros são aplicadas corretamente.
- Testes de aceitação garantem o fluxo de alteração de dados.
DOR
- Estrutura de informações definida e aprovada (e.g., tutorial, funcionalidades).
- Critérios de aceitação aprovados para exibição das informações.
Critérios de Aceitação
- Página de informações deve ser acessível e responsiva.
- Dados devem ser apresentados de forma clara e organizada.
- Deve ser possível visualizar informações completas sobre o sistema ou funcionalidades.
- Testes unitários devem cobrir a renderização correta das informações.
- Testes de aceitação devem garantir a clareza e a acessibilidade das informações.
DOD
- Página de informações disponível e acessível.
- Dados são apresentados de maneira clara e organizada.
- Testes unitários e de aceitação garantem a integridade e acessibilidade das informações.
DOR
- Ferramenta de CI/CD configurada (e.g., Jenkins, GitHub Actions).
- Scripts de build e deploy configurados e testados previamente.
- Checklist de validação de versões implementado.
Critérios de Aceitação
- Sistema deve realizar deploy automaticamente em ambiente de homologação e produção.
- Logs e notificações de status de deploy devem ser implementados.
- Testes unitários e de integração devem ser executados automaticamente antes do deploy.
- Testes de aceitação devem ser realizados após o deploy em homologação para garantir o funcionamento correto.
DOD
- Deploy automático realizado corretamente em ambos os ambientes.
- Logs de deploy e notificações de status funcionando corretamente.
- Testes automatizados executados antes e após o deploy.
- Testes de aceitação realizados com sucesso em ambiente de homologação.
DOR
- Ferramentas de teste configuradas (Jest).
- Componentes interativos da interface implementados.
- Casos de uso e fluxos de interação detalhados e aprovados.
Critérios de Aceitação
- Testar cliques em botões para verificar se ações esperadas são disparadas corretamente.
- Garantir que múltiplos cliques em botões não causem comportamentos indesejados.
- Verificar submissões de formulários, incluindo validação de campos obrigatórios.
- Testar interação com elementos como dropdowns, sliders e checkboxes.
- Garantir que modais abrem, fecham e executam ações internas corretamente.
- Assegurar que mudanças no estado da aplicação após interações ocorrem conforme esperado.
DOD
- Testes unitários escritos e executados com Jest.
- Cobertura de testes inclui os componentes interativos de maior relevância.
- Pull request enviado com descrição clara dos cenários testados.
- Testes aprovados no pipeline de integração contínua.
DOR
- Conexão do front-end com o back-end configurada.
- Fluxos principais de integração entre a interface e a API documentados no Swagger.
- Configuração de mocks ou servidores de teste para simular respostas da API.
Critérios de Aceitação
- Testar chamadas API para validar que os dados enviados e recebidos estão corretos.
- Garantir que componentes do front-end lidam adequadamente com respostas bem-sucedidas e erros da API.
- Verificar que fluxos principais, como listagem de itens e envio de formulários, estão funcionando de ponta a ponta.
- Simular cenários de erro, como tempo limite ou dados inválidos retornados pela API.
DOD
- Testes de integração escritos e executados com Jest.
- Relatórios de cobertura para fluxos de integração estão disponíveis.
- Mock API configurada e integrada nos testes.
- Testes aprovados no pipeline de integração contínua.
- Pull request enviado com detalhes dos cenários de integração testados.
DOR
- Ferramentas de teste configuradas (Pytest).
- Principais endpoints e funcionalidades do back-end implementados.
- Casos de uso documentados com base nas especificações da API.
Critérios de Aceitação
- Testar endpoints para validar entrada e saída de dados corretamente.
- Garantir que regras de negócio são validadas (e.g., dados obrigatórios, formatos válidos).
- Simular cenários de erro para garantir tratamento adequado de exceções.
- Verificar que funções auxiliares e métodos utilizados no back-end estão funcionando como esperado.
DOD
- Testes unitários escritos e executados com Pytest.
- Cobertura de testes alcança todas as funcionalidades críticas do back-end.
- Relatório de cobertura de código está disponível e aprovado.
- Testes passam em todos os cenários no pipeline de integração contínua.
- Pull request enviado com descrição detalhada dos testes implementados.
DOR
- Ferramentas de teste configuradas (Pytest).
- Endpoints documentados no Swagger.
- Banco de dados de teste configurado e operacional.
Critérios de Aceitação
- Testar fluxos principais que envolvem interação com o banco de dados e APIs externas.
- Garantir que todos os endpoints funcionam conforme esperado nos cenários principais.
- Verificar cenários de erro, como dados inválidos e falhas de comunicação com serviços externos.
DOD
- Testes de integração escritos e executados com Pytest.
- Cobertura de testes inclui os principais endpoints e fluxos principais.
- Banco de dados de teste limpa e restaura os dados corretamente após cada execução.
- Relatório de testes de integração disponível e aprovado.
- Pull request enviado com detalhes dos cenários de integração testados.
