“Não tínhamos testadores”: como a Givebacks construiu uma cultura de qualidade

O horário após o almoço na Quality Sense Conf, no Uruguai, não costuma ser o momento em que se espera uma confissão. Foi exatamente assim, porém, que Matt Harrell, cofundador da Givebacks, plataforma de K-12 baseada nos Estados Unidos, escolheu abrir a palestra.

No palco, ao lado de Alexa Altez, da Abstracta, ele admitiu que, durante anos, a empresa cresceu rapidamente, processando milhões de dólares em pagamentos escolares, sem uma equipe formal de testes.

“Não tínhamos testadores. Não tínhamos um processo formal de QA”, disse ele à plateia. Os product owners faziam algumas verificações, os smoke tests rodavam antes dos releases e o negócio seguia em frente. “Olhando para trás”, acrescentou, “eu realmente não sei como conseguimos fazer isso.”

A sessão, parte da edição de 2025 da Quality Sense Conf, realizada em 11 de novembro no Radisson Hotel, em Montevidéu, Uruguai, rapidamente se transformou em um estudo de caso ao vivo sobre o que acontece quando hábitos de startup colidem com uma realidade de alto risco.

De uma pequena plataforma para PTAs a uma infraestrutura crítica¶

A Givebacks começou em 2008 para criar um software de excelência que ajudasse organizações sem fins lucrativos e grupos liderados por voluntários a trabalhar de forma mais inteligente e arrecadar mais recursos. Em 2018, era “basicamente uma plataforma de gestão de membros” para associações de pais e professores, como Matt descreveu.

Naquele ano, a empresa atendia cerca de 1.000 PTAs (associações de pais e professores), processava aproximadamente três milhões de dólares em volume de pagamentos e operava com dois desenvolvedores e um representante de suporte.

Em 2023, o cenário havia mudado. A Givebacks tinha evoluído para uma “plataforma tudo em um de engajamento e captação de recursos para pais”, usada por cerca de 11.000 PTAs escolares e movimentando cerca de 80 milhões de dólares em vários produtos. A equipe de engenharia havia crescido para cinco desenvolvedores, com gerentes de produto e uma equipe maior de suporte.

O que não havia mudado era o modelo de testes. Ainda não havia especialistas de QA dedicados.

A empresa, disse Matt, tinha “aderido a esta filosofia de ‘mover rápido e quebrar coisas’”. “Estávamos indo rápido e quebrando muita coisa.”

Quando “quebrar coisas” se torna um risco¶

O ponto de ruptura chegou em 2024, durante a volta às aulas, o período mais sensível do ciclo anual da Givebacks. A equipe tinha reformulado módulos importantes, incluindo a funcionalidade de associação da qual as PTAs locais dependem para reportar dados às organizações estaduais.

“Nós tínhamos quebrado isso”, contou Matt à plateia da QSConf. O resultado foi uma sequência de bugs críticos que afetaram os clientes no pior momento possível. Parcerias em nível estadual, como a com a New York State PTA, ficaram de repente sob pressão, enquanto as escolas lutavam para obter as informações de que precisavam.

“O volume de tickets de suporte também disparou. Tínhamos clientes frustrados, agentes de suporte esgotados e equipes de produto cansadas. Os product owners corriam tentando entender: ‘Temos que corrigir isto agora, temos que corrigir aquilo ali’. Tínhamos uma diretoria decepcionada. Todo mundo estava decepcionado com algumas das coisas que estavam acontecendo”, ele lembrou.

A percepção da marca, recordou Matt, começou a soar assim: “A Givebacks é ótima, eles têm esta plataforma excelente e precisamos usá-la. Eles têm alguns bugs, mas os corrigem.”

“Eu só me lembro de pensar tantas vezes”, disse ele no palco, “é por isso que queremos ser conhecidos?”

O atalho no-code que não era atalho¶

No que veio depois, a equipe de liderança concordou em uma coisa: “Precisamos de QA”. A primeira opção concreta que apareceu foi uma plataforma de automação com IA, no-code, oferecida por um empreendedor local.

O discurso era familiar para muita gente na plateia da QSConf: automatizar centenas de testes em poucos meses, “entregar mais rápido e entregar melhor”, exigindo apenas um tempo mínimo da equipe interna. Segundo Matt, o fornecedor sugeriu que eles poderiam automatizar cerca de 600 testes em três meses com “15 minutos de uma pessoa da sua equipe por semana”.

“Dá para imaginar o impacto dessa proposta de valor”, disse ele, especialmente para o CEO. A ideia de que uma ferramenta poderia “marcar essa caixa e ter todos os testes feitos” era poderosa.

