Embora Quality has nothing to do with testing seja um ótimo post que vale a pena dar uma olhada, acho que o título ficaria melhor formulado como Quality has nothing to do with finding defects. Testes são instrumentos de feedback que obtemos do software quando comparamos seus resultados com nossas expectativas. Assim, quando o resultado de um teste é associado com a completude de uma expectativa, ele é sim um importante instrumento de qualidade.
O mérito do post está em desmistificar as atividades de teste como sendo as únicas necessárias para garantir a qualidade do software. Na verdade, o que ocorre é que as atividades de teste perdem dramaticamente o poder de agregar valor em termos de qualidade quando são utilizadas como instrumento de inspeção-para-a-localização-de-defeitos. Se uma feature sai do ambiente de desenvolvimento sem funcionamento adequado, será certamente mais apropriado parar e descobrir porquê isso ocorreu do que registrar os problemas em um bug tracking e depois continuar o trabalho de inspeção incansável até que nenhum problema seja mais encontrado.
Uma melhor opção é utilizar as atividades de testes como instrumentos para prevenção-de-defeitos. Ao criar, por exemplo, um teste automatizado, não há inspeção. Há a formalização de critérios de aceitação que passarão a conviver eternamente de forma agregada ao produto à partir daquele momento. Assim, somos capazes de introduzir qualidade no produto no mesmo passo em quê o desenvolvemos.
A qualidade dos incrementos de software liberados em um projeto Ágil depende muito do efeito conjunto resultante da aplicação de diferentes tipos de técnicas e práticas, cujo intuito central é evitar que defeitos sejam introduzidos no produto. A ação conjunta desses elementos tem o poder de eliminar (muitas vezes por completo) a necessidade de inspeções-para-a-localização-de-defeitos.
Testes orientados para inspecionar aquilo que, já no seu início, é produzido sem levar em conta os vários aspectos de qualidade relevantes para desenvolvimento de software, são nocivos na medida em que criam uma cultura em que quem desenvolve não precisa garantir a qualidade daquilo que faz, pois há uma implícita delegação para que isso seja verificado por uma outra pessoa.
No entanto, inspeções não serão sempre ruins. Há as inspeções boas também. Elas ocorrem quando o foco é gerar feedback. Ao inspecionar uma nova funcionalidade, por exemplo, o foco de quem inspeciona não precisa ser verificação e conferência. O objetivo da boa inspeção é dar feedback, é oferecer um novo ponto de vista de modo a encontrar pontos que poderiam estar melhor resolvidos. O mesmo ocorre quando inspecionamos código, seja passando o código para um colega inspecionar, ou seja fazendo inspeção contínua com pair programming. Em ambos os casos, a procura-por-problemas é elemento secundário, enquanto que feedback é o elemento central.
Em resumo, a inspeção ruim procura por defeitos, enquanto que a boa gera feedback.