Ep. 43 - Qualidade, qualidade qualidade

Este episódio recebe Samanta Cecília, referência nacional em qualidade de software e cocriadora do Agile Testers, para discutir por que qualidade continua sendo um assunto negligenciado mesmo num mundo cada vez mais dependente de software.

O problema de abertura é direto: apesar de o software estar por trás de praticamente tudo hoje, qualidade ainda é um tema frequentemente evitado dentro das organizações, muito mais fácil falar de fluxo, negócio ou produto do que do domínio técnico e da qualidade propriamente dita. Samanta reforça que, embora se fale mais sobre qualidade hoje do que há alguns anos, nem sempre esse interesse é genuíno. Ela define qualidade como um conjunto de atributos ligado à expectativa de diferentes pessoas, algo que, por natureza, você não controla totalmente. Isso inclui não só a expectativa do cliente final, mas também a do próprio time: um software sem cuidado com testabilidade e manutenibilidade vai gerar dificuldade constante para quem precisa dar manutenção a ele, mesmo que o cliente nunca perceba isso diretamente.

Um erro comum apontado é tentar resolver todo problema de qualidade com a mesma ferramenta genérica, 'ah, precisa fazer teste unitário', sem antes investigar qual problema específico de qualidade realmente precisa ser resolvido naquele contexto. Isso exige conhecer o usuário final, entender o negócio (inclusive questões regulatórias, que podem gerar multas se ignoradas) e considerar a saúde do próprio time, evitando cenários em que um produto de sucesso é sustentado às custas de hora extra e deploys de madrugada.

Samanta conta sua trajetória profissional em detalhe, cada etapa marcada por resolver um problema real específico. Na Infoglobo, em 2012, entrou como estagiária num time de qualidade que nasceu não de uma decisão de diretoria, mas da insatisfação de dois desenvolvedores com a quantidade de problemas em produção. O time experimentou formatos até descobrir o que funcionava, incluindo colocar profissionais de QA dentro dos times de desenvolvimento em vez de um silo isolado. Resolvido esse primeiro problema, surgiu o seguinte: o processo de deploy era caro e arriscado, exigindo janelas específicas à meia-noite. Isso a levou a se aprofundar em DevOps, aprendendo a criar pipelines e ferramentas de observabilidade, até o time conseguir sair de deploys raros e tensos para múltiplos deploys automatizados e confiáveis por dia.

Um ponto de virada pessoal veio quando o principal stakeholder do software que ela desenvolvia decidiu bloquear qualquer nova entrega em produção, com medo de quebrar algo, um sintoma claro, segundo ela, de um problema de qualidade real e não resolvido. Foi perseguindo esse tipo de problema que ela se aproximou da comunidade de testes, participando de eventos desde 2012 (incluindo o Test Day em São Paulo, onde conheceu Galani, seu parceiro no projeto Agile Testers).

Na Concrete, uma consultoria de tecnologia, Samanta viveu sua virada de contribuidora individual para gestora, acompanhando o crescimento da área de QA de cerca de sete para cinquenta pessoas espalhadas por diferentes escritórios do país. Ali ela trabalhou com Andressa Chiara (referência recorrente no podcast) e aprendeu a lidar com a natureza particular da consultoria: mesmo quando um cliente não valorizava explicitamente testes automatizados ou não incluía um perfil de QA no contrato, o time às vezes decidia investir nisso mesmo assim, não para o cliente ver, mas para a própria saúde e confiança do time em fazer mudanças com segurança, e depois usava esse resultado concreto para demonstrar valor e negociar a inclusão desse perfil em contratos futuros. Ela descreve a cultura de comunidade interna criada na Concrete: encontros regulares de capítulo de QA, conectando escritórios de diferentes cidades por videoconferência, com apresentações internas de técnicas e rotação de pessoas entre diferentes especialidades (mobile, API, web) para evitar isolamento e estagnação, mesmo estando cada QA fisicamente alocado dentro de times de clientes diferentes.

Da Concrete, Samanta foi para a Paysertify, uma startup de São Francisco com time distribuído globalmente, como Head de QA, um desafio de construir toda a estrutura de qualidade do zero, num time pequeno recém-saído da fase de validação de hipótese de produto. Ali ela teve contato direto com clientes e com todas as áreas da empresa, uma experiência que reforçou uma ideia central: o que diferencia uma startup de sucesso não é fazer as coisas 'de qualquer jeito' por conta do clima acelerado, mas justamente a qualidade do que entregam, pautada numa visão sistêmica do negócio como um todo, cliente, produto e time.

Atualmente na Pagar.me, Samanta descreve um cenário diferente: os times já se importam genuinamente com qualidade e escrevem testes automatizados por conta própria, mas falta uma estrutura que facilite e unifique esse esforço. Ela cita o livro 'Team Topologies' como referência que deu nome a um modelo que já vinha aplicando intuitivamente: em vez de um time de QA isolado que só recebe e testa demandas (criando um gargalo), ou um modelo em que cada time tem seus próprios especialistas mas ainda corre risco de silos internos, o modelo adotado na Pagar.me usa times especialistas (em qualidade, infraestrutura, segurança) que 'habilitam' outros times, não como um gate que aprova ou reprova, mas como suporte que ajuda os times de produto a ganharem autonomia real, com métricas e diretrizes compartilhadas em vez de controle centralizado. Ela compartilha, com evidente orgulho, um exemplo recente: seu time identificou e resolveu sozinho um problema sistêmico, sem qualquer intervenção direta dela, sinal, para ela, de que esse modelo de habilitação está funcionando de verdade.

É contado um caso adicional, de um grande banco público brasileiro atendido em consultoria: um time que desenvolvia ferramentas de teste automatizado para mainframe em COBOL, algo raro no mundo, ilustrando a capacidade técnica brasileira, inicialmente via seu trabalho apenas como melhorar a ferramenta em si, até perceberem, num momento de clareza coletiva, que o verdadeiro objetivo era disseminar uma cultura de qualidade, não apenas adicionar funcionalidades a um software. Em contraste, é citado outro time do mesmo contexto que automatizou testes apenas na interface, sem entender o problema real, resultando numa suíte de testes que levava oito horas para rodar, evidência de solução aplicada sem compreensão do problema original.

Para encerrar, Samanta dá conselhos práticos para quem está num contexto onde qualidade simplesmente não é pauta. Primeiro: identifique problemas visíveis, como a taxa de retrabalho gerada por defeitos que chegam ao cliente, dado que às vezes fica isolado apenas na área de atendimento, sem nunca chegar ao time de desenvolvimento. Segundo: cuidado com métricas de vaidade, fazer cinquenta deploys num dia não significa nada de bom se quarenta e nove deles forem correções emergenciais do primeiro deploy quebrado; o que importa é acompanhar quantas entregas geram problemas reais. Terceiro: reforçar que qualidade também é sobre a saúde do time, não apenas do cliente: um time sem confiança para fazer mudanças, sempre apagando incêndio, tem um problema real de qualidade que precisa ser resolvido, e parte disso envolve o próprio time aprender a negociar e defender seus requisitos como legítimos, não apenas atender pedidos externos.