A especificação técnica é uma parte essencial no desenvolvimento de sistemas, pois fornece uma descrição detalhada dos aspectos operacionais e estruturais de um projeto. O principal objetivo é assegurar que todos os envolvidos no processo de desenvolvimento tenham uma compreensão clara dos requisitos, das tecnologias que serão utilizadas, dos fluxos de trabalho e das decisões de design que guiarão a implementação da solução proposta.

O sistema deverá contemplar os seguintes requisitos:

Protocolos:

• HTTP/HTTPS: Comunicação entre cliente e servidor.
• RESTful API: Estrutura de requisições entre frontend e backend.
• JWT (JSON Web Token): Autenticação segura para acesso de usuários autenticados.

Funcionalidades Principais:

• Criação e organização de cenários de teste.
• Associação de cenários a requisitos ou módulos do sistema.
• Atribuição de responsáveis e status (ex: Pendente, Em Execução, Aprovado, Reprovado).
• Upload de evidências (print, vídeo, documentos).
• Geração de relatórios por status, por testador ou por funcionalidade.
• Dashboard com métricas e indicadores de qualidade.

Procedimentos:

1. Realiza cadastro e login no sistema.
2. Cria um projeto ou seleciona um existente.
3. Adiciona cenários de teste com título, descrição, pré-condições, passos e dados esperados.
4. Atribui testadores responsáveis.
5. Registra a execução do teste com status e evidências.
6. Visualiza resultados, métricas e relatórios.
7. Edita, exclui ou duplica cenários conforme necessidade.

Formatos de Dados:

• Cenários de teste: JSON (frontend/backend) com estrutura contendo campos como título, descrição, requisitos vinculados, status e evidências.
• Evidências: Arquivos .jpg, .png, .pdf.
• Exportação: Relatórios gerados em PDF.
• Banco de dados relacional (PostgreSQL): Armazenamento seguro de usuários, projetos, cenários, execuções e evidências.

Módulos do Sistema

• Frontend (Vue.js + Quasar): Interface responsiva com foco em usabilidade e performance.
• Backend (Node.js + Express): API RESTful com endpoints para autenticação, gerenciamento de projetos e cenários.
• Armazenamento de Arquivos: Evidências serão armazenadas em serviço externo.
• Banco de Dados (PostgreSQL): Estrutura relacional para dados persistentes.

Requisitos Funcionais (RF):

Código	Descrição
RF01	O sistema deve permitir que o usuário se cadastre com e-mail e senha.
RF02	O sistema deve permitir que o usuário faça login com suas credenciais.
RF03	O sistema deve permitir a recuperação e alteração de senha pelo usuário.
RF04	O sistema deve permitir que o usuário crie e gerencie projetos de teste.
RF05	O sistema deve permitir a criação de cenários de teste com título, descrição, passos e resultados esperados.
RF06	O sistema deve permitir a associação de cenários a requisitos ou funcionalidades.
RF07	O sistema deve permitir o upload de evidências (imagens e arquivos).
RF08	O sistema deve permitir a atribuição de responsáveis pelos testes.
RF09	O sistema deve registrar o resultado da execução de cada cenário (aprovado, reprovado, pendente).
RF10	O sistema deve manter um histórico de execuções por cenário.
RF11	O sistema deve permitir comentários ou anotações em cada cenário ou execução.
RF12	O sistema deve gerar relatórios com filtros por status, responsável ou projeto.
RF13	O sistema deve permitir a exportação dos relatórios em formato PDF.
RF14	O sistema deve permitir a exclusão e edição de cenários e execuções.
RF15	O sistema deve listar os projetos e cenários criados pelo usuário.

Requisitos Não-Funcionais (NRF):

Código	Requisito Não-Funcional
RNF01	O sistema deve ter uma interface web responsiva.
RNF02	As informações do usuário e senhas devem ser armazenadas de forma criptografada.
RNF03	As evidências de teste devem ser armazenadas com integridade e associadas corretamente aos cenários.
RNF04	O sistema deve garantir segurança nas APIs, com autenticação JWT e validação dos dados.

Para complementar a especificação dos requisitos funcionais, foram elaborados diagramas de casos de uso que representam visualmente as interações entre os usuários (atores) e o sistema. Esses diagramas ajudam a identificar de forma clara as funcionalidades esperadas, facilitando a validação com stakeholders e a organização do desenvolvimento. Cada caso de uso reflete um requisito funcional descrito anteriormente, como cadastro de usuários, criação de cenários de teste, upload de evidências e geração de relatórios.

