PSP em Tempos de DevOps: o Teste que o Desenvolvedor não Faz
Uma defesa do teste manual, local e consciente no desenvolvimento moderno.
Na virada dos anos 1990 para os 2000, enquanto o mundo do desenvolvimento de software ainda tropeçava tentando entender como entregar sistemas com menos defeitos e mais previsibilidade, surgiu uma proposta ousada: o PSP — Personal Software Process. A ideia era simples, mas potente: e se o desenvolvedor medisse, ele mesmo, os próprios erros, os próprios tempos, os próprios acertos? E se o controle de qualidade começasse individualmente, antes mesmo de qualquer QA, pipeline ou análise estática entrar em cena?
Tive a oportunidade de participar de projetos reais de implantação de PSP. E posso afirmar com segurança que funcionava. Em contextos onde os profissionais aderiram com seriedade à proposta, os ganhos foram visíveis. Os indicadores da qualidade percebida deram saltos. E, talvez mais importante do que os números, desenvolvedores começaram a enxergar seus próprios padrões de falha. Começaram a depurar o próprio comportamento.
Hoje, o PSP original sobrevive quase que exclusivamente no ambiente acadêmico. Em cursos de tecnologia mais tradicionais, ainda se ensina a medir tempo de codificação, categorizar tipos de defeito, anotar os minutos gastos com correções. Mas, do lado de cá, no mercado — principalmente nas empresas onde o ágil e o DevOps já tomaram conta — quase ninguém mais fala disso.
Em vez disso, falamos em ferramentas. Testes automatizados, coverage reports, SonarQube, pipelines com dezenas de gates. Nada disso existia na época do PSP original, e é justo reconhecer que houve evolução. Mas é curioso — e um pouco irônico — que, com tanta automatização, um hábito fundamental do desenvolvedor se tornou escasso: o teste manual, local, imediato.
Refiro-me àquele teste que se faz no terminal, com um JSON na mão, batendo numa rota antes de subir a branch. Aquele clique no botão da tela, num ambiente de dev, só pra ver o que acontece se o cliente tentar cadastrar um usuário sem CPF. O “teste do desenvolvedor”, o ensaio antes do show, o ensaio que muitos hoje não fazem mais.
O resultado é um novo tipo de problema crônico. Não são erros de lógica, tampouco falhas de arquitetura. São defeitos funcionais — os mais caros, os mais frustrantes. Código bonito, com 100% de cobertura e zero code smells, mas que simplesmente não faz o que deveria fazer. Erros que não deveriam sair do laptop, mas que só são percebidos no QA, ou pior, em produção.
É por isso que me parece urgente revisitar o espírito do PSP. Não a cartilha original, mas a essência. Uma proposta adaptada aos tempos atuais, que reconheça a existência de ferramentas automatizadas e de ciclos de feedback contínuos, mas que também resgate a responsabilidade individual do desenvolvedor em validar aquilo que escreveu.
Essa nova versão do PSP poderia se apoiar em poucos, mas sólidos pilares:
Checklists funcionais individuais, ligados às histórias de usuário, para validação local.
Tempo reservado no ciclo de desenvolvimento para testes manuais exploratórios, antes de qualquer pull request.
Registro (mesmo informal) de erros evitáveis detectados após o commit, para análise retroativa e aprendizado pessoal.
Métricas funcionais simples, como número de falhas de regras de negócio encontradas no QA que poderiam ter sido detectadas localmente.
Participação ativa dos Engenheiros de Qualidade, não como fiscais, mas como mentores e facilitadores desse processo individual de melhoria.
Nada disso precisa ser formal ou pesado. Pode viver junto com o Jira, com o GitHub Actions, com o Cypress. Mas precisa existir.
Porque, no fim das contas, qualidade de software continua precisando de responsabilidade. E, mesmo que a esteira de desenvolvimento esteja cheia de sensores e alarmes, a decisão do primeiro teste ainda é pessoal. Ainda é humana. Ainda é do desenvolvedor.