Robert C. Martin (Uncle Bob) tem uma opinião marcante sobre o papel do QA no desenvolvimento de software. Em suas palestras e livros, como Clean Code, Clean Coder, Clean Architecture, Clean Agile e Clean Craftsmanship, ele frequentemente afirma que o papel de QA não deveria existir em um time de desenvolvimento bem estruturado. Segundo ele:
“Se você tem um time de QA, significa que o time de desenvolvimento não está assumindo responsabilidade pela qualidade do software.”
Uncle Bob argumenta que a responsabilidade pela qualidade deve ser integralmente dos desenvolvedores, desde o momento da escrita do código até sua entrega em produção. Ele acredita que a criação do papel de QA frequentemente leva a um deslocamento de responsabilidade, onde os desenvolvedores delegam a garantia de qualidade para outra equipe, em vez de garantir que o código esteja correto desde o início.
Sua visão é que, em um cenário ideal:
• Desenvolvedores escrevam testes automatizados robustos (unitários, de integração, de aceitação, etc.).
• A equipe inteira trabalhe com práticas como TDD (Test-Driven Development).
• O processo seja projetado para evitar defeitos ao invés de detectá-los posteriormente.
Isso não significa que Uncle Bob desvalorize o papel de QA. Ele reconhece a importância histórica do QA, mas enfatiza que o modelo moderno de desenvolvimento ágil deve buscar integrar essas práticas dentro do próprio trabalho dos desenvolvedores.
Essa fala tem gerado debates sobre como equilibrar responsabilidades em equipes, especialmente em organizações onde QA é visto como essencial para garantir qualidade.
E você? Qual a sua opinião?
Deixa um comentário.
A propósito, quer se tornar um/uma QA mais técnico/a?
Conheça a Assinatura Talking About Testing e transforme sua carreira com uma experiência prática e exclusiva para profissionais de qualidade e engenharia de software. 🚀
Obrigado pela leitura e até a próxima! 👋😉✌️
TALKING ABOUT TESTING 
concordo em partes. No cenário perfeito seria isso mesmo, mas também não seria necessário PO e techlead, pois os devs tem capacidade de interpretar o negócio e não precisa de liderança pois teria responsabilidade, proatividade e pontualidade nas entregas. Acredito que os demais cargos servem para retirar o peso maior até a entrega do produto, mas nem isso agiliza a entrega pois até chegar no QA, a descrição das funcionalidades é precária, o Dev demora pra entregar e o techlead só reage se forem atrás ou quando é cobrado da gestão. Aí fica o QA sendo cobrado.
Oi Rafael, obrigado pelo comentário.
No entanto, o mesmo parece enviesado em suas experiências e não dá pra generalizar.
Tem muito software sendo desenvolvido com práticas modernas onde o que você citou não acontece.
De qualquer forma, valeu pela contribuição.
Boa Tarde, Walmyr. Feliz Ano !! Tudo bem ? O comentario do post veio para o Rafael errado.
👌
Eu que me confundi aqui . Me desculpe .
👌