Os casos de uso estão divididos em 5 diagramas

Figura 1 – Casos de uso do cadastro, login e alteração de senha

O diagrama de casos de uso acima representa as funcionalidades relacionadas à autenticação de usuários na plataforma de testes QA. Ele inclui as ações principais disponíveis para o ator "Usuário", como cadastrar uma nova conta, realizar login no sistema e recuperar ou alterar a senha, estando alinhado com os requisitos funcionais RF01, RF02 e RF03.

Figura 2 – Casos de uso do gerenciamento de projetos de teste

O diagrama de casos de uso da figura 2 representa as funcionalidades relacionadas à criação, visualização e manutenção de projetos de teste na plataforma QA. O ator "Usuário Autenticado" interage com o sistema para realizar ações essenciais como criar novos projetos de teste, listar projetos existentes e editar ou excluir projetos previamente cadastrados. Essas ações estão diretamente ligadas aos requisitos funcionais RF04, RF14 e RF15, permitindo que o usuário mantenha o controle sobre os projetos em andamento dentro da aplicação.

Figura 3 – Casos de uso da geração e exportação de relatórios

O diagrama de casos de uso da figura 3 representa as funcionalidades voltadas à análise de resultados por meio da geração de relatórios na plataforma QA. O ator "Usuário Autenticado" pode gerar relatórios filtrando os dados por projeto, status de execução ou responsável pelos testes. Como parte integrante desse processo, o sistema permite a exportação dos relatórios em formato PDF, funcionalidade incluída automaticamente sempre que um relatório é gerado. Esse diagrama está alinhado aos requisitos funcionais RF12 e RF13.

Figura 4 – Casos de uso da criação e gerenciamento de cenários de teste

O diagrama de casos de uso da figura 4 representa as funcionalidades oferecidas ao "Usuário Autenticado" para gerenciar cenários de teste na plataforma QA. As ações incluem listar os cenários cadastrados, criar novos cenários de teste, editar ou excluir os existentes e associá-los a requisitos ou funcionalidades específicas do sistema. Essas interações são fundamentais para garantir a rastreabilidade e a organização das atividades de Quality Assurance, estando relacionadas aos requisitos funcionais RF05, RF06, RF14 e RF15.

Figura 5 – Casos de uso da execução de cenários de teste

O diagrama de casos de uso da figura 5 apresenta as funcionalidades relacionadas à execução prática dos cenários de teste na plataforma QA. O ator "Usuário Autenticado" pode realizar o upload de evidências (como prints e documentos), comentar cenários ou execuções, consultar o histórico de execuções anteriores, atribuir responsáveis para a realização dos testes e registrar os resultados obtidos. Essas funcionalidades são essenciais para garantir a rastreabilidade, a colaboração entre membros da equipe e a documentação eficiente do processo de Quality Assurance. Os casos de uso aqui apresentados estão alinhados aos requisitos funcionais RF07, RF08, RF09, RF10 e RF11.

O sistema foi concebido com base em uma arquitetura modular e na aplicação do padrão MVC (Model-View-Controller), tanto no frontend quanto no backend, visando organização, escalabilidade e manutenibilidade. A separação entre frontend (Vue.js + Quasar), backend (Node.js + Express) e o banco de dados relacional (PostgreSQL) permite que cada módulo evolua de forma independente, além de facilitar testes, manutenções e futuras integrações com outras ferramentas de QA, como JIRA ou ferramentas de CI/CD.

A arquitetura do sistema está organizada em cinco componentes principais, que interagem de forma integrada para garantir uma experiência fluida ao usuário, processamento eficiente e armazenamento seguro das informações.

Responsável por toda a interação com o usuário, construída com Vue.js e Quasar Framework. Esta interface permitirá:

• Cadastro e login de usuários.
• Criação e gerenciamento de projetos e cenários de teste.
• Execução de testes e registro de resultados.
• Upload e visualização de evidências.
• Acompanhamento de indicadores e relatórios.

Camada intermediária que gerencia a lógica de negócio e o acesso aos dados, estruturada em controladores e serviços:

• Validação e autenticação de usuários (JWT).
• Gerenciamento de projetos, cenários e execuções.
• Processamento de uploads de evidências.
• Geração de relatórios filtráveis e exportáveis.

Componente responsável por tratar os arquivos enviados como evidência, como imagens, vídeos ou documentos:

