Hoje um dos temas quentes do twitter foi precisamente a questão da segurança, ou melhor dizendo das suas falhas de segurança.
Existem quanto a mim, duas grandes fontes destes problemas, por um lado os clientes, sejam internos ou externos, pagam funcionalidades e dão a segurança como um dado adquirido, os prazos são geralmente apenas pensado em termos de funcionalidades, por outro lado, existe o problema da fusão de papeis, tarefas que deviam ser executadas por pessoas diferentes são na realidade executadas pelas mesmas pessoas.
Mesmo no caso do desenvolvimento de software, o developer têm um reforço positivo quando os testes correm, e um reforço negativo quando quebram.
Como o seu cérebro funciona no sentido dos reforços positivos, isto motiva o developer a corrigí-los e a não quebrá-los, mesmo quando tem mesmo de o fazer para avançar.
A situação piora quando o developer quer testar a sua aplicação, criando novos testes, sendo de certa forma traído pelo seu próprio cérebro que não o ajuda a criar bons testes para o quebrar.
No entanto existem possíveis soluções, como gerar testes aleatóriamente ou todos os casos possíveis (quando é possível), ou recorrer apenas aos use-cases e depois ir adicionando à medida que vão sendo reportados bugs.
Mas a melhor solução é sem dúvida ter um tester especializado, idealmente até pode ser um gajo do contra, cujo prazer lhe vem apenas de encontrar falhas no trabalho dos outros, o que importa é que ele tenha prazer em encontrar bugs e a reportá-los para que possam ser criados os testes.
Quando falamos em termos de segurança, a situação é ainda mais complicada, porque normalmente as consequências são maiores, pelo que a questão dos reforços é ainda mais evidente.
Obviamente não é dizer que o developer não deva perceber de segurança, claro que sim, o máximo possível, mas o objectivo dele é protecção, o tester é penetração.
Eu sou a favor de disputas amigáveis entre developers e testers.
