Sessão 1 — Teste Exploratório de UI
Participantes
Luiz Francisco Piedade Pucci Neto
Gabriel Fernando Palomares
Charter
Explore:
O formulário de cadastro de produtos no Frontend do ServeRest.
Com:
A heurística CHIQUE, com foco nas letras C (Campos obrigatórios e validações) e E (Entradas inesperadas e Estouro).
Para descobrir:
A robustez das validações de interface (client-side) e como o sistema se comporta ao receber dados formatados incorretamente (como espaços em branco) ou arquivos de tipos não suportados para imagens.
Sessão
Início: 14/08/2026 às 20:00
Fim: 14/08/2026 às 20:25
Estratégia
A exploração utilizou a heurística CHIQUE para estressar os limites do formulário de cadastro, simulando comportamentos fora do "caminho feliz". A condução foi dividida em duas frentes de atuação para contornar bloqueios visuais: primeiro, tentei burlar a obrigatoriedade do campo texto de "Nome" inserindo apenas espaços em branco seguidos. Segundo, submeti um arquivo de formato incompatível (arquivos de texto simples - .txt) no campo exclusivo para upload de imagens, avaliando a capacidade de reação da interface frente a dados sujos.
Achados
(C - Campos obrigatórios): O sistema não realiza a higienização dos dados de entrada (função de trim()). Ele permite cadastrar um produto preenchendo o campo "Nome" apenas com espaços, gerando um "produto fantasma" na listagem.
(E - Entradas Inesperadas): O campo de imagem não restringe adequadamente as extensões ou o tipo MIME dos arquivos. O sistema aceitou o upload do arquivo de texto teste.txt, registrou o caminho padrão no navegador (C:\fakepath\teste.txt) e tratou uma entrada completamente inválida como se fosse uma imagem legítima.
Questionamentos
Essas falhas de validação ocorrem exclusivamente no frontend, ou a API (backend) também permite a persistência de registros com strings vazias e arquivos de qualquer formato?
Como a interface da listagem e da vitrine de produtos irá se comportar e renderizar esses itens quando houver a tentativa de buscá-los ou filtrá-los no sistema?
Evidências
Evidência 1:
Evidência 2:
Evidência 3:
Aprendizados
Foi descoberto que o frontend do ServeRest é frágil quanto à garantia da integridade dos dados na origem, confiando excessivamente no input direto do usuário sem tratamentos. A aplicação carece de validações primárias essenciais, como a higienização de texto e a verificação do tipo de arquivo, antes de acionar a requisição de criação de produto.
Riscos
Risco de UX e Negócios: Impacto negativo na experiência de compra, pois usuários visualizarão vitrines com produtos sem nome de identificação e imagens quebradas.
Risco Técnico e de Segurança: Poluição da base de dados com informações inconsistentes, o que pode desencadear quebras no layout da listagem, falhas na funcionalidade de filtros de pesquisa e potencial vulnerabilidade no servidor ao permitir uploads irrestritos de arquivos (caso o backend também não valide).
Próximas investigações
Para uma próxima sessão, o foco será investigar o comportamento da listagem, pesquisa e filtros do sistema ao interagir com esses "produtos fantasmas". Além disso, seria interessante enviar requisições de criação com esses mesmos cenários diretamente via API (usando ferramentas como Postman) para validar se o backend possui alguma camada de segurança.
Shift-Left
O comportamento de aceitar nomes em branco e arquivos .txt poderia ter sido descoberto e prevenido logo na fase de Engenharia de Requisitos, estabelecendo Critérios de Aceitação rígidos nas histórias de usuário (ex: "O nome do produto não pode ser composto unicamente por espaços vazios" e "Apenas arquivos com extensão .jpg ou .png são aceitos").
Durante o desenvolvimento, a aplicação de testes unitários na camada de backend para validar as entidades garantiria que a lógica de negócio rejeitasse essas requisições. Além disso, a aplicação de regras e constraints diretamente na modelagem do banco de dados bloquearia as inserções inválidas na raiz, garantindo a qualidade do sistema independentemente de eventuais falhas de validação no frontend.
Sessão 1 — Teste Exploratório de UI
Participantes
Luiz Francisco Piedade Pucci Neto
Gabriel Fernando Palomares
Charter
Explore:
O formulário de cadastro de produtos no Frontend do ServeRest.
Com:
A heurística CHIQUE, com foco nas letras C (Campos obrigatórios e validações) e E (Entradas inesperadas e Estouro).
Para descobrir:
A robustez das validações de interface (client-side) e como o sistema se comporta ao receber dados formatados incorretamente (como espaços em branco) ou arquivos de tipos não suportados para imagens.
Sessão
Início: 14/08/2026 às 20:00
Fim: 14/08/2026 às 20:25
Estratégia
A exploração utilizou a heurística CHIQUE para estressar os limites do formulário de cadastro, simulando comportamentos fora do "caminho feliz". A condução foi dividida em duas frentes de atuação para contornar bloqueios visuais: primeiro, tentei burlar a obrigatoriedade do campo texto de "Nome" inserindo apenas espaços em branco seguidos. Segundo, submeti um arquivo de formato incompatível (arquivos de texto simples - .txt) no campo exclusivo para upload de imagens, avaliando a capacidade de reação da interface frente a dados sujos.
Achados
(C - Campos obrigatórios): O sistema não realiza a higienização dos dados de entrada (função de trim()). Ele permite cadastrar um produto preenchendo o campo "Nome" apenas com espaços, gerando um "produto fantasma" na listagem.
(E - Entradas Inesperadas): O campo de imagem não restringe adequadamente as extensões ou o tipo MIME dos arquivos. O sistema aceitou o upload do arquivo de texto teste.txt, registrou o caminho padrão no navegador (C:\fakepath\teste.txt) e tratou uma entrada completamente inválida como se fosse uma imagem legítima.
Questionamentos
Essas falhas de validação ocorrem exclusivamente no frontend, ou a API (backend) também permite a persistência de registros com strings vazias e arquivos de qualquer formato?
Como a interface da listagem e da vitrine de produtos irá se comportar e renderizar esses itens quando houver a tentativa de buscá-los ou filtrá-los no sistema?
Evidências
Evidência 1:
Evidência 2:
Evidência 3:
Aprendizados
Foi descoberto que o frontend do ServeRest é frágil quanto à garantia da integridade dos dados na origem, confiando excessivamente no input direto do usuário sem tratamentos. A aplicação carece de validações primárias essenciais, como a higienização de texto e a verificação do tipo de arquivo, antes de acionar a requisição de criação de produto.
Riscos
Risco de UX e Negócios: Impacto negativo na experiência de compra, pois usuários visualizarão vitrines com produtos sem nome de identificação e imagens quebradas.
Risco Técnico e de Segurança: Poluição da base de dados com informações inconsistentes, o que pode desencadear quebras no layout da listagem, falhas na funcionalidade de filtros de pesquisa e potencial vulnerabilidade no servidor ao permitir uploads irrestritos de arquivos (caso o backend também não valide).
Próximas investigações
Para uma próxima sessão, o foco será investigar o comportamento da listagem, pesquisa e filtros do sistema ao interagir com esses "produtos fantasmas". Além disso, seria interessante enviar requisições de criação com esses mesmos cenários diretamente via API (usando ferramentas como Postman) para validar se o backend possui alguma camada de segurança.
Shift-Left
O comportamento de aceitar nomes em branco e arquivos .txt poderia ter sido descoberto e prevenido logo na fase de Engenharia de Requisitos, estabelecendo Critérios de Aceitação rígidos nas histórias de usuário (ex: "O nome do produto não pode ser composto unicamente por espaços vazios" e "Apenas arquivos com extensão .jpg ou .png são aceitos").
Durante o desenvolvimento, a aplicação de testes unitários na camada de backend para validar as entidades garantiria que a lógica de negócio rejeitasse essas requisições. Além disso, a aplicação de regras e constraints diretamente na modelagem do banco de dados bloquearia as inserções inválidas na raiz, garantindo a qualidade do sistema independentemente de eventuais falhas de validação no frontend.