• Validação de formatos e tamanhos.
• Armazenamento seguro no banco de dados.
• Associação direta com cenários e execuções específicas.

Responsável pela análise dos dados e geração de relatórios gerenciais:

• Rumo por projeto, por testador, por funcionalidade ou status.
• Gráficos de cobertura de testes, taxa de sucesso e evolução por sprint.

Base relacional estruturada para garantir persistência e integridade dos dados, incluindo:

• Informações de usuários, autenticação e permissões.
• Projetos, cenários, execuções, evidências e comentários.
• Logs de alterações e histórico de execução.

A comunicação entre os módulos ocorrerá via requisições REST em formato JSON, garantindo interoperabilidade entre tecnologias distintas e fácil manutenção futura.

Para garantir a organização, escalabilidade e manutenibilidade do sistema, foram adotados dois principais padrões arquiteturais: o padrão MVC (Model-View-Controller) e a separação lógica em microsserviços.

Aplicado tanto no frontend (Vue.js + Quasar) quanto no backend (Node.js + Express), o padrão MVC assegura a separação de responsabilidades e a clareza no desenvolvimento de funcionalidades.

• Model (Modelo): Representa as entidades do sistema como usuários, projetos, cenários, execuções e evidências. Esses modelos são manipulados por meio de um ORM (Prisma), permitindo consultas seguras e performáticas no PostgreSQL.
• View (Visão): Refere-se à interface de usuário desenvolvida com componentes Vue.js, seguindo os princípios de design responsivo e acessibilidade, permitindo interações intuitivas para todas as ações do sistema.
• Controller (Controlador): Responsável por receber requisições, aplicar regras de negócio, validar dados e acionar os serviços adequados. Cada funcionalidade possui seu controlador específico (ex: AuthController, TestCaseController, ExecutionController).

Embora o sistema seja implementado em uma única aplicação, os módulos são organizados de forma lógica e desacoplada, permitindo maior independência entre os componentes internos. Isso facilita futuras expansões, como:

• Módulo de Upload de Evidências: Responsável por gerenciar o upload, validação e armazenamento de arquivos, como imagens e PDFs, seja no sistema de arquivos local ou em serviços externos (ex.: AWS S3).
• Módulo de Relatórios: Encapsula a geração e exportação de relatórios, permitindo filtrar e consolidar dados de projetos, cenários e execuções.

Essa abordagem promove:

• Manutenção facilitada, já que cada módulo possui uma responsabilidade bem definida dentro da aplicação.
• Evolução contínua, permitindo introduzir novas funcionalidades ou até mesmo transformar módulos em microsserviços no futuro, sem impacto nas partes críticas do sistema.
• Reutilização de código, como middlewares de autenticação, validações genéricas, serviços utilitários e integração com banco de dados ou armazenamento de evidências.

O sistema foi modelado utilizando o C4 Model, que permite visualizar sua arquitetura em diferentes níveis de abstração:

• Nível 1 – Contexto: Define a visão geral da plataforma QA.
• Nível 2 – Contêineres: Demonstra como o sistema é dividido em contêineres, como o frontend (Vue.js + Quasar), backend (Node.js + Express), banco de dados (PostgreSQL) e serviços auxiliares, como o serviço de relatórios e o serviço de upload de evidências.
• Nível 3 – Componentes: Detalha os componentes internos de cada contêiner, como os controllers (AuthController, ProjectController, TestCaseController, ExecutionController), os serviços e os modelos ORM (Prisma).

Figura 6 – Diagrama de Contexto do Sistema de Gerenciamento de Testes QA

O diagrama de contexto acima apresenta uma visão macro da arquitetura lógica do sistema de gerenciamento de testes QA, com base no modelo C4 - nível de contexto. Ele descreve a interação do ator principal (Usuário) com os principais componentes do sistema, ilustrando o fluxo de acesso e responsabilidades entre as camadas. O Usuário, representado como ator externo, interage inicialmente com o Frontend, uma interface web desenvolvida com Vue.js e Quasar, responsável por proporcionar uma experiência visual e funcional completa para as atividades de cadastro, execução e acompanhamento dos projetos de teste. O Frontend, por sua vez, se comunica diretamente com o Backend, implementado em Node.js com Express, que centraliza toda a lógica de negócio, controle de autenticação e gerenciamento das regras do sistema. Por fim, o Backend acessa o Database, um banco de dados relacional PostgreSQL, responsável pelo armazenamento persistente e estruturado das informações — incluindo usuários, projetos, cenários, execuções, evidências e logs de alterações. Esse diagrama reforça a separação de responsabilidades, a comunicação em camadas e a arquitetura modular, garantindo escalabilidade, manutenibilidade e segurança para o sistema como um todo.

