Sublime Caixa - Sistema de Gestão para Salão de Beleza Sublime Caixa - Management System for Beauty Salons
Sistema interno desenvolvido do zero para atender às necessidades de um salão de beleza real, cobrindo caixa, estoque, clientes e fichas técnicas. Desenvolvido e testado em paralelo - hoje em uso diário pelo cliente.
Internal system developed from scratch to meet the needs of a real beauty salon, covering cashier, inventory, clients, and technical records. Developed and tested in parallel - currently in daily use by the client.
Ciclo de Desenvolvimento Development Cycle
Stack utilizada Tech Stack
Python · Django
Back-end, rotas, regras de negócio e ORM
Back-end, routes, business rules and ORM
HTML · CSS · JS
Front-end dinâmico com formulários e interações
Dynamic front-end with forms and interactions
PostgreSQL
Banco de dados relacional em produção
Relational database in production
Cypress
Testes E2E e regressão automatizados
Automated E2E and regression tests
Postman
Testes manuais e automatizados de API REST
Manual and automated REST API tests
Kanban · Scrum
Organização das demandas e entregas
Organization of demands and deliveries
Chance.js
Geração dinâmica de dados de teste
Dynamic test data generation
DataTables
Tabelas e relatórios com filtros
Tables and reports with filters
Estratégia de testes Test Strategy
Prioridade pelos caminhos críticos Priority on critical paths
A estratégia partiu da pergunta: "qual parte não pode falhar?". A resposta foi caixa e estoque — o caixa por risco de faturamento incorreto, o estoque por risco de vender produtos indisponíveis. Esses módulos foram os primeiros a ter cobertura completa.
The strategy started with the question: "which part cannot fail?". The answer was cashier and inventory — cashier for the risk of incorrect billing, inventory for the risk of selling unavailable products. These modules were the first to have full coverage.
Cobertura total intencional Intentional full coverage
Optei por testar todas as partes do sistema, mesmo indo contra o princípio de que "testar tudo é inviável" — decisão consciente para aplicar na prática cada tipo de teste aprendido. Cobertura 100% foi definida como: todas as funcionalidades funcionando sem erros ou bugs críticos.
I chose to test all parts of the system, even going against the principle that "testing everything is unfeasible" — a conscious decision to apply each type of learned test in practice. 100% coverage was defined as: all features working without errors or critical bugs.
Regressão automatizada Automated regression
Suíte completa em Cypress cobrindo todos os fluxos de criação, edição e exclusão de cada módulo. Cada teste é independente, com seus próprios dados gerados dinamicamente para garantir repetibilidade e evitar colisão entre testes.
Complete suite in Cypress covering all creation, editing, and deletion flows of each module. Each test is independent, with its own dynamically generated data to ensure repeatability and avoid collision between tests.
Smoke test manual no caixa Manual smoke test on the cashier
O smoke test é focado exclusivamente no fluxo de venda: realizar uma venda com serviço e produto sem falhas. Executado manualmente por ser o caminho mais crítico do sistema e o que mais impacta diretamente o negócio do cliente.
The smoke test is focused exclusively on the sales flow: performing a sale with service and product without flaws. Executed manually as it is the most critical path of the system and the one that most directly impacts the client's business.
Qualidade e Testes aplicados Quality and Applied Testing
Como o foco da minha carreira é voltada para área de QA, este projeto foi o cenário principal para aplicar os seguintes testes:
As my career focus is on QA, this project was the main scenario for applying the following tests:
Funcionalidades e Regras de Negócio Features and Business Rules
O sistema conta com controle de fluxo de caixa com histórico e registros de recibos, cadastro detalhado de clientes com fichas técnicas de procedimentos, gerenciamento de estoque com histórico de entrada e saída de produtos.
The system features cash flow control with history and receipt records, detailed customer registration with procedure technical records, and inventory management with product entry and exit history.
ClientesClients
- ✓ Nome, telefone e NIF são campos obrigatórios para cadastro de cliente.
- ✓ Telefone com formato e comprimento válido (ex.: apenas números no formato +351 XXX XXX XXX).
- ✓ NIF deve ser único para cada cliente, valida se é padrão de Portugal (9 dígitos) e se outro cliente já possui o mesmo NIF.
- ✓ Email, se preenchido, valida se tem formato válido.
- ✓ Data de nascimento, se preenchido, valida se tem formato válido DD/MM/AAAA e ano deve ser ≤ ano atual.
- ✓ Clientes ativos indica se o cliente ainda é atendido, enquanto clientes inativos não devem aparecer em buscas de venda ou cadastro de fichas.
- ✓ Ao excluir cliente, as fichas devem ser removidas.
- ✓ Name, phone and NIF are required fields for customer registration.
- ✓ Phone with valid format and length (e.g., only numbers in the format +351 XXX XXX XXX).
- ✓ NIF must be unique for each customer, validates if it follows the Portugal standard (9 digits) and if another customer already has the same NIF.
- ✓ Email, if filled in, validates if it has a valid format.
- ✓ Date of birth, if filled in, validates if it has a valid format DD/MM/YYYY and the year must be ≤ current year.
- ✓ Active customers indicate whether the customer is still being served, while inactive customers should not appear in sales searches or record creation.
- ✓ When deleting a customer, the records must be removed.
Fichas de AtendimentoService Records
- ✓ Cliente é obrigatório para fazer o cadastro da ficha
- ✓ Preço deve ser ≥ 0.
- ✓ Data do procedimento não pode ser uma data futura.
- ✓ Profissional é opcional, mas essencial para informar quem realizou o atendimento.
- ✓ Procedimento, homecare e observação são opcionais, mas têm limite de caracteres.
- ✓ Ao excluir um cliente, todas as fichas dele são excluídas.
- ✓ Cada ficha deve registrar o valor do serviço/produto naquela data, não dependendo de atualizações futuras de preço do serviço/produto.
- ✓ Histórico: fichas ordenadas da mais recente para a mais antiga.
- ✓ Customer is required to create a record
- ✓ Price must be ≥ 0.
- ✓ Procedure date cannot be a future date.
- ✓ Professional is optional, but essential to indicate who performed the service.
- ✓ Procedure, homecare and notes are optional, but have a character limit.
- ✓ When deleting a customer, all their records are deleted.
- ✓ Each record must store the service/product price at that date, not depending on future price updates of the service/product.
- ✓ History: records ordered from most recent to oldest.
EstoqueInventory
- ✓ Nome e preço são obrigatórios.
- ✓ Preço deve ser > 0.
- ✓ Quantidade não pode ser negativa, caso não tenha estoque ainda pode ser criado com quantidade 0 e ser atualizada posteriormente, a quantidade é controlada por entradas e saídas.
- ✓ Não é permitido vender produto com estoque insuficiente.
- ✓ Movimentações de estoque devem registrar tipo (entrada/saída), quantidade e data.
- ✓ Produto pode ter descrição opcional.
- ✓ Produtos com quantidade 0 devem aparecer como “sem estoque” em vendas.
- ✓ Produto e tipo (entrada/saída) são obrigatórios para fazer movimentação no estoque.
- ✓ Tipo deve ser apenas entrada ou saída.
- ✓ Ao criar uma saída (venda no caixa), valida se o produto possui estoque suficiente.
- ✓ Cliente pode ser opcional, mas se estiver preenchido indica que a saída está ligada a uma venda.
- ✓ Movimentação no estoque
• Entrada:
- Adiciona quantidade ao estoque pela edição do produto.
• Saída:
- Verifica se quantidade > 0.
- Verifica estoque suficiente.
- Cria movimentação no estoque do tipo 'SAIDA'.
- Associa cliente, se informado. - ✓ Relatório do estoque filtra por data, cliente e produto, mostrando entradas, saídas e quantidade atual de cada produto.
- ✓ Name and price are required.
- ✓ Price must be > 0.
- ✓ Quantity cannot be negative; if there is no stock yet, it can be created with quantity 0 and updated later. Quantity is controlled by stock in and out movements.
- ✓ It is not allowed to sell a product with insufficient stock.
- ✓ Stock movements must record type (in/out), quantity and date.
- ✓ Product may have an optional description.
- ✓ Products with quantity 0 must appear as “out of stock” in sales.
- ✓ Product and type (in/out) are required to perform a stock movement.
- ✓ Type must be either in or out only.
- ✓ When creating an out movement (sale at the cashier), it validates if the product has sufficient stock.
- ✓ Customer can be optional, but if filled it indicates that the out movement is linked to a sale.
- ✓ Stock movement
• In:
- Adds quantity to stock through product editing.
• Out:
- Checks if quantity > 0.
- Checks sufficient stock.
- Creates a stock movement of type 'OUT'.
- Associates customer, if provided. - ✓ Stock report filters by date, customer and product, showing in/out movements and current quantity of each product.
ServiçosServices
- ✓ Nome e preco são obrigatórios.
- ✓ Preço deve ser > 0.
- ✓ Preço do serviço deve ser congelado ao criar uma venda, preservando o valor no histórico das vendas antigas.
- ✓ Name and price are mandatory.
- ✓ Price must be > 0.
- ✓ Service price must be frozen upon sale to preserve historical data.
CaixaCashier
- ✓ Cliente é opcional, mas essencial, caso não tenha o registro fica como “Não informado”.
- ✓ Data por padrão é a data e hora local do dispositivo.
- ✓ Desconto e sinal são opcionais, pode ser ≥ 0.
- ✓ Valor total deve ser > 0 (não pode ser negativo nem zero).
- ✓ Profissional opcional, mas essencial para informar quem realizou o atendimento.
- ✓ Forma de pagamento é obrigatório, deve ser uma das opções definidas.
- ✓ Quantidades sempre 1 por registro; multiplicar registro se necessário.
- ✓ Fatura deve ser 'sim' ou 'nao' de acordo com desejo da cliente, caso não seja selecionado salva como 'nao'.
- ✓ Ao finalizar venda:
- Valida estoque dos produtos (tem um campo no caixa mostrando a quantidade de estoque real).
- Valida valor total ≥ 0, caso não seja validado a venda não é finalizada e uma mensagem de erro aparece na tela.
- A quantidade dos produtos vendidos é atualizada no estoque assim que a venda é finalizada no caixa.
- Os nomes e valores de produtos/serviços são congelados no recibo para evitar alterações de valor/nome em recibos antigos caso tenha alteração de preço ou nome no futuro. - ✓ Pelo menos produto ou servico deve estar preenchido.
- ✓ Quantidade de produto ou serviço é sempre 1, caso a cliente vá pagar 2 serviços/produtos iguais, deve ser adicionado o serviço/produto 2 vezes.
- ✓ Produto ou serviço deve ser preenchido no momento da venda para congelar no histórico das vendas e no recibo da cliente.
- ✓ Não permite vender mais do que estoque disponível.
- ✓ Atualizações de preço ou nome do produto/serviço não devem afetar vendas já registradas.
- ✓ Client is optional but essential; if not registered, it stays as "Not informed".
- ✓ Date by default is the device's local date and time.
- ✓ Discount and down payment are optional, must be ≥ 0.
- ✓ Total value must be > 0 (cannot be negative or zero).
- ✓ Professional optional, but essential to inform who performed the service.
- ✓ Payment method is mandatory, must be one of the defined options.
- ✓ Quantities always 1 per entry; multiply the entry if necessary.
- ✓ Invoice must be 'yes' or 'no' according to the client's wish; if not selected, saves as 'no'.
- ✓ When finalizing a sale:
- Validates product stock.
- Validates total value ≥ 0.
- Sold quantities are updated in stock.
- Values are frozen in the receipt. - ✓ At least product or service must be filled.
- ✓ Product or service quantity is always 1, if 2 are sold, they must be added twice.
- ✓ Product or service must be filled at the time of sale to freeze in history.
- ✓ Does not allow selling more than available stock.
- ✓ Price or name updates should not affect already registered sales.
Destaques técnicos Technical Highlights
Dados dinâmicos e independência entre testes Dynamic data and test independence
Cada teste gera seus próprios dados via gerarClientes() com a biblioteca chance.js e Date.now(), garantindo nomes únicos e evitando colisão entre execuções. Isso torna a suíte repetível e confiável sem depender de dados pré-existentes.
Each test generates its own data via gerarClientes() with the chance.js library and Date.now(), ensuring unique names and avoiding collision between executions. This makes the suite repeatable and reliable without depending on pre-existing data.
Seletores robustos com data-test Robust selectors with data-test
Todos os elementos interativos foram marcados com atributos data-test no front-end durante o desenvolvimento, garantindo que mudanças de layout ou estilo não quebrem os testes automatizados.
All interactive elements were marked with data-test attributes on the front-end during development, ensuring that layout or style changes do not break automated tests.
Congelamento de dados em vendas Data freezing in sales
Regra de negócio implementada e testada: nomes e preços de serviços e produtos são congelados no momento da venda para que alterações futuras de preço ou nome não afetem o histórico de vendas já registrado.
Business rule implemented and tested: service and product names and prices are frozen at the time of sale so that future price or name changes do not affect the already registered sales history.
Melhorias identificadas durante os testes Improvements identified during testing
Durante a automação, foram identificados pontos de melhoria no sistema: substituição de window.confirm() nativo por modais customizados na exclusão de fichas, e adição de mensagem de feedback ao excluir produtos — ambos documentados no código como pontos de evolução.
During automation, improvement points were identified in the system: replacing native window.confirm() with custom modals in record deletion, and adding a feedback message when deleting products — both documented in the code as evolution points.
O que aprendi e apliquei What I learned and applied
Desenvolvimento full-stack real Real full-stack development
Do levantamento de requisitos com o cliente à implementação completa com Django, JavaScript e PostgreSQL.
From requirements gathering with the client to full implementation with Django, JavaScript, and PostgreSQL.
Desenvolvimento e QA em paralelo Development and QA in parallel
Aprender a testar enquanto desenvolve muda a forma de escrever código — pensando em testabilidade desde o início.
Learning to test while developing changes the way you write code — you think about testability from the start.
Estratégia de testes com critério Criteria-based test strategy
Definir o que testar primeiro, como garantir cobertura, o que vai para regressão e o que entra no smoke test.
Defining what to test first, how to ensure coverage, what goes to regression, and what enters the smoke test.
Testes de API com Postman API testing with Postman
Validação de status codes, regras de negócio e integridade de dados em uma API REST real com environment configurado.
Validation of status codes, business rules, and data integrity in a real REST API with configured environment.
Confiabilidade de testes automatizados Reliability of automated tests
Dados dinâmicos, independência entre testes e seletores estáveis como base para uma suíte que pode ser executada repetidamente.
Dynamic data, independence between tests, and stable selectors as a basis for a suite that can be executed repeatedly.
Produção como o melhor laboratório Production as the best laboratory
Bugs que aparecem só em uso real ensinam mais do que qualquer ambiente de teste. O beta com o cliente revelou necessidades que não existiam no levantamento inicial.
Bugs that appear only in real use teach more than any test environment. The beta with the client revealed needs that did not exist in the initial survey.
Repositório no GitHub: GitHub Repository:
Você pode ver o projeto clicando aqui You can see the project by clicking here