A Givebacks concordou com uma prova de conceito de 15 dias. O software do fornecedor gerou cerca de 100 testes para o módulo de associações, uma área crítica que eles não podiam se dar ao luxo de quebrar outra vez. Quando os dois lados se reuniram para revisar o resultado, o entusiasmo esfriou.

Matt descreveu o resultado como “incerto”. Alguns casos de teste eram “rasos” e não cobriam as jornadas completas dos usuários. Havia sobreposição em partes da cobertura e “eles simplesmente deixaram de fora alguns fluxos críticos de usuário”. Os engenheiros, acrescentou, tiveram dificuldade com a opacidade do sistema: “Havia pouca transparência no código, e a engenharia ficou meio confusa… o que isso fez?”

Ele disse à plateia que conseguia imaginar esse tipo de ferramenta funcionando bem em um aplicativo simples, com “apenas três ou quatro fluxos de usuário”. Na plataforma de vários módulos da Givebacks, que movimenta o dinheiro das escolas, a equipe concluiu que “isso não vai funcionar”.

Uma proposta diferente: “somos seus aliados em qualidade”¶

Na mesma época, a Givebacks foi apresentada à Abstracta, por recomendação de outra empresa. A abordagem era diferente da proposta de automação. A Abstracta se apresentou como “seus aliados em qualidade” e propôs começar por uma avaliação de maturidade, em vez de ferramentas.

Segundo Matt, não foi um exercício tradicional de apresentação de slides. A equipe da Abstracta participou das reuniões de sprint, conversou com engenheiros e product owners e “logo começou a se integrar à organização e simplesmente observar”.

A avaliação trouxe uma conclusão que mudou a conversa interna. “Não tínhamos um problema de QA”, disse Matt. “Na verdade, tínhamos um problema de entrega.”

A empresa estava perdendo datas de release, publicando bugs nas temporadas de pico e enfrentando silos. A automação, sozinha, não ia resolver isso.

Da avaliação saiu um plano de 90 dias. Alexa, representando a Abstracta no palco, descreveu o plano como “um plano que detalhava cada coisa que faríamos nos 90 dias seguintes para começar a construir essa base”, desde a escolha de uma estratégia de gestão de casos de teste até a definição de como os casos de teste críticos seriam escritos.

Mudanças incrementais: quando o processo encontra as pessoas¶

O plano parecia sólido. A implementação foi outra história.

Uma das primeiras mudanças focou a forma de reportar bugs. Até então, os defeitos eram registrados como comentários dentro da user story principal na ferramenta de acompanhamento. A Abstracta propôs uma abordagem mais estruturada.

“A questão é que as pessoas tinham trabalhado durante meses, ou até anos, seguindo aquele processo”, lembrou Alexa. “E de repente apareceram pessoas de fora para dizer: ‘Vocês precisam mudar isto’.”

Olhando para trás, ela viu nisso uma armadilha clássica dos projetos de transformação: concentrar-se em ferramentas e em checklists de boas práticas e subestimar o impacto nos hábitos e nas rotinas das pessoas. “Focamos demais nas ferramentas, nas boas práticas e no que o livro diz, mas esquecemos as pessoas, em vez de tentar colaborar com elas.”

A resistência não se limitava aos fluxos de bugs. A Givebacks também precisou confrontar suas premissas internas sobre responsabilidade. “QA não é a única responsável pelos bugs” tornou-se uma mensagem-chave que, nas palavras de Matt, exigiu “uma mudança de mentalidade”, de uma cultura de culpa para uma cultura de qualidade.

Apesar de haver pods de produto multifuncionais, “engenharia, produto e QA não se cruzavam; não se misturavam muito bem”, disse ele. A culpa circulava em padrões conhecidos: requisitos incompletos, critérios de aceite ausentes e casos extremos que passavam despercebidos.

O progresso veio por mudanças incrementais: convidar o VP de Engenharia para o canal em que as execuções de testes automatizados eram publicadas, pedir aos testadores funcionais que falassem nas reviews de sprint e nas sessões de grooming e envolver os fundadores diretamente nas discussões sobre risco e expectativas.

Números, e a recusa de fingir que a história terminou¶

Depois de mais de um ano de colaboração, a Givebacks consegue apontar mudanças mensuráveis.

“Agora temos mais de 2.000 casos de teste. Temos algum nível de automação em cerca de 90%, e eles encontraram literalmente mais de 500 defeitos antes de o release sair”, disse Matt.

Ao mesmo tempo, ele preferiu não apresentar uma história de sucesso bem-arrumada. “Eu adoraria sentar aqui e dizer: ‘Tínhamos bugs, fizemos parceria com a Abstracta e não temos mais nenhum bug’”, disse à plateia. “Mas a realidade é que, mesmo nesta temporada de volta às aulas, tivemos vários bugs que ainda chegaram à produção.”