Figura 7 – Diagrama de Contêineres do Sistema de Gerenciamento de Cenários de Teste QA

O diagrama de contêineres detalha a estrutura interna do sistema, destacando os principais componentes (contêineres) responsáveis por executar as funcionalidades da aplicação e suas interações. O ator Usuário interage com o sistema por meio de um Frontend desenvolvido com Vue.js e Quasar, que oferece funcionalidades como autenticação, criação e visualização de projetos, cenários, execuções e relatórios. Esse frontend se comunica com o Backend, uma API REST desenvolvida com Node.js, Express e Prisma, responsável por processar as regras de negócio, autenticação via JWT e persistência de dados. A API se conecta a dois contêineres principais de suporte:

• Database: um banco de dados relacional PostgreSQL utilizado para armazenar todas as entidades estruturadas do sistema (usuários, projetos, cenários, execuções, evidências, etc.).

• Armazenamento de Evidências: representa o subsistema de arquivos, que pode ser implementado com sistema de arquivos local ou um serviço em nuvem como AWS S3, destinado a armazenar evidências como imagens e documentos.

As comunicações são realizadas por meio de protocolos seguros (HTTPS/JSON para API e PostgreSQL Protocol para o banco de dados), garantindo integridade e segurança nas trocas de informação.

Figura 8 – Diagrama de Componentes do Sistema de Gerenciamento de Cenários de Teste QA

O diagrama de componentes detalha a arquitetura interna da API Backend da plataforma de gerenciamento de testes QA, destacando os principais módulos que compõem sua estrutura lógica. Esse nível de detalhamento permite compreender como as funcionalidades são distribuídas entre controladores, serviços e middlewares, reforçando a modularidade e manutenibilidade do sistema.

O ator Usuário interage com o Frontend (implementado com Quasar + Vue.js), que se comunica com o Backend API (desenvolvido em Node.js + Express) via REST (JSON/HTTPS). A API é composta por diversos componentes responsáveis por áreas específicas da lógica de negócio:

• Auth Controller: Gerencia autenticação, login e cadastro de usuários, utilizando JWT.
• Project Controller: Responsável pela criação e edição de projetos de teste.
• TestCase Controller: Manipula os cenários de teste.
• Execution Controller: Lida com o processo de execução dos testes.
• Report Service: Gera relatórios analíticos em PDF/CSV com dados filtrados.
• File Upload Service: Trata o upload e associação de evidências aos testes.
• Security Component (Middleware): Implementa camadas de segurança, como validação de JWT, proteção contra CSRF e XSS.

Esses componentes acessam dois contêineres externos:

• Database (PostgreSQL): Armazena todos os dados estruturados da aplicação (usuários, projetos, execuções, cenários e evidências).
• File Storage (Local ou em Nuvem como AWS S3): Responsável por guardar os arquivos de evidência enviados pelos usuários (imagens, vídeos, documentos).

Essa organização fortalece a separação de responsabilidades, facilita a escalabilidade e melhora a testabilidade individual de cada módulo, promovendo boas práticas de desenvolvimento orientado a serviços.

• JavaScript / TypeScript: Utilizadas no frontend (Vue.js) e backend (Node.js). TypeScript garante tipagem estática e maior segurança no código, evitando erros em tempo de execução.
• SQL (PostgreSQL): Utilizada para manipulação de dados relacionais com alto desempenho, integridade e suporte a relacionamentos complexos.

Frontend (interface web):

• Vue.js: Framework progressivo, com curva de aprendizado acessível e alta produtividade no desenvolvimento de interfaces dinâmicas.
• Quasar Framework: Baseado em Vue.js, permite criação rápida de interfaces responsivas com componentes prontos e compatibilidade mobile/desktop.

Backend (lógica de negócio):

• Node.js: Ambiente leve e escalável para execução de código JavaScript no servidor.
• Express.js: Framework web minimalista e flexível para construção de APIs RESTful.
• Prisma ORM: Mapeamento objeto-relacional (ORM) moderno e seguro, facilita a integração com PostgreSQL.

• JWT (jsonwebtoken): Geração de tokens seguros para autenticação de sessões.
• Bcrypt.js: Hash de senhas de forma segura e resistente a ataques.

