Defeito barato é defeito cedo
Um problema encontrado no refinamento custa uma conversa. O mesmo problema em produção custa retrabalho, suporte, reputação e às vezes clientes.
Software Quality Engineer
GabrielRomanini
Mais de 8 anos construindo qualidade de software em ambientes ágeis de alta escala: estruturando áreas de QA do zero, desenvolvendo software com ênfase em qualidade, liderando equipes e aplicando Inteligência Artificial à engenharia de testes.
Curitiba · PR · Brasil
Os pilares da qualidade de software
Qualidade como estratégia, não como etapa.
A maioria dos softwares é construída primeiro e testada depois. Aqui, o caminho é o inverso: cada funcionalidade é pensada a partir de como pode falhar, antes da primeira linha de código. O resultado são entregas que chegam prontas, com menos retrabalho, menos surpresas e mais confiança para evoluir.
Para empresas, isso significa qualidade estruturada como parte da engenharia: processos sólidos, governança e times que entregam mais rápido sem abrir mão da estabilidade. Um trabalho potencializado por Inteligência Artificial (GenAI, LLM e MCP), que automatiza análises e acelera a criação de cenários de teste.
Para quem está tirando uma ideia do papel, significa desenvolvimento conduzido por um especialista em qualidade, com tranquilidade também depois da entrega. Projetos que nascem bem elaborados, acessíveis, seguros e fáceis de manter, porque são pensados desde o início por quem sabe onde o software costuma quebrar.
Por que ter um engenheiro de qualidade no time
Um QA não está ali só para encontrar bugs. Está para evitar que eles nasçam, dar confiança para o time entregar e garantir que o software resolve o problema de quem usa.
Velocidade com segurança
Qualidade não freia o time. Com testes confiáveis e critérios claros, o time entrega mais rápido porque para de apagar incêndio.
O olhar de quem usa
O QA questiona o que ninguém perguntou: e se o usuário fizer diferente? E se a rede cair? E se o dado vier vazio? É aí que moram os bugs.
Decisão com dados
Métricas de qualidade mostram onde está o risco real, e transformam a pergunta “está pronto para subir?” em algo objetivo.
Qualidade na prática
Quality Engineering
Software entregue com altíssima qualidade: estratégia de testes, cultura de qualidade no time e testes bem implementados, do planejamento à produção.
IA aplicada a testes
Evolução de frameworks internos com GenAI, LLM e MCP para gerar cenários, planos de teste e validações automatizadas com agentes inteligentes.
Automação de testes
Testes que rodam sozinhos, sem interação humana, sempre que o software muda. O ganho: erros encontrados em minutos, entregas mais rápidas e a segurança de que o que já funcionava continua funcionando.
CI/CD & Observabilidade
Testes integrados ao pipeline de entrega: cada alteração é verificada automaticamente antes de ir para o ar, com relatórios que mostram a saúde do software e a evolução da qualidade ao longo do tempo.
Como a qualidade é construída
Qualidade não é uma fase no fim do projeto. É uma forma de construir software, do primeiro rascunho da ideia até o acompanhamento em produção. Este é o método aplicado no dia a dia dos times.
Qualidade desde o primeiro dia
Shift Left é trazer os testes para a esquerda da linha do tempo, ou seja, para o começo. Em vez de testar só quando tudo está pronto, a qualidade participa da descoberta, do refinamento e do desenvolvimento. Os problemas aparecem quando ainda são baratos de resolver.
DescobertaRefinamentoDesenvolvimentoCode reviewDeployProdução
Modelo tradicional
Testes concentrados no fim. Bugs chegam tarde, com mais retrabalho.
Shift Left
Qualidade presente em todas as fases, mais forte no começo, onde evita mais custo.
- QA no refinamento das histórias
- Critérios de aceite antes do código
- Quality Champions dentro das squads
- Testes rodando a cada pull request
A proporção certa de cada teste
A pirâmide de testes organiza a estratégia de automação: muitos testes rápidos e baratos na base, e poucos testes lentos e caros no topo. Assim o feedback é rápido e a suíte continua estável.
E2E
Integração & API
Unitários
+ testes exploratórios em todas as camadas
E2E
Poucos e valiosos. Cobrem as jornadas críticas do usuário de ponta a ponta, com Cypress ou Playwright.
Integração & API
Validam contratos, regras de negócio e a conversa entre serviços. Rápidos e muito estáveis.
Unitários
A base: muitos, rápidos e baratos. Dão feedback em segundos para quem está desenvolvendo.
Atalhos de quem sabe onde o bug se esconde
Heurísticas são regras práticas, nascidas da experiência, que guiam o que testar e onde olhar. Não garantem que tudo será encontrado, mas tornam o teste exploratório mais rápido, mais completo e menos dependente da sorte.
SFDPOT
Estrutura, Função, Dados, Plataforma, Operações e Tempo: um roteiro para não esquecer nenhuma dimensão do produto.
Valores-limite
Os bugs gostam das bordas: o mínimo, o máximo, um a menos e um a mais.
Classes de equivalência
Agrupar entradas que se comportam igual e testar um representante de cada grupo, sem repetir esforço.
CRUD
Criar, ler, atualizar e apagar: cada dado precisa sobreviver ao ciclo de vida completo.
Zero, um, muitos
Lista vazia, um item só e milhares de itens costumam revelar comportamentos bem diferentes.
Interrupções
Voltar no navegador, perder a conexão, clicar duas vezes, sessão expirada: o mundo real não segue o caminho feliz.
Cada risco pede um tipo de teste
Não existe um teste que cubra tudo. A combinação certa é escolhida conforme o risco, o momento do produto e o tempo disponível.
Funcional
O sistema faz o que deveria fazer?
Regressão
O que já funcionava continua funcionando?
Smoke
O essencial está de pé depois do deploy?
Exploratório
Investigação guiada por heurísticas e curiosidade.
Integração
As partes conversam bem entre si?
API
Contratos, status, regras e dados das APIs.
E2E
A jornada completa, como o usuário vive.
Carga
Como o sistema se comporta sob volume, com K6.
Usabilidade
É claro e simples para quem usa?
Mobile
Telas, gestos e condições de rede do celular.
Perto de produto, longe do retrabalho
Boa parte dos bugs nasce de um mal-entendido, não de código. Por isso o trabalho é lado a lado com a pessoa de produto: quanto mais cedo todos se entendem, menos defeito chega no usuário.
“Qualidade é uma conversa contínua entre quem pensa, quem constrói e quem testa.”
- Participação no refinamento junto com produto e desenvolvimento, antes de qualquer linha de código.
- Critérios de aceite claros e testáveis, escritos em conjunto, para que todos tenham a mesma definição de pronto.
- Riscos e cenários de borda levantados cedo, enquanto mudar ainda é barato.
- Dados de qualidade levados para as decisões de roadmap e de prioridade.
Antes de mudar, medir
Toda melhoria começa por um diagnóstico. As métricas são extraídas antes de aplicar qualquer quality gate e comparadas com o depois. Assim o ganho de qualidade fica visível para o time e para a liderança, sem achismo.
Antes
Medir o ponto de partida
Antes de mudar qualquer processo, as métricas atuais do time são extraídas. Sem esse retrato, não dá para provar que algo melhorou.
Durante
Aplicar os quality gates
Com o diagnóstico em mãos, os gates são definidos onde o risco é maior, acompanhando a adoção pelas squads.
Depois
Comparar e ajustar
Antes e depois comparados com os mesmos indicadores, resultado apresentado ao time e ajustes no que não trouxe ganho.
O que acompanho
- Bugs encontrados em produção
- Taxa de reabertura de tarefas
- Churn rate das squads
- Tempo de ciclo até produção
- Cobertura de automação
- Estabilidade dos testes (flaky)
Portões que só abrem com qualidade
Quality gates são pontos de verificação no caminho até a produção. Cada um tem critérios objetivos: se não forem atendidos, a entrega não avança. Isso tira a qualidade do campo da opinião e coloca no processo.
Commit
Gate 1
Código
Lint, build e testes unitários
Gate 2
Integração
Testes de API e contratos
Gate 3
Smoke E2E
Jornadas críticas no pipeline
Gate 4
Release
Regressão e critérios de aceite
Produção
Como os quality gates são criados
Mapeamento dos riscos do produto e das métricas atuais.
Definição, com o time e com produto, de critérios objetivos: o que bloqueia e o que só alerta.
Automação dos gates no pipeline de CI/CD, com Argo Workflows.
Publicação dos resultados em relatórios (Allure, Cypress Cloud) visíveis para todos.
Revisão periódica dos gates, para que continuem úteis, e não burocráticos.
Automação que dura
Automatizar não é gravar cliques. É escrever código de teste com o mesmo cuidado do código de produção: legível, reutilizável e fácil de manter. Para isso, o padrão Page Objects é usado com Cypress e Playwright.
Page Objects
Cada tela vira uma classe com seus elementos e ações. O teste descreve o que o usuário faz, e a página sabe como fazer.
Manutenção em um só lugar
Mudou um botão? O ajuste é feito em um ponto só e todos os testes que usam aquela tela continuam funcionando.
Integrada ao pipeline
A suíte roda a cada entrega no CI/CD, com relatórios no Allure e no Cypress Cloud.
Playwright · Page Object
// pages/LoginPage.ts
export class LoginPage {
constructor(private page: Page) {}
email = () => this.page.getByLabel("E-mail");
senha = () => this.page.getByLabel("Senha");
entrar = () => this.page.getByRole("button", { name: "Entrar" });
async login(email: string, senha: string) {
await this.email().fill(email);
await this.senha().fill(senha);
await this.entrar().click();
}
}
// tests/login.spec.ts
test("usuário acessa o painel", async ({ page }) => {
const login = new LoginPage(page);
await page.goto("/login");
await login.login("qa@empresa.com", "********");
await expect(page).toHaveURL(/painel/);
});Qualidade é responsabilidade de todos
Um QA sozinho não garante qualidade, e nem deveria. Qualidade de verdade acontece quando produto, design, desenvolvimento e liderança compartilham o mesmo critério do que é "pronto". O papel do engenheiro de qualidade é espalhar esse conhecimento pelo time, até que a qualidade deixe de depender de uma pessoa.
ProdutoDesignDesenvolvimentoQALiderança
Modelo tradicional
A qualidade fica com uma pessoa, e vira gargalo no fim do processo.
Cultura de qualidade
Cada papel assume sua parte, e o QA atua como referência e multiplicador.
- Workshops e treinamentos para o time
- Quality Champions em cada squad
- Critérios de "pronto" definidos em conjunto
- Boas práticas documentadas e acessíveis
Experiência
Projetos Independentes
Desenvolvedor Front-end · Freelancer
- Criação de websites e landing pages para clientes de diferentes segmentos, do levantamento de necessidades à publicação.
- Interfaces responsivas, pensadas primeiro para o celular.
- Performance, acessibilidade e boas práticas de SEO tratadas como requisito desde a estrutura.
- Código organizado e fácil de manter, validado com o olhar de engenharia de qualidade antes de cada entrega.
Frota162
Consultor de Qualidade de Software
- Estruturação da área de QA com processos, governança e cultura de qualidade para 5 squads simultâneas.
- Referência de qualidade para cerca de 23 desenvolvedores, promovendo Shift Left Testing e Quality Champions.
- Evolução de framework interno baseado em GenAI/LLM/MCP para geração de cenários, planos de teste e validações.
- Automações E2E com Cypress e Playwright integradas ao CI/CD via Argo Workflows.
- Allure Reports e Cypress Cloud para rastreabilidade e acompanhamento de churn rate das squads.
Autoforce
QA Lead
QA Sênior
- Gestão e desenvolvimento do time de Qualidade de Software, com 5 QAs.
- Definição da estratégia, aplicação de Shift Left Testing e roadmap da área de QA.
- Testes E2E com Cypress, testes de API com Postman e Cypress, e testes de carga com K6.
- Análise de impacto, documentação técnica, relatórios de qualidade e apoio ao roadmap de produto.
SóCarrão
QA Analyst
- Planejamento e levantamento de requisitos de testes.
- Automação com Cypress e testes de API com Postman.
- Testes de regressão, smoke, usabilidade e carga.
Roit Bank
QA Analyst
- Testes funcionais, mobile e de API com Postman.
- Testes automatizados com Cypress.
Mirum Brasil
QA Analyst
- Testes funcionais: regressão, exploratórios e smoke.
- Automação com Ruby e Cucumber, e testes de API com Postman.
Vamos construir algo com qualidade?
Para times: estruturar ou elevar a qualidade do que já está em produção.
Para quem tem uma ideia: tirar o projeto do papel com quem sabe onde o software costuma quebrar, do primeiro rascunho à publicação.