Esses incidentes levaram a “uma análise profunda de causa raiz”, motivada também pela pergunta direta do CEO sobre por que, apesar do investimento, os bugs permaneciam. A análise reforçou uma ideia que Matt repetiu várias vezes: “Não é só uma questão de QA”. Muitas causas estão no produto e na engenharia, e na forma como as equipes trabalham juntas.

Dar um lugar para a mudança viver¶

Uma resposta estrutural da Givebacks foi criar uma função de gestão de mudanças: uma abordagem estruturada para passar de um estado atual a um estado futuro.

Matt lembrou que a equipe estava diante de tantas mudanças necessárias e se perguntava: “Por onde começamos? Como fazemos isso?”. Por isso, como ele afirmou, criaram essa função de gestão de mudanças, “porque gestão de mudanças tem a ver com pessoas. Tem a ver com conduzir as pessoas por todas as mudanças”.

A partir desse esforço interno, a empresa agora mantém um backlog de mudanças relacionadas à qualidade e à entrega. Os itens são priorizados, e representantes de engenharia, produto, QA e entrega se reúnem para discuti-los.

A prática nasceu de uma iniciativa interna da Givebacks. As avaliações contínuas da Abstracta e a análise de causa raiz contribuíram com insights que se transformaram em itens concretos e acionáveis do backlog.

“Agora, tudo o que estamos aprendendo e tentando mudar para ter foco em qualidade e no cliente passa pela gestão de mudanças. Conversamos com todas as pessoas envolvidas:

O que está mudando? Por que isso importa? Quem é impactado? Como vai ser a adoção? Vai ser tranquila? Vai ser mensurável?

Isto é muito novo. Essa função de gestão na nossa organização foi enorme para complementar o que fazemos do ponto de vista da qualidade e para impulsionar parte dessa mudança”, concluiu.

Lições para os líderes que estavam ouvindo¶

A sessão terminou com vários conselhos de Matt e Alexa, dirigidos especialmente a líderes de negócio e de produto que participavam da Quality Sense Conf.

Alexa, por sua vez, deixou três conclusões para a plateia:

1. Boas práticas, ferramentas e processos não bastam se não considerarmos as pessoas que vão se envolver neles.
2. A mudança exige paciência
3. A colaboração precisa incluir todas as pessoas envolvidas no produto, não apenas a tríade tradicional de produto, desenvolvimento e QA.

Matt os incentivou a se informar sobre as tendências mais recentes de qualidade, para “falar a língua” ao tentar introduzir práticas de qualidade em uma organização que já existe.

Ele também sugeriu preparar-se para a resistência: “Antecipe a resposta do seu líder de engenharia. Antecipe o que os seus product owners vão questionar.”

Do lado das métricas, ele compartilhou um momento que simplificou uma discussão complexa de dashboard. Um dos cofundadores, Bobby, disse à equipe que simplesmente queria “parar de publicar bugs de regressão” e listou três prioridades. Para Matt, aquilo foi um lembrete para “manter a simplicidade” ao apresentar o ROI de iniciativas de qualidade.

Em resumo¶

A história que Matt e Alexa levaram à Quality Sense Conf não era sobre uma ferramenta mágica nem sobre um framework perfeito. Era sobre uma empresa que descobriu, às vezes pelo caminho mais difícil, que escalar a qualidade significa mudar a forma como o trabalho é feito, como a responsabilidade é compartilhada e como as conversas incômodas são conduzidas, dentro e fora do palco.

Em 2025, a Givebacks se tornou o principal ecossistema de doações e pagamentos do mercado K-12.

Sobre a Givebacks¶

A Givebacks lidera em tecnologia filantrópica, ajudando escolas, organizações sem fins lucrativos e marcas a integrar a doação ao cotidiano. A plataforma viabiliza a captação de recursos para mais de 14.000 organizações sem fins lucrativos, fortalecendo uma cultura de doação e abrindo caminhos inovadores para arrecadar fundos.

• Fundada em 2008, com o lançamento do MemberHub.
• Sede em Raleigh, Carolina do Norte.
• Atende 61 distritos escolares e 42 PTAs estaduais nos Estados Unidos, com mais de 14.000 contas da Stripe conectadas e mais de US$ 115 milhões em volume anual de pagamentos.
• Envolve mais de 5 milhões de pais e mães
• Tem parceria com mais de 10.000 restaurantes e 15.000 varejistas online.
• Oferece captação passiva de recursos durante o ano inteiro, por meio dos programas “Shop to Give”.

Nossa colaboração com a Givebacks resultou em uma transformação significativa dos processos de QA, com melhorias mensuráveis na qualidade do produto, na eficiência da equipe e na experiência do usuário. Convidamos você a ler o nosso case de sucesso.