Upload e Armazenamento:

• Multer: Middleware para upload de arquivos no backend.

Relatórios:

• pdfkit / json2csv: Bibliotecas para geração de relatórios em PDF e CSV.

Ferramentas de Desenvolvimento e Gestão de Projeto

• Visual Studio Code: IDE leve, com suporte a extensões de Vue, Node e integração com Git.
• Git e Github: Controle de versão, documentação e colaboração entre integrantes.
• Postman: Testes de APIs RESTful durante o desenvolvimento backend.
• GitHub Projects: Gestão de tarefas, sprints e acompanhamento do progresso do projeto.

Banco de Dados:

• PostgreSQL: Banco de dados relacional robusto, ideal para manter integridade entre entidades como cenários, execuções, usuários e evidências. Suporta relacionamentos complexos, controle de transações e segurança avançada.

A segurança é um aspecto crítico em qualquer sistema que lide com dados sensíveis, como credenciais de acesso, informações de usuários e arquivos enviados. No projeto de gerenciamento de cenários de teste QA, as considerações de segurança são fundamentais para garantir a integridade dos dados, a proteção contra acessos não autorizados e a confidencialidade das informações tratadas.

Uma das primeiras camadas de segurança será o controle de autenticação, utilizando JSON Web Tokens (JWT) para garantir que apenas usuários autenticados tenham acesso às funcionalidades da plataforma. Os tokens JWT serão gerados após o login e utilizados para validar a identidade do usuário em cada requisição subsequente, com um tempo de expiração para reduzir os riscos de uso indevido. Além disso, o sistema adotará um controle de permissões baseado em papéis (por exemplo, Testador, Desenvolvedor, Gestor de QA) para garantir que os usuários acessem apenas as funcionalidades que lhes são permitidas.

As senhas dos usuários serão armazenadas de forma criptografada utilizando a biblioteca bcrypt.js. Isso assegura que mesmo em caso de violação de segurança no banco de dados, as senhas não poderão ser recuperadas ou utilizadas de forma indevida. Para garantir a confidencialidade dos dados durante a comunicação entre cliente e servidor, todo o tráfego será protegido com HTTPS, utilizando SSL/TLS para a encriptação dos dados em trânsito.

Diversas vulnerabilidades comuns em aplicações web serão mitigadas:

• Proteção contra Cross-Site Scripting (XSS): A entrada de dados será cuidadosamente validada e sanitizada para evitar que scripts maliciosos sejam injetados nas páginas, protegendo tanto o sistema quanto os usuários finais.
• Proteção contra Cross-Site Request Forgery (CSRF): O sistema utilizará tokens anti-CSRF em todas as requisições que modificam dados no servidor, garantindo que as solicitações só possam ser realizadas a partir da própria interface de usuário e não por ataques externos.
• Prevenção contra SQL Injection: Embora o uso do ORM Prisma reduza significativamente o risco de injeção SQL, validações adicionais e práticas seguras serão adotadas para garantir que todas as entradas de dados sejam corretamente tratadas, impedindo a execução de comandos maliciosos no banco de dados.
• Validação e Sanitização de Arquivos: Os arquivos enviados pelos usuários, como evidências de teste, serão validados quanto ao tipo e tamanho. Apenas formatos permitidos (imagens, vídeos e documentos) serão aceitos, evitando o upload de arquivos executáveis ou maliciosos. Além disso, os nomes dos arquivos serão sanitizados para prevenir ataques por injeção ou manipulação de caminho.

Para garantir a segurança durante as sessões de usuário, o sistema implementará controle de sessões robusto, com tokens JWT com tempo de expiração configurável. Caso o usuário permaneça inativo por um período prolongado, a sessão será automaticamente invalidada, exigindo novo login. Além disso, o logout será completamente gerenciado, garantindo que a sessão seja encerrada corretamente.

A plataforma também será projetada para realizar o monitoramento constante de atividades suspeitas. Serão registrados logs de eventos críticos, como falhas de autenticação, tentativas de acesso não autorizado e alterações de dados. Esses logs permitirão a auditoria do sistema e poderão ser utilizados em investigações, caso necessário.

A segurança também envolve garantir que os dados possam ser recuperados em caso de falha. O sistema realizará backups regulares do banco de dados e das evidências de testes armazenadas, protegendo esses dados contra perdas acidentais ou ataques de